Episode 167: The History of JUnit and the Future of Testing with Kent Beck
Recording Venue: Skype
Guest: Kent Beck
Host: Martin
In this episode we talk with Kent Beck about this tiny little thing he created many years ago and that has changed the daily work of many many programmers in the world: automated unit testing and JUnit. We briefly revisit the history of JUnit, talk about how things began and what has happened since then. We discuss test-driven development (TDD), talk about when to do TDD and when not, and chat about experiences in the wild. The episode closes with some personal thoughts about the future of testing and software engineering in general.
Links:
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | RSS
SE Radio Alerts
[…] This post was mentioned on Twitter by Kent Beck, Michael Easter, Sebastian Sanitz, Martin Lippert, Martin Lippert and others. Martin Lippert said: RT @seradio: New episode: Episode 167: The History of JUnit and the Future of Testing with Kent Beck http://bit.ly/aQvkBu […]
Your site is totally unreadable in Firefox. OK in Chrome.
Looks fine if I open it in Firefox on Windows and Mac. What version and OS are you using?
Looks fine in Firefox under Linux too!
I missed a topic in your podcast: test coverage tools like clover (every source line has to be tested at least once). I’ve worked in a project where this was an dogmatic issue. My feelings were, that we wasted a lot of time on trivialities. Is there a golden mean, a common consensus on that problem?
I don’t know what the common consensus on that problem is. My experience is: if you really do test-driven development, the test coverage of your code must be quite high (because you implement code to get the test green). If there is no test failing, you don’t work on the production code… 🙂
Having test coverage as a metric without any real meaning doesn’t make much sense to me. Doing test-driven development to automatically get a high test coverage makes a lot of sense to me.
If you are interested in the ‘rules’ feature mentioned in the interview you might be interested in these blog posts. (Obviously this is self marketing, but hopefully of the useful kind):
http://blog.schauderhaft.de/2010/08/15/use-cases-for-junit-rules/
http://blog.schauderhaft.de/2009/10/04/junit-rules/
[…] Vynikajúci rozhovor s Kentom Beckom nájdete na stránkach SE-Radio.net. […]
[…] Кент Бек (Kent Beck) рассказывает об истории JUnit и будущем тестирования (подкаст); […]
At one point in the interview the question came up of why teams have tests they don’t run and/or tests that are permanently broken. This seemed like a complete mystery to Martin and Kent.
This issue comes up all the time in practice especially when your tests are not beautifully designed. You have some big complicated test that is failing after some refactor. In all probability the problem is with the test not the code under test. You are under deadline pressure. You have other feedback that tells you everything is working. Do you stop and spend two days debugging the test or do you just comment out the test?
Hey Matt,
I know such situations from practice. And I know that some people tend to comment out the test, if they are under time pressure. But my observation is that this is often not the real problem. Many times its just a symptom of another, often bigger problem: the team is not test-driven and hasn’t an appropriate Definition-of-Done that includes tests. Skipping tests under time pressure demonstrates that tests aren’t an integral part of programming for them. And skipping tests produces technical debt, from my experience. You can do that, but you loose the value that test produced in the past. And you create a little time bomb for the team… If I need to create that technical debt for whatever reason or pressure, I would hurry to fix that before implementing the next feature.
Just my 2 cents,
Martin
[…] and try a few episodes out. I just did that with Software Engineering Radio, mainly to hear this interview with Kent Beck. He is the person behind JUnit. In my job I try to to test driven development wherever possible […]
Great episode. Unexpected bonus hearing Kent Beck use Goldie locks and the three bears as a metaphor for when too many tests are involved. I am looking forward to a discussion on Continuous Deployment. I agree with this being a large topic for future concerns and knowledge. TDD adoption is social and there still exists a mire of fear behind its adoption. Fear of the unknown. Every professional who epitomizes their contribution to the craftsmanship of creating software needs to listen to this podcast. Thanks host and Beck for this talk!
John
Very interesting podcast for a young developer like me. Often I’m confronted with smaller development tasks where I’m not really sure how to solve them and work more exploratory. I got my confirmation that writing tests in that case isn’t necessary if there is not clear whether to use it in further development. Thanks Mr. Beck and SE-Radio.
Johannes
[…] Software Engineering Radio: Episode 167: The History of JUnit and the Future of Testing with Kent Beck […]
Very interesting podcast for a young developer like me. thank good pratik pasta tarifi
[…] In the episode 167 of the Software Engineering Radio, Kent Beck discusses about this tiny little thing he created many years ago and that has changed the daily work of many many programmers in the world: automated unit testing and JUnit. […]
[…] Shows include: Game Development with Andrew Brownsword (Electronic Arts), The History of JUnit and the Future of Testing with Kent Beck, Rich Hickey on Clojure, and my favorite, Software Craftsmanship with Bob Martin. Check the site […]
[…] #167: The History of JUnit and the Future of Testing with Kent Beck – it was nice to hear on this episode that even Kent Beck doesn’t test drive when he’s doing highly exploratory work. […]
[…] by staying focused on the software being written. As an aside Software Engineering Radio did an interview with Kent in 2010, the interview is well worth listening to if you want to get a sense of Kent’s […]
Thank you a lot for such really valuable information found in the your blog. You can get info on Web Application Testing as well with some guidelines with different way of thinking.
[…] Episode 167: The History of JUnit and the Future of Testing with Kent Beck […]
[…] einem sehr hörenswerten Podcast auf se-radio.net mit Kent Beck (er hat zusammen mit Erich Gamma JUnit erfunden) lässt sich Mr. Beck auch über einen Grund aus, […]
[…] Kent Beck – The History of JUnit and the Future of Testing with Kent Beck – Episode 167 […]
Great common sense here. Wish I’d thguoht of that.
[…] Kent Beck – The History of JUnit and the Future of Testing with Kent Beck – Episode 167 […]
Great post-Kent Beck. Thanks for sharing it.
nice podcast. However, now I’m now using JUnit only for reporting purpose as a plugin in Jenkins.
A great podcast. Thanks for sharing it.
Thanks for posting useful information. Your Blog helps to clarify a few terms for me as well as giving. Great article and interesting