When I first learned unit testing and Test Driven Development, test frameworks were very light and mocking frameworks were just coming into the picture. I was writing a lot of C++ back then, and if I wanted a mock I would implement my class interface and link my test to the mock version instead of the production version. Fast forward 15 years and we have extraordinarily advanced mocking frameworks (and I mostly write Java these days). While new libraries have come and gone, Mockito remains my favorite. It has a good balance of a straightforward syntax and a very complete feature set. In fact, a bit too complete if you ask me.
A big part of writing good automated tests is understanding why to write each test. While this seems obvious, people rarely think about it. When I write a test, I make sure that it achieves at least one of the following goals:
- Verify that the product meets the business requirements
- Give cover for future change
- Document intent