Just because you can test it, doesn't mean you should

added by dpeterson
12/15/2011 9:15:19 AM

4 Kicks, 267 Views

Samson Tanrena shares his thoughts on why choosing what to test, rather than simply testing all code, is an important step in shipping your product.


12/19/2011 1:38:19 PM
I tend to gravitate towards BDD style testing in which I write tests for discrete components, rather than specific functions etc. The tests I write tend to provide pretty good test coverage just by testing the functionality of the components. I don't rule out testing specific functions/etc that don't necessarily fall into a specific component or system, but I don't seek them out.

12/20/2011 8:39:17 AM
I refuse to obfuscate production code for the sake of testing - that makes me a hypocrite to some people but I have seen way too many well tested applications that are cumbersome and mind boggling to work in. I tend to focus most on integration tests that test how the application actually works and unit tests for pure business logic - I don't try to unit tests pieces of code where the majority of the complexity is really in the integration of two components. (controllers are a good example, we test our pages using Selenium but we don't have unit tests for controller methods)

12/20/2011 9:20:04 AM
The post has a different view than what I am used to. I feel component level testing and unit testing is definitely required. Preferably, these lower level tests should be automated. Duplication of effort may be there in integration and acceptance tests. But, this should not be a reason to not do component level testing.