Joseph Wilk
My feedback
1 result found
-
12 votesJoseph Wilk
supported this idea
·
An error occurred while saving the comment
Joseph Wilk
1 result found
Joseph Wilk
supported this idea
·
Interesting thought. I'm still forming ideas about shared lessons but perhaps if I got down some of the aspects I feel important in TDD we might extract something.
One of TDDs key aspects is that you express in plain English the behaviour of a unit before the unit exists. What makes that even stronger is you pair on writing the test. So this forces very early on a discussion ("should it really do that?").
In TDD we also often use a ping pong style pairing. One person writes a test and then the other person has to make that test pass and so on. Again this forces discovering unknowns, as the person writing the code does not have the same mental model as the person who wrote the test.
There is a mentality of failing fast and making the smallest possible step in order to complete the test. Often to the scale of doing something very quick and dirty and improving as you build further tests.
One key difference I see is that with TDD the tests persist, and provide useful feedback throughout the lifetime of the units. Every hypothesis is validated upon every change. The tests often provide a form of documentation for people to understand how something works.
Making things easy to test forces us to change the way we build our software. It forces the principles of isolating external dependencies, avoiding coupling between different units, working in small composable units. TDD helps us discover the smells of bad design in our system.