When writing a unit test, it is tempting to exercise many scenarios by writing a data-driven test. For example, to test the function IsWord, you could write (ARRAYSIZE is a macro that returns the number of elements in an array):const struct {const char* word; bool is_word;} test_data[] = { {"milk", true}, {"centre", false}, {"jklm", false}, }; TEST(IsWordTest, TestEverything) { for (int i = 0; i < ARRAYSIZE(test_data); i++) EXPECT_EQ(test_data[i].is_word, IsWord(test_data[i].word)); }
faster than linearly Locale LOCALES[] = { Word::US, Word::UK, Word::France, ... }; const struct {const char* word; bool is_word[NUM_LOCALES];} data[] = { {"milk", {true, true, false, ...}}, // one bool per language {"centre", {false, true, true, ...}}, {"jklm", {false, false, false, ...}} }; TEST(IsWordTest, TestEverything) { for (int i = 0; i < ARRAYSIZE(data); i++) for (int j = 0; j < ARRAYSIZE(LOCALES); j++) EXPECT_EQ(data[i].is_word[j], IsWord(data[i].word, LOCALES[i])); }
keeping the data in the test TEST(IsWordTest, IsWordInMultipleLocales) { EXPECT_TRUE(IsWord("milk", Word::UK)); EXPECT_TRUE(IsWord("milk", Word::US)); EXPECT_FALSE(IsWord("milk", Word::France)); } TEST(IsWordTest, IsWordWithNonExistentWord) { // 'jklm' test is not repeated EXPECT_FALSE(IsWord("jklm", Word::US)); // as it uses the same code path }
unmanageable this episode of Testing on the Toilet and post it in your office.
This is an excellent post. It's too easy to use data the wrong way. Just had this discussion with someone yesterday, and I'm putting this on their desk.
ReplyDeleteBUG : LOCALES[i] should be LOCALES[j]
ReplyDelete