Comments 6
Хороший материал. Спасибо.
Есть ряд вопросов.
1. Позволяет ли TS_EXPECT_CALL задать очередность вызовов одной и той же функции? Например, первый раз вернуть 10, а второй 20.
2. Как обстоят дела с указателями в параметрах? Например, если параметр есть указатель на структуру. Что в этом случае проверяется в реализации мока — указатель, поля структуры или просто область памяти по sizeof? (я пишу на С и не силен в C++, поэтому объектов не касаюсь)
3. Потокобезопастность (есть или нет)
Есть ряд вопросов.
1. Позволяет ли TS_EXPECT_CALL задать очередность вызовов одной и той же функции? Например, первый раз вернуть 10, а второй 20.
2. Как обстоят дела с указателями в параметрах? Например, если параметр есть указатель на структуру. Что в этом случае проверяется в реализации мока — указатель, поля структуры или просто область памяти по sizeof? (я пишу на С и не силен в C++, поэтому объектов не касаюсь)
3. Потокобезопастность (есть или нет)
1. Да. позволяет. И только этот режим поддерживается.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
Как бы в gmock тоже есть генерилка моков. Разве что репозитория нет. Зато там можно в статический полиморфизм.
Не раскрыта тема, как сабж умеет в перегрузки. И как поведёт себя с нечистоабстрактными классами.
Не раскрыта тема, как сабж умеет в перегрузки. И как поведёт себя с нечистоабстрактными классами.
Плохо жить без кармы, даже коммент не поправить.
Не разглядел сию часть.
Обширный список «НЕ работает/поддерживает», не вдохновляет пересаживаться с gmock.
Но за обзор спасибо.
И как поведёт себя с нечистоабстрактными классами.
Не разглядел сию часть.
Обширный список «НЕ работает/поддерживает», не вдохновляет пересаживаться с gmock.
Но за обзор спасибо.
Аджайл, TDD, не хватает только паттернов ООП
Sign up to leave a comment.
CxxMock — Mock-объекты в C++