Test Driven Development - bradyclifford/sdlc GitHub Wiki

TDD: Where did it all go wrong

Summary of the video includes the need to get back to TDD basics. Our tests should not know about our internal implementations. Decoupling that allows us more easily refactor.

Recall the TDD process: red, green then we always forget the Refactor step!
A test-case per class approach fails to capture the ethos for TDD
Adding a new class is not the trigger for writing tests
The trigger is implementing a requirement, a behavior!
Do not write tests for implementation details - these change
Don't bake implementation details into test! This allows us to refactor implementations without changing tests
Having coupled tests prevents ability to freely refactor
Only test the public interface, the module (even classes have a public interface)
- A unit test is too focused now on testing a "class" -> you end up mocking too much
- A class may be the facade (the module), but there are many cases where a collection of classes are implementation details
- Don't make everything public in order to test it
When refactoring, the last TDD step, you do not write new unit tests
- During the green phase, you write dirty code
- Then you refactor it into patterns, clean code, remove any anti-patterns, code smells, etc.

Only writing tests to cover the implementation details when you need to better understand the refactoring of the simple implementation details when you need to better understand the refactoring of the simple implementation we start with. But after, delete those coupled tests!