If tests are written first, (_and_ the dev has a good eye for design, which is not always given) then it is likelier that you will write a more ergonomic interf

If tests are written first, (_and_ the dev has a good eye for design, which is not always given) then it is likelier that you will write a more ergonomic interface (e.g. methods having smaller number of parameters/dependencies, "intention revealing names", [0] etc..). In a unit-testing paradigm, this also means that you will need to inject the unit's dependencies so that it can be driven into specific states by each test in the suite, encouraging dependency inversion and the open/closed principle (as given by Uncle Bob [1]; note that with dependency inversion it becomes possible to vary the behaviour of the unit in test vs. production environments simply by specifying different dependencies without modifying the unit's code itself). If the dependencies are too cumbersome or even impossible to set up, then the test reveals something about the design (e.g. high coupling). Of course, it's also possible to just grin and bear the pain of tests being too difficult to write, without actually resolving the design problems revealed by the test... [0] https://wiki.c2.com/?IntentionRevealingNames https://wiki.c2.com/?IntentionRevealingNames [1] https://web.archive.org/web/20060822033314/http://www.objectmentor.com/resources/articles/ocp.pdf https://web.archive.org/web/20060822033314/http://www.object...