Clearly, I don't understand unit testing. This is fine, considering I've never done it before. I'm starting a new project, and wanted to bake unit testing into it from the beginning, so I'm looking to learn.
I had always equated unit testing with code coverage, thinking that you should have unit tests which cover every function/method in your application, but clearly this isn't the case and I've completely misunderstood the concept.
So,
- What sorts of functions benefit from unit testing?
- What sorts of functions shouldn't be unit tested?
What should be covered with unit tests?
Unit tests should validate all of the details, the corner cases and boundary conditions, etc. Component, integration, UI, and functional tests should be used more sparingly, to validate the behavior of the APIs or application as a whole.
What makes a good unit test?
Good unit tests are independent and isolated They test one thing at a time, ideally with one assertion. They don't cause side effects. They certainly don't rely on side effects. You can run them in any order and they still pass.
What are two limitations of unit testing?
Limitations of Unit Testing Unit testing cannot detect integration or interfacing issues between two modules. It cannot catch complex errors in the system ranging from multiple modules. It cannot test non-functional attributes like usability, scalability, the overall performance of the system, etc.
I don't have a complete answer (I'd love to hear anybody who does, honestly), but can at least toss out a few points...
- You're already on the right track by driving the development from tests in the first place. Retro-fitting unit tests into existing applications is difficult and rarely provides real benefit (instead often gives a false sense of code coverage). Proper TDD is always a forethought, never an afterthought.
- I wouldn't bother testing private functions. Various code coverage tools may say it's left untested, but if it's private then its functionality should be tested by testing the public methods. Private methods are internal and not part of the API, nothing outside of the class (even the tests) should know or care about them, as they can easily change if the implementation of that class is changed.
- Focus on the exposed API of your code. Write tests against your interfaces, not against your classes. The classes themselves are later implemented and tested against the tests.
- Finally, and very importantly, study what you're doing and what its benefits are. Writing unit tests isn't a brown-and-serve process. One doesn't achieve good test coverage by simply writing tests, but by understanding TDD and how to implement it. It'll take practice. One suggestion I would give is to do a proper TDD project and also try to retro-fit tests into an existing project. We can tell each other all day that the former is better than the latter, but by doing both you can actually discern the differences and get a better understanding of why it's better. This will bring you beyond just writing the tests and into being more of an expert of TDD and what it really brings to the table. Anybody can write tests, but all too often they're just wasting their time unless they really understand what's going on.
Menu
889
