Laboratory: Implementing Dictionaries with Association Lists

We should, of course, begin our exploration of code by designing unit tests for that code. Suppose we are focusing primarly on the primary operations of put, get, and remove.

Read through the tests that are there. Then note what aspects of the three methods we are failing to test. (You don't need to add these tests; just think about how the tests are incomplete.)

It's sometimes nice to read other people's code before we are biased by test results. So let's look at the underlying code.

a. Prepare to describe to someone else how the code is designed. What are the big-picture design decisions? How are different methods implemented? What are tricks that the designers have attempted?

b. Identify likely trouble spots in the code. What potential issues do you see?

a. Given your reading of the code and the tests, which tests do you expect to succeed and which tests do you expect to fail?

b. Check your answer by running the tests.

c. Correct any bugs in the code the tests have identified.

In an earlier exercise, you identified missing black-box tests. Write a few of those tests.

If the tests identify errors, correct the code.

Traditionally, when designing unit tests we focus primarily on the client's perspective of the code. But when we know the underlying implementation, we also have the opportunity to think about particular areas in which the implementation may be more fragile. Hence, we can design tests that focus on the implementation and not just interface. This approach is often called “white-box” or “clear-box” testing.

When you looked at the underlying implementation, you identified some potential trouble spots. Write a few white-box tests that explore those potential issues.