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-tp2819... Sent from the Boost - Users mailing list archive at Nabble.com.