TDD makes you a better everyday developer by Jesse Kershaw
(link)Summary
Jesse Kershaw explains test-driven development as a practical skill that helps developers write better everyday code, even if they do not use TDD all the time. The talk frames good code as correct, understandable, maintainable, testable, and efficient, then shows how TDD supports those goals through short feedback loops, safer refactoring, and clearer design. Using a live IntelliJ demo, Kershaw walks through the red-green-refactor cycle with a simple `Greeter` example, showing how tests drive implementation and incremental improvement. He also discusses why good test assertions matter, how tests can serve as documentation, and how TDD can improve API design, pair programming, and confidence during optimization. The talk closes with the idea that TDD is a way to practice writing good code, not a rigid rule that every developer must follow.
Key Takeaways
- TDD means writing a failing test first, implementing the smallest change to pass, then refactoring safely in small steps.
- Good code is not just correct; it should also be easy to understand, easy to change, easy to test, and efficient.
- Tests written with TDD provide tighter feedback loops and help shape better APIs and cleaner design.
- Well-written assertions and parameterized tests produce failures that are easier to debug and maintain.
- Tests can act as living documentation because they show how code is meant to be used and what behavior is expected.
- TDD supports incremental refactoring and reduces risk when improving performance or changing existing code.
- The talk argues that TDD helps you practice better development habits, even if you do not use it in every project.
Sections
What TDD Is and Why It Matters
The talk defines test-driven development as writing a test first, then writing the minimum code needed to make it pass, and finally refactoring. Kershaw contrasts this with writing tests at the end as an afterthought, which is often harder and less useful. He emphasizes that TDD is a way to learn and practice better development habits, not a mandate to use it in every situation.
Live Demo: Red-Green-Refactor with a Greeter
A live coding demo in IntelliJ shows the basic TDD loop using a simple `Greeter` class. The test is written first, the IDE helps create missing classes and methods, the test initially fails, and then the minimal implementation is added to make it pass. The demo extends the behavior with another test, then refactors the code while keeping the tests green, illustrating the red-green-refactor cycle in practice.
What Good Code Looks Like
Kershaw describes good code as correct, understandable, maintainable, easy to test, and efficient. He explains that these properties are related: code that is easy to understand is often easier to change and easier to test, and tests help preserve correctness. He also notes that in environments with high turnover, readable and maintainable code is especially important.
Benefits of TDD
The talk highlights several benefits of TDD: improved code coverage with real behavioral validation, shorter feedback loops while designing APIs, and a natural fit with pair programming. Kershaw also frames TDD as a scientific method for software development: hypothesis, experiment, conclusion. This structure helps developers reason about code changes in a disciplined way.
Better Assertions, Better Test Design
Kershaw argues that TDD helps developers write more helpful assertions because failures happen early and often. He compares weak assertions that are hard to debug with more specific test output that immediately points to the problem. He recommends using assertion libraries, adding failure messages, and using parameterized tests when appropriate. He also advises not to over-refactor test setup too early; copying and pasting in tests can be acceptable if it keeps them clear.
Tests as Documentation and Refactoring Safety
The talk explains that comments can become stale, but tests fail when behavior changes, so tests are a more trustworthy form of documentation. Well-structured tests show how to use a class and what outputs to expect. TDD also encourages continuous incremental refactoring, which lets developers improve code safely instead of postponing cleanup until later.
TDD, Change, and Performance
Kershaw discusses how TDD helps avoid large, hard-to-change designs by encouraging the smallest useful implementation first. This reduces the temptation to build large abstract hierarchies too early. He also notes that while TDD does not automatically make code efficient, it provides a safety net for optimizing code and experimenting with performance changes, including benchmarking support in Go.
Main Message
The closing message is that TDD is a practice tool: it helps developers build the muscle of writing testable, understandable, and maintainable code. The code quality comes from the developer, not the technique itself. TDD is presented as one valuable way to improve, not a religious requirement.
Keywords: test-driven development, tdd, red green refactor, unit testing, java testing, junit, hamcrest, test assertions, parameterized tests, code coverage, pair programming, refactoring, maintainable code, testable code, api design, scientific method in software development, go microbenchmarking, software craftsmanship, developer productivity, cern software engineering