Ask HN: How would one start doing TDD “properly”?
I was reading today a small rant by GeePaw (https://twitter.com/GeePawHill/status/1558159024520151041) and made me think that I don't feel I ever a) did TDD the "right way" b) ever found a good resource on how to do it. For people that to it, what would you recommend to your younger self?
4 comments
This book explains the theory and practice of TDD better than anything else:
https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
In particular that book considers the problem of retrofitting an existing system to have good tests, so it covers all the bases for a system that runs in production and is in front of customers. Feathers is particularly an advocate for fast tests, he thinks a 1ms test is a little slow.
A counter to that is some subsystems are prone to race conditions and a necessary test could be to stress the subsystem with 200 threads. This automated test is of great value but takes 30 seconds to run which is quick to do once but adds up to slower development cycles when you make any change.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
In particular that book considers the problem of retrofitting an existing system to have good tests, so it covers all the bases for a system that runs in production and is in front of customers. Feathers is particularly an advocate for fast tests, he thinks a 1ms test is a little slow.
A counter to that is some subsystems are prone to race conditions and a necessary test could be to stress the subsystem with 200 threads. This automated test is of great value but takes 30 seconds to run which is quick to do once but adds up to slower development cycles when you make any change.
While your question is about "doing TDD properly", do you mind if I suggest another approach?
Consider embracing a Risk Driven Development[0] philosophy.
This is where the highest risk to a project's success is addressed first, then the next highest, and so on, which drives risk to 0 and success to 1.
This begs the question, "what is typically the highest risk to a project's success?" This is always defining the (stakeholder) problem to solve. IOW, what would be the result if everyone involved had perfect knowledge of what needs to be done? From there, identification of what needs to be done next (risks/tasks/work/etc.) will flow.
Note that risks include non-technical concerns. Many times these are some of the biggest risks.
HTH
0 - https://www.methodsandtools.com/archive/agilesoftwarearchite...
Consider embracing a Risk Driven Development[0] philosophy.
This is where the highest risk to a project's success is addressed first, then the next highest, and so on, which drives risk to 0 and success to 1.
This begs the question, "what is typically the highest risk to a project's success?" This is always defining the (stakeholder) problem to solve. IOW, what would be the result if everyone involved had perfect knowledge of what needs to be done? From there, identification of what needs to be done next (risks/tasks/work/etc.) will flow.
Note that risks include non-technical concerns. Many times these are some of the biggest risks.
HTH
0 - https://www.methodsandtools.com/archive/agilesoftwarearchite...
I wouldn’t worry about doing it “properly.” Instead do what adds to overall quality and developer productivity. There’s no one size fits all formula.
Look up property-based testing, too. It helps you forget about coming up with specific test values and edge cases.
The Hypothesis library for Python has a pretty good docs explaining property-based testing and how to use it.
The Hypothesis library for Python has a pretty good docs explaining property-based testing and how to use it.