Posts
1150
Comments
891
Trackbacks
1
YAGNI applies to testing as well

Suppose you have a class related to inventory with a method that takes in a quantity, and as such, that quantity cannot be negative.  Should you create a test that proves the method throws an exception (or however you think the method should behave) when a negative quantity is passed to it?

<digression>Note that it is very easy to slip into a mistake of asking what ‘the right thing’ to do is, as if there has to be a single correct answer.  ‘The right thing’ often depends on the context.  Universal truths (related to morality anyway) are those where ‘the right thing’ is in fact the same thing in all contexts.  But I digress.</digression>

Given the simplicity of the example, it is easy to answer yes, since it will take all of 20 seconds to write it.  But from a general perspective, you should really apply YAGNI.

TDD tends to lead you to think in terms of 100% code coverage and testing all possible edge cases and what not, and this is why it generally sucks.  You shouldn’t be thinking in those terms.

If you think instead in terms of how you application behaves and the scenarios the users will encounter.  Is it possible for the application to pass in a negative quantity?  If it isn’t, then you don’t need to test for it.

Now, of course, the specific simplistic example is besides the point.  You should always be thinking in terms of cost effectiveness and risk.  What does your application do?  What is the cost of trying to achieve 100% code coverage?  What is the risk involved in not testing edge cases?  For some applications, I think it is perfectly acceptable to create specifications that test your application as you are building it and then ‘throwing them away’, taking away the safety blanket, so to speak (and what I really mean here is not actively maintaining them).  When dealing with applications in a financial institution where potentially millions of dollars could be at risk, maybe not so much.

Don’t practice test-driven development, even if you test and test aggressively.  Your development should be driven by business needs instead.

caveat: if you are building a framework, you really should be thinking in terms of 100% code coverage because your ‘business needs’ will drive you there.  If you are offering a public API, then you should test all the possible ways it could be used.  This is different from when you control the application, where you control how your APIs are used.

posted on Friday, April 22, 2011 12:11 PM Print
Comments
No comments posted yet.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 4 and 4 and type the answer here: