Clean Test Design
How to design your tests so that they are maintainable, valuable, long-live, and help you develop defect-less code?
WORK IN PROGRESS
Stuff to include
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
acceptance tests
make sense to the business (though usually written by devs), can form the basis of a system of "living documentation)
Ref
Topics
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.”