In his talk TDD, where did it all go wrong, Ian Cooper pushes Kent Beck's original intention behind unit testing in TDD (to test behaviours, not methods of classes specifically) and argues for avoiding coupling the tests to the implementation.
In the case of behaviour like save X to some data source in a system with a typical set of services and repositories, how can we unit test the saving of some data at the service level, through the repository, without coupling the test to implementation details (like calling a specific method)? Is avoiding this kind of coupling actually not worth the effort/bad in some way?
Best Answer
Your specific example is a case that you usually have to test by checking if a certain method was called, because
saving X to data sourcemeans communicating with an external dependency, so the behavior you have to test is that the communication is occurring as expected.However, this isn't a bad thing. The boundary interfaces between your application and its external dependencies are not implementation details, in fact, they are defined in the architecture of your system; which means that such a boundary is not likely to change (or if it must, it would be the least frequent kind of change). Thus, coupling your tests to a
repositoryinterface should not cause you too much trouble (if it does, consider if the interface is not stealing responsibilities from the application).Now, consider only the business rules of an application, decoupled from UI, databases and other external services. This is were you must be free to change both structure and behavior of the code. This is where coupling tests and implementation details will force you to change more test code than production code, even when there is no change in the overall behavior of the application. This is where testing
Stateinstead ofInteractionhelp us go faster.PS: It's not my intention to say if testing by State or Interactions is the only true way of TDD - I believe it to be a matter of using the right tool for the right job.