23: Lessons about testing and TDD from Kent Beck

Test & Code in Python - Een podcast door Brian Okken

Probeer Podimo de eerste 60!!! dagen gratis

Luister 30 dagen gratis naar exclusieve podcasts en duizenden luisterboeken

Categorieën:

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.

http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/

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.