32186db1b0
- initially just covers new colour config - also updated all [Home] links in footers to go to local readme
32 lines
1.3 KiB
Markdown
32 lines
1.3 KiB
Markdown
Although Catch allows you to group tests together as sections within a test case, it can still convenient, sometimes, to group them using a more traditional test fixture. Catch fully supports this too. You define the test fixture as a simple structure:
|
|
|
|
```c++
|
|
class UniqueTestsFixture {
|
|
private:
|
|
static int uniqueID;
|
|
protected:
|
|
DBConnection conn;
|
|
public:
|
|
UniqueTestsFixture() : conn(DBConnection::createConnection("myDB")) {
|
|
}
|
|
protected:
|
|
int getID() {
|
|
return ++uniqueID;
|
|
}
|
|
};
|
|
|
|
int UniqueTestsFixture::uniqueID = 0;
|
|
|
|
TEST_CASE_METHOD(UniqueTestsFixture, "Create Employee/No Name", "[create]") {
|
|
REQUIRE_THROWS(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), ""));
|
|
}
|
|
TEST_CASE_METHOD(UniqueTestsFixture, "Create Employee/Normal", "[create]") {
|
|
REQUIRE(conn.executeSQL("INSERT INTO employee (id, name) VALUES (?, ?)", getID(), "Joe Bloggs"));
|
|
}
|
|
```
|
|
|
|
The two test cases here will create uniquely-named derived classes of UniqueTestsFixture and thus can access the `getID()` protected method and `conn` member variables. This ensures that both the test cases are able to create a DBConnection using the same method (DRY principle) and that any ID's created are unique such that the order that tests are executed does not matter.
|
|
|
|
---
|
|
|
|
[Home](Readme.md) |