In this podcast we talked about TDD with an expert in the domain. Frederik has been in the industry for more than 15 years and he is an advocate of Clean Coding practices and teaches Software Engineers how to write better code. Watch the video to see what Frederik had to say on TDD. We also did live coding using TDD to add a new feature to a E-Commerce product application.
- As Uncle Bob explains TDD as a 3 step process (Red – Green – Refactor Cycle)
- You must write a failing test before any production code.
- You must NOT more of a test than is sufficient to fail, or fail to compile.
- You must NOT write more production code than is sufficient to make the current failing test pass.
- Why do we need TDD? TDD is a great way to approach problems as it breaks down the problem into many smaller steps which reduces the cognitive burden from the developers. A problem is solved and coded one step at a time. At a side effect you also get good test coverage.
- Test coverage is just a number and only that number does not represent any key metric regarding the quality of the code. A 95% test coverage may not mean anything regarding quality, if the tests aren’t effective.
- Write tests around the expected behaviour and use un-mocked code as far as possible. Mocking should be done when it is necessary and you can’t move forward without it.
- Start from the outer most layer “The external APIs” and go inwards i.e. controller -> service -> dao etc.
- Refactor code in smaller steps. Changing 1000 lines is NOT refactoring it is disrupting the whole codebase. Refactoring must be easy to test is isolation and easy to review.
- While live coding we also discussed how it doesn’t always make sense to create separate classes for each layer of the application. It must be done when needed, but not when the book says.
- Live coding example showing a near real world application of TDD and some pitfalls.
Please like, share and subscribe to The GeekNarrator youtube channel -> https://www.youtube.com/channel/UC_mGuY4g0mggeUGM6V1osdA