Comments by "Brent Jacobs" (@br3nto) on "Why Would Anyone Hate TDD? | Prime Reacts" video.

16:31 also, Dave focuses on tests for expected behaviour, not expected failure. So if failure is expected behaviour, he’d write tests that verify the failure is happening in an expected way. Make sense?
2
4:27 and 16:22 I think Primeagen is not understanding Dave’s approach. Dave’s TDD is much more atomic than testing an entire complete function, edge cases and all. In the first TDD iteration for writing a function, a function will have 0 edge cases, in the next, a new test added, to test an edge case which will fail at first, then the function is updated to meet the new expected behaviour of the two tests, rinse and repeat. You don’t write the entirety of the behaviour of the function up front, you build it up piece by piece. So a buggy test isn’t really likely because it is so atomic. Now you might argue that the tests are then too fine grained and brittle, however, they test the functionality that is expected of the program and the stakeholders, so if a requirement changes, you remove the no longer applicable tests and one by one add new ones with the new requirements.
1
22:23 yeah that’s the point of TTD for existing code… it forces you to update the code in ways that makes it testable, which in my experience, does actually make the code better and nicer to work with and improve over time. All code that can’t be tested is difficult code to work with and to change because it’s just so highly coupled to everything around it. Adding TDD for code like this forces the decoupling and improves the design over time. It just takes a really long time… sometime it effectively equates to a full rewrite… but you can do it very piecemeal, so easy to prioritise other more important dev work.
1
23:02 I assume if testing embedded systems, you’d actually test the expected behaviour of the embedded system rather than mocking it.
1
41:51 If tests are testing behaviour, then it should be a relatively easy refactor. A refactor may involve changing the method signatures or design structures, but the behaviours being tested remain. So the tests need to be refactored to ensure all the behaviours are still being met by the changes. This is fundamentally the Refactor step. Improving the design, and using the existing test to see what you broke, then fix it. But it also forces you to make smaller refactoring changes, which in theory, is better for stability, and the sanity of the other developers who are also making code changes.
1
44:55 the problem with test driven debugging is that your code needs to be in a state that is already testable… if it’s not, then how do you even add the debugging tests? Catch 22.
1