How to design your tests so that they are maintainable, valuable, long-live, and help you develop defect-less code?
WORK IN PROGRESS
Split into (ref.: Cohen’s Testing Pyramid)
focused private|public unit tests
- test individual methods in isolation; focused, independent => can test more cases, more easily
module-level integration tests
- test collaboration of few classes (real classes, no mocks) to verify they collaborate together as expected - verify that the methods tested in unit tests are actually used
end-to-end integration/functional tests
- similar to the previous one but on a higher level; what we choose as our ends depends on the risks invovled
- make sense to the business (though usually written by devs), can form the basis of a system of “living documentation)
- How to Create Maintainable Acceptance Tests
- Principles for Creating Maintainable and Evolvable Tests
- Help, My Code Isn’t Testable! Do I Need to Fix the Design?
- Do You Know Why You Are Testing?! (On The Principles Underlying TDD)
- Mocks: Yes or not? (=> when yes?) - read Martin Fowler’s Mocks Aren’t Stubs that discusses mockist vs classical testing; quote (emphasis mine): “A classic test only cares about the final state - not how that state was derived. Mockist tests are thus more coupled to the implementation of a method. Changing the nature of calls to collaborators usually cause a mockist test to break.”