| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Why We Stopped Using the Auto-Mocking Container and What's Next

Page history last edited by Weston M. Binford III 14 years, 11 months ago

 

Video of the presentation:

AltNetSeattle: Why We Stopped Using the AutoMockingContainer from Weston M. Binford III on Vimeo.

 

Notes:

 

Mocking entities is a pain in the ass. If you have object graphs more than two levels deep...

 

Controller took on additional dependencies, three services, each has one or two DAL dependencies. Fine grained unit testing, but creating a lot of mocks. How can we simplify this? Came up with the AutoMockingContainer. Worked great. But, found that mocking entities was not really that useful because they were persistent ignorant anyway.

 

Moved to Fluent Fixtures some people call them Fluent Builders.

new Student("Bob").EnrolledIn(new Course("101"))

 

Not a way to specify business behavior, just create an object graph. Still really like that for their messaging infrastructure now.

 

Some of these services can get big. Services need to be refactored and decomposed into other services.

 

Start with a Service that is unit tested. Then, start to decompose it, where do we test? Started using fine-grained unit tests around the services, but this was very brittle, but when you started to refactor, you had to scrap a hundred unit tests, because of the ripple effect of the refactoring. Nothing about the tests breaking tells him anything because they are breaking because the assumptions have changed.

 

Ian Cooper: Hard to refactor because you are doing white box testing

 

Aaron: "Hard core mockist to something in between to, more or less processes."

 

Fine grain unit testing didn't work. So, we didn't want to mock as much.

 

We create our dependencies manually

 

jbogard: Why not bring a container in?

 

In order to successfully use a container in test, you need a specialized container. Registration time is slow especially when doing Test Driven Development. For this result only, give me a mock of this. With Machine.Container, not doing any resolution when inserting into the container. Could still be improved. Lifetime Management. Singletons. Container will cache it, but want more control over when to nuke the cache and replace with mocks.

 

Elutian is currently using Windsor for their IoC container, but Aaron is using Machine.Container for side projects.

 

Requirements for container:

  • Fast Registration
  • Overrides
  • Lifetime Reset

 

Behavior based test:

 

When I put the funds transfer button, it should move the money from this account to this account. Write the controller first, AccountService (which does not exist yet), Checkpoint it. Pull entire object graph from container. Run state-based tests. Set up a script. These are the things I expect. Proxy everything and assert things coming and the things coming out and allow yourself to... Allow part of the test to fail, but continue testing.

 

Ian Cooper: Using a Fitnesse or story type testing tool. Make sure that if you are doing some kind of proxy wrapping make sure that it is going to be useful in your operational environment in addition to your testing environment.

 

Synthesis - Ruby project to make sure that objects have the methods you expect them to have.

 

So, where do we go from here?

Aaron went though an end-to-end example of how create the following feature:

When transferring funds from my account to Joe’s account,

  • it should debit my account $50
  • it should credit Joe’s account $50.

 

Comments (0)

You don't have permission to comment on this page.