02.08.2023 **Tags** #areas/dev/software-design # Test-Driven Development John Ousterhout argues that, while unit tests themselves are very valuable, TDD focuses too much on getting a specific feature working, instead of finding the best design. This automatically leads to [[Tactical vs. Strategic Programming|tactical programming]]. Therefore, it is better to achieve the design first and get the abstractions right. Then write unit tests. ## Personal Opinion I think there are times for TDD and times for doing the design first. I personally lean towards not doing TDD all the time, because I feel the exact kind of distraction from the actual design work while managing red-green-refactor loop and researching about how to create mocks, fakes and the test setup in general with whatever language I am working with. I also agree with Ousterhout's opinion that unit tests should always be created as part of the development process. It is simply not mission critical if tests are written after some code has been implemented. On the other hand, if too much time passes between writing code and covering it with tests, the risk increases that the tests either end up bad or are forgotten entirely. But if the design is relatively clear from the start, and you are experienced with the test framework, TDD can definitely save you some hassle by immediately providing you with a test suite for the entire feature you are about to build. ## Contrary Opinion When using TDD, you are forced to design good interfaces/abstractions. The reasons for that is, if your abstractions is not good, the test setup automatically becomes cumbersome. A test that is easy to setup implies an interface that is more cleanly decoupled from other parts of the application (since you don't need to initialize many dependencies that are actually not-needed). # References [[A Philosophy of Software Design (John Ousterhout)]]