• Choose a category
• All
• Classic-Fiction

By Root 1077 0

objects. If the pool is properly dishing out unique objects, none of their serial numbers should match. Note that this test only covers objects created as part of a single chunk. A similar test for multiple chunks would be an excellent idea.

void ObjectPoolTest::testExclusivity()

{

const size_t poolSize = 5;

ObjectPool myPool(poolSize);

set seenSerials;

for (size_t i = 0; i < poolSize; i++) {

shared_ptr nextSerial = myPool.acquireObject();

// Assert that this number hasn't been seen before.

CPPUNIT_ASSERT(seenSerials.find(nextSerial->getSerialNumber()) ==

seenSerials.end());

// Add this number to the set.

seenSerials.insert(nextSerial->getSerialNumber());

}

}

Code snippet from ObjectPoolTest\ObjectPoolTest.cpp

This implementation uses the set container from the STL. Consult Chapter 12 for details if you are unfamiliar with this container.

The final test (for now) checks the release functionality. Once an object is released, the ObjectPool can give it out again. The pool shouldn’t create additional chunks until it has recycled all released objects. This test first retrieves a Serial from the pool and records its serial number. Then, the object is immediately released back into the pool. Next, objects are retrieved from the pool until either the original object is recycled (identified by its serial number) or the chunk has been used up. If the code gets all the way through the chunk without seeing the recycled object, the test fails.

void ObjectPoolTest::testRelease()

{

const size_t poolSize = 5;

ObjectPool myPool(poolSize);

shared_ptr originalSerial = myPool.acquireObject();

size_t originalSerialNumber = originalSerial->getSerialNumber();

// Return the original object to the pool.

myPool.releaseObject(originalSerial);

// Now make sure that the original object is recycled before

// a new chunk is created.

bool wasRecycled = false;

for (size_t i = 0; i < poolSize; i++) {

shared_ptr nextSerial = myPool.acquireObject();

if (nextSerial->getSerialNumber() == originalSerialNumber) {

wasRecycled = true;

break;

}

}

CPPUNIT_ASSERT(wasRecycled);

}

Code snippet from ObjectPoolTest\ObjectPoolTest.cpp

Once these tests are added to the suite, you should be able to run them, and they should all pass. Of course, if one or more tests fails, you are presented with the quintessential issue in unit tests — is it the test or the code that is broken?

Basking in the Glorious Light of Unit Test Results

The tests in the previous section should have given you a good idea of how to get started writing actual professional-quality tests for real code. It’s just the tip of the iceberg though. The previous examples should help you think of additional tests that you could write for the ObjectPool class. For example, none of the tests deal with allocation of multiple chunks — there should definitely be coverage of that functionality. There also weren’t complex tests that acquired and released the same object multiple times.

There is no end to the number of unit tests you could write for a given piece of code, and that’s the best thing about unit tests. If you find yourself wondering how your code might react to a certain situation, that’s a unit test. If a particular aspect of your subsystem seems to be presenting problems, increase unit test coverage of that particular area. Even if you simply want to put yourself in the client’s shoes to see what it’s like to work with your class, writing unit tests is a great way to get a different perspective.

HIGHER-LEVEL TESTING

While unit tests are the best first line of defense against bugs, they are only part of the larger testing process. Higher-level tests focus on how pieces of the product work together, as opposed to the relatively narrow focus of unit tests. In a way, higher-level tests are more challenging to write because it’s less clear what tests need to be written. Yet, you cannot really claim that the program works until you have tested how its pieces work together.

Integration Tests

An integration test