Boost logo

Boost Users :

Subject: [Boost-users] Boost.Test - Advice needed on structuring tests
From: pholding (pholding_at_[hidden])
Date: 2010-04-09 14:38:22


I'm looking for some advice/recommendations on how I should structure a suite
of unit tests for a project I've been working on. The code uses exceptions
rather than return codes. Essentially the code is a wrapper around a C
database library. In the future the code will grow into a full application,
but I'm taking small steps at the moment.

As I'm new to unit testing I'm unsure the tests should be structured and am
keen to follow good practice.

I'm thinking of structuring the unit tests as follows
Unit test 1 - connect to database
Unit test 2 - create table
Unit test 3 - insert record into table
Unit test 4 - select record from table
Unit test 5 - (perform some other SQL statements)
Unit test 6 - disconnect from database
Some of these tests could be considered as setup and teardown code, but I
want the unit tests to cover all code in my wrapper.

What I'm unsure about is whether it's considered good practice for one unit
test to depend upon a previous unit test creating something in order to
allow the test to be performed.

The other issue I've got is whilst the function may not have thrown an
exception it doesn't necessary mean the function did what its supposed to
do. For example unit test 2 might not throw an error, but the only way I'll
know if the function worked correctly is to query the database metadata or
do unit test 3. Should unit test 2 only check that an error was not thrown
or should it also call another function to query the metadata and then check
the result of that function before marking unit test 2 as a success?

-- 
View this message in context: http://old.nabble.com/Boost.Test---Advice-needed-on-structuring-tests-tp28196054p28196054.html
Sent from the Boost - Users mailing list archive at Nabble.com.

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net