Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In the context of Continuous Integration, I need to teach unit testing to a 20-people audience of programmers.

Everything will be all right, but I am still trying to find the perfect unit testing example.

More than writing tests like a robot, I want to show that unit testing can help prevent very subtle errors. I am thinking of the following scenario to happen when doing a live TDD demo:

  • the test cases would already be written,
  • we would have to write methods together,
  • most of us would naturally have forgotten to handle a specific case for a method,
  • everyone would then be surprised, when seeing that all tests don't pass,
  • the failing test would make us think more and realize that we forgot an important case.

My question will probably end up as "too broad" or "not clear what you are asking", but we never know, one of you might have a great idea. Your answer can use Java and JUnit, though any other language will be fine since only the idea matters.

share|improve this question

closed as too broad by gnat, Bart van Ingen Schenau, GlenH7, Michael Kohne, Glenn Nelson Nov 3 '13 at 18:28

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

Bounds checking on strings is always a good one, especially on things where ToUpper and its kin behave differently in different locales. –  Telastyn Oct 30 '13 at 13:52
The Java Puzzlers might contain some good corner cases for you to introduce in your training. There are plenty of videos on YouTube (such as this one) with the puzzlers. –  Laf Oct 30 '13 at 14:47

2 Answers 2

I ran into a live bug yesterday that might fit what you're looking for. The method reads the contents of a directory using java.io.File.list() and processes (by at some point calling File.open()) anything that ends with extension '.INT'. The way it checked for that is...

if ( (currFile.toUpperCase().indexOf(".INT") == currFile.length() - 4) )

Recall .indexOf() returns -1 when the string isn't found, and then consider what .length()-4 is for a three letter file or directory. Bonus points when a three letter directory only shows up as a result of another weird edge case. That code ran for 6 years without incident, and then blew up as a result of a faulty reinstall (already during a crisis) of the program it supports.

TDD may not have caught that bug, but between the mindset change to 'thinking about edge cases' and potentially hitting bugs like that with test coverage, I'd happily take the reduced rate of errors across any amount of the codebase.

Edit: If you think that might be too much of a softball, you can take a similar track as this answer. In the second half it mentions the edge case for finding any extension when given a path that has a '.' in a directory, but the file name itself has no extension. I feel like that one's slightly more obscure, and less likely to get picked out of thin air during a discussion/presentation.

share|improve this answer
Your example is indeed very interesting but as you said, TDD may not have caught that bug! –  Stéphane Bruckert Oct 30 '13 at 14:52
TDD always has a chance of missing bugs, the goal is to prevent as many as you can and stop old bugs from coming back. Expecting or attempting 100% coverage is incredibly costly. Put another way, it's impossible to test for important possibilities nobody is aware of unless you exhaustively test the entire input space. –  Snagulus Oct 30 '13 at 14:59

I had similar problem in the past. I used a bit different approach though. I wanted to show how unit tests can actually save time.

For that purpose I created an example of simple validation password match validation. While demoing this code I was able to show how easily we can spot an error without running the application. I showed the old way approach - when you write your code and then run it and then the example with writing the tests.

This example is very simple, because I was showing it mostly to students, unexperienced programmers (not only Java) and during rather short talks (up to 1h). I received a lot of positive feedback. And I think plenty of people was able to understand why they actually need to test their code. Real example is a must have, in my opinion.

I can imagine that with a validation example you could find the way to show subtle example. E.g. you test 3 out of 4 variations of validation and when you run the code you test it against the missing one to show why it is so important to think of all crucial test cases.

I used this code for my, rather simple, presentations: https://github.com/kolorobot/unit-testing-demo

Presentation itself (in Polish) can be found here: http://www.slideshare.net/RafaBorowiec/testowanie-jenostkowe-unit-testing

I hope it helps.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.