|
|
|
|
|
|
by jakubp
3956 days ago
|
|
|
The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine! So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them) |
|
|
Arguments don't work. You need to build the tools that let your developers actually write sensible tests (i.e. tests which mimic user stories).
Once the tools are there the process becomes fairly natural and the upsides become obvious.
Some people call this BDD. It doesn't really matter what it's called, but it's generally a faster and less risky approach to programming.