Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 516 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Paying Attention

05.09.2010
| 3308 views |
  • submit to reddit

Jeremy Miller tweeted earlier in the week about the dangers of using an auto mocking container and how it can encourage sloppy design:

That whole "Auto Mocking Containers encourage sloppy design" meme that I blew off last week? Seeing an example in our code.

I haven't used an auto mocking container but it seems to me that although that type of tool might be useful for reducing the amount of code we have to write in our tests it also hides the actual problem that we have – an object has too many dependencies.

By hiding the creation of stubs/mocks for those dependencies in our test we are addressing the effect and not the cause i.e. we are bear shaving.

Jeremy followed this up with a couple of quite insightful comments:

You know though, I still think it comes down to you being responsible for paying attention.

It's no different than still having to worry about DB optimization even though the ORM is shielding you from the details

Another somewhat related situation where I've noticed a similar problem is when we have several tests which require a certain method to be stubbed out and in the interests of reducing duplication we pull that up into a setup method.

While this achieves that goal it also means that there is information that is hidden away from us when we read each of our tests.

One approach that I've seen encouraged is that we should never use a setup method so that we have to create everything we need for our test in the test body.

I quite like this approach because it encourages us to see any problems that we're creating with respect to writing difficult to test code but quite often what ends up happening is we'll copy and paste tests because there's more code to write for each test.

I'm coming to the conclusion that there's no one approach that will stop us making design mistakes and that as Jeremy says, we need to make sure that we pay attention to what we're doing.

 

From http://www.markhneedham.com/blog/2010/05/09/coding-paying-attention

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: