This is the transcript for Test & Code, episode 23: Lessons about testing and TDD from Kent Beck
Kent Beck’s twitter profile says “Programmer, author, father, husband, goat farmer”. But I know him best from his work on extreme programming, test first programming, and test driven development. He’s the one. The reason you know about TDD is because of Kent Beck.
I first ran across writings from Kent Beck as started exploring Extreme Programming in the early 2000’s.
Although I don’t agree with all of the views he’s expressed in his long and verbose career, I respect him as one of the best sources of information about software development, engineering practices, and software testing.
Along with Test First Programming and Test Driven Development, Kent started an automated test framework that turned into jUnit. jUnit and it’s model of setup and teardown wrapping test functions, as well base test class driven test frameworks became what we know of as xUnit style frameworks now, which includes Python’s unittest.
He discussed this history and a lot more on episode 122 of Software Engineering Radio. The episode is titled “The History of JUnit and the Future of Testing with Kent Beck”, and is from Sept 26, 2010.
I urge you to download it and listen to the whole thing. It’s a great interview, still relevant, and applicable to testing in any language, including Python.
What I’ve done in this podcast is take a handful of clips from the interview (with permission from IEEE and SERadio), and discuss the clips and my opinions a bit.
The lessons are:
- You’re tests should tell a story.
- Be careful of DRY, inheritance, and other software development practices that might get in the way of keeping your tests easy to understand.
- All test should help differentiate good programs from bad programs and not be redundant.
- Test at multiple levels and multiple scales where it makes sense.
- Differentiating between TDD, BDD, ATDD, etc. isn’t as important as testing your software to learn about it. Who cares what you call it.
Interview with Harry Percival
If you develop and/or test web applications, especially django, you will probably enjoy this episode.
Whatever your stance on the merits or pitfalls of Test Driven Development, I think it’s worthwhile and educational to pay attention to a discussion that’s going on lately.
Testing is crucial. But is unit test focused TDD the right path?
I care about the conversation about TDD because I see serious flaws in the conventional understanding of TDD.
Much of the current view of TDD includes:
- Units are tested in isolation of the rest of the system.
- Unit tests are more important than any other form of testing.
- A “unit” is a class or a function. Nothing larger is a “unit”.
- If you test more than one class, that’s an integration test.
- If you test from the API with all resources, that’s a system test. Let QA deal with that later. Isn’t that exactly where waterfall failed?
- You can’t write any production code without a failing test.
- You have to write only one test at a time, and it must fail.
- Tests have to be fast.
- Therefore, they cannot touch hardware, the file system, other services, or database.
- Tests should be short.
All of this rubs me the wrong way.
I’ll get to my thoughts later, but my concern about this cemented view of TDD caused me to be very interested in the current talks.
On to the discussion
I came in after the 2nd video, while doing research on Agile and TDD.
I’m not sure if the order matters, but here’s a list of what I know about the discussions.