Automated software testing part 4: combining similar tests

Previous: part 3 – Next: part 5

You can also find the code below in the src/unit-test-2   dir of my blog code repository.

Today, you have been asked by your uncle to help him set up the new MegaBanana Slide in his Fun Park. The MegaBanana Slide is meant for children, but not too small children. Certainly not for adults. And you must take off your shoes before using it. Oh, and of course you are not allowed to go together with your friend – each child has to wait for its turn!

A child going down a pretty big slide

The MegaBanana Slide!

To prevent any accidents, the MegaBanana Slide has a sophisticated Child Measurement System, where any child who stands near the start of the Slide is measured. The results of this measurement are then fed into the Permission Granting System, which then opens the gate – or not.

Your uncle knows that you are a star programmer, so he has asked you to program the PGS according to his specifications:

  • only 1 child at a time
  • no shoes
  • no children under 90 cm (that’s about 3 feet)
  • absolutely nobody who weighs more than 125 kg (275 lbs)!

The PGS wants an object with a canUse  field and a reason  field. If canUse  is false , the reason is shown to the poor child who is not allowed to go down the slide.

Writing this code takes you all of 3 minutes and 42 seconds.

Easy peasy. But you know that your uncle is a nitpick, so you decide to write some unit tests (even though he has no clue what that term even means) to verify that your code does the right thing.

5 possible situations, so 5 tests. But this test code hurts your eyes. So much copy-pasting going on here, agh. You can do better.

Let’s make an array of test situations. We’ll give each one a name (to put in the it  description), the input of canUseSlide , and the expected output.

Excellent. You have separated the data from the test execution. It’s now easy and clear how to add another test. It’s even possible to put the test data in a different file.

However, your test file just went up from 68 lines to 78 lines. And there is still a lot of duplication.

In the test data, the expected result can be reduced to just the reason. During test execution, you can then create the expected result object from the reason (after all, canUse  is true  if the reason is empty, and false  otherwise).

Also, you decide to make a helper function to create the person objects.

This is the final version of your test file:

51 lines of lean and mean test code. The test data is very clear and compact. Not bad!

Your uncle installs your code on the PGS, and soon after, the MegaBanana Slide is fully operational. Everyone is happy!

Except that you still have this slight nagging feeling that it should be possible somehow to refactor the person  field of the test data so you can move the createPerson  calls from the test data to the test execution. But you can’t think of an elegant way…

This entry was posted in software development, testing and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.