Software Engineering Radio

[...] 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.

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?

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?

[...] 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.