@Kanekotic like most software development practices I feel #TDD has a time and a place.
I believe any nontrivial code base will benefit from TDD with *fewer* bugs and cleaer code however things like rapid prototyping and exploratory work that will be thrown away later can be drastically slowed down.
I also, personally, find it tricky to learn a new language, library or framework via TDD and instead try to grok the fundamentals then come back to testing after I've managed to get a few hours of experience under my belt.
Ultimately TDD is another tool #agile teams can choose to utilise or not.
Yeah, I agree and try to TDD anything that'll be in prod. I am a TDD proponent! 🙂
Avoiding over engineering is indeed another great reason to use TDD.
Years of being a consultant have shown me you don't need TDD to build a production system but you'll have a considerably more maintainable system if you do!
@Kanekotic @tomheyes
from my point of view, doing correct TDD like uncle bob's trying to propagate is not so easy because what exactly TDD, which activities, steps developers have to follow in order to get TDD label?
Important is that we really care about writing tests for our software in order to help ourselves and others
@chicuongle @tomheyes i will have to disagree a practice is not a seniority related subject, is the same as an aeronautical engineer does not need to use tools from 1950 and risk crashing planes.
TDD is a design tool, while testing is just that. It is possible to have 100% coverage and have no working software, and it to be too complex to understand and maintain.
The problem of seniority is a different one, and is in the inability of experienced people to pass that knowledge to others by also using practices that have demonstrated not to be optimal like PRs (vs pair programming)
@Kanekotic @tomheyes I mean that TDD is difficult to understand and use by junior developers, not that TDD can only used by senior developers. By using TDD as a design tool, we have to think about other "bilities" because TDD increase testability of software, but not all other "bilities".
@chicuongle @tomheyes but TDD is not about testability, If it was about testing it would be called TDT. The main intent of TDD is to do minimal code to resolve a use case, not tested code. Because of this the process itself improves other ilities like for example readibility.
In my experience seniority is actually a burden as people tend to overengineer quite a lot, so a few ilities are overused and overvalued, for example reusability.
@tomheyes I fully agree with you that are cases where TDD is not a good fit.
Nevertheless, I believe it should be always used for production code as its not a testing tool its a design tool that helps ensure there is no overengineering.