Sha256: 6b0a62cdb337498403ff31de71b936fa14b1304a157b7085ae9a2462ee8f037c
Contents?: true
Size: 1.29 KB
Versions: 2
Compression:
Stored size: 1.29 KB
Contents
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)
Version data entries
2 entries across 1 versions & 1 rubygems
Version | Path |
---|---|
redsnow-0.3.2 | ext/snowcrash/ext/markdown-parser/test/ext/Catch/docs/test-fixtures.md |
redsnow-0.3.2 | ext/snowcrash/test/vendor/Catch/docs/test-fixtures.md |