1.
Приходят данные, как мне протестить их, может пришло не то!
Для этого надо задать себе вопрос "А какие именно данные будут не теми?" и переписать их на листочке или же запомнить и держать в голове.
2.
>>Создавать доп базу?
Нет! Для класса работающего с базой написать рефакторинг. Сутью рефакторинга перепроектировать на наследование этого класса работающего с БД от некоего интерфейса. Дальше от интерфейса породить несколько классов потомков на каждую ситуацию описанную в п.1. это будут моки, а вернее State-классы.
Этот вид тестирования называется "State-based testing". Основан на том что заранее пишутся классы имеющее вполне заранее определенное и конкретное состояние, как правило захардкоженное(В data driven testing пока не вдавайтесь, ибо увязнете в деталях). Такие классы нужно писать как можно проще !!! Чтобы в будущем удалять код не было так жалко )))
3)
В тест-методах , т.е. в юнит-тестах вызываете production-код,но подставляете не реальную БД, а классы написанные п.2. и проверяете состояние.
Попробую написать простейший псевдокод, сходство с конкретным языком чисто случайно:
interface StudentDataBase:
getName()
getAge()
// production code
class OracleDataBase implements StudentDataBase
getName()
getAge()
// For Testing goal
class BadNameCorectAge implements StudentDataBase
getName() {
return 'Wrong-name'
}
getAge() {
return 19;
}
TEST(WithBadNameForStudent) {
// [1] Подготовительная часть. Т.е. 'Arrange' из паттерна Arrange-Act-Assert
BadNameCorectAge database;
// Здесь с псевдо-базой используется код из production-части, который вы хотите проверить
TestObject testObj;
testObj->setDataBase(database);
// Выполняем действие в production-части и тут же проверяем
// [2] Другими словами это совмещенная Act-Assert из паттерна ArrangeAct-Assert
EXPECT_EXCEPTION(testObj->process(), WrongNameException);
}