Last updated on

Tests

Tests are a key part of robust software development, and you will get most valuable experience by writing your tests for your own code. For more focused training, however, we provide a few exercises below. Happy hacking!

As usual, ⭐️ indicates the most important exercises and questions; 🔥, the most challenging ones; and 🔜, the ones that are useful to prepare for future lectures.

You do not need to complete all exercises to succeed in this class, and you do not need to do all exercises in the order they are written.

We strongly encourage you to solve the exercises on paper first, in groups. After completing a first draft on paper, you may want to check your solutions on your computer. To do so, you can download the scaffold code (ZIP).

Understanding different kinds of tests

  1. Think of an event in your life that you had to rehearse or train for:

    • Which components of your preparation were most like unit tests (focusing on a single, minimal aspect)?
    • Which components were more similar to integration tests (focusing on a subsystem and exercising it from end to end)?
    • Which were more like system tests (exercising the whole system in conditions as close as possible to the real event)?
    • Was there any monitoring (detecting issues as they happen)?
  2. Classify the following tests into monitoring, unit tests, integration tests, system tests, and acceptance tests.

    1. Your dishwasher reports that it is low on salt.
    2. Your induction stove turns off due to a spill.
    3. A phone repair tech checks that all pixels on your phone screen are working by displaying a uniform-white picture.
    4. You make sure that your baking powder still works by pouring a bit of vinegar or a bit of hot water on it.
    5. While developing a robot, you make sure that your path-planning software works by running it in a simulator.
    6. Your phone indicates that you are low on space.
    7. You practice for a test by attempting to complete a mock exam within the allocated time.
    8. You demo your newly built robot to investors at a tech fair.

Debugging, testing, and refactoring all in one 🔥

In an attempt at making a boids callback better, we have implemented a quadtree data structure to hold boid collections. Quadtrees are a two-dimensional analogue of binary search trees: they are used to organize point clouds in a way that supports quick filtering and lookups (in boids, this would allow us to quickly determine which boids are close to each other, in much less time than a linear filter of all boids). You can see the complete implementation in src/main/scala/tests/QuadTree.scala.

Unfortunately, the lab release date is fast approaching (edit: passed), and we still haven’t written unit tests nor integration tests, let alone documentation. There’s even a missing function, contains!

Worse: one of our SAs reports that our implementation sometimes loses boids, and sometimes gets into an infinite loop. Oh, and there also seem to be performance problems.

Your task: help us fix it! We need to do the following:

  1. implement the missing function;
  2. add a documentation string to each function;
  3. add pre- and postconditions (require and ensuring) where relevant;
  4. write unit tests (testing a single function) and integration tests (testing collection of functions) to ensure that the quadtree works correctly;
  5. fix any bugs and performance issues that may pop up.

Oh, and when you’re done: patch boids to use the tree!

You will most likely find it useful to work with others. Don’t hesitate to create a thread on Ed to share documentation, tests, bugs, or ideas.

Good luck! Some tips: