http://blog.coreycoogan.com/2010/01/28/holy-over-mocking-batman-a-natural-progression/ Python, .Net, C#, ASP.NET MVC, Architecture and Design Tue, 07 Feb 2012 04:33:49 +0000 hourly 1 http://wordpress.com/ http://blog.coreycoogan.com/2010/01/28/holy-over-mocking-batman-a-natural-progression/#comment-104 Fri, 19 Feb 2010 21:11:36 +0000 http://coreycoogan.wordpress.com/?p=258#comment-104 Thanks for the comment James. Your tests should test the core logic that you are getting at. For example, a typical layered architecture might include some domain services that interact with entities. Don’t bother testing how the service method gets the entity, just test the logic and state changed by the service method. You may then have Application Services that are responsible for getting entities from repository and feeding them into the domain service. From that standpoint, an interaction test to ensure that the app service is opening a transaction or calling the proper domain service may be appropriate, but you wouldn’t need to assert any calls on your Repository and could Mock your domain service. Does this make sense? Let me know if you’d like to see some code and I will write a short post to include some.

]]> http://blog.coreycoogan.com/2010/01/28/holy-over-mocking-batman-a-natural-progression/#comment-103 Thu, 18 Feb 2010 19:51:12 +0000 http://coreycoogan.wordpress.com/?p=258#comment-103 So I’m at the realization now that interaction based tests with too many mocks yields fragile tests, but in the blog you don’t really describe what that next step is, just that “tests get simpler”. How do they get simpler? What do they look like?

]]>