Я хочу сделать что-то вроде этого:
TEST(MyTestFixture, printAfterExpectationFailure)
{
const string request("bring me tea");
const string&& response = sendRequestAndGetResponse(request);
checkResponseWithExpectarions1(response);
checkResponseWithExpectarions2(response);
checkResponseWithExpectarions3(response);
checkResponseWithExpectarions4(response);
if (anyOfExpectsFailed())
cout << "Request: " << request << "\nresponse: " << response << endl;
}
TEST(MyTestFixture, printAfterAssertionFailure)
{
const string request("bring me tea");
const string&& response = sendRequestAndGetResponse(request);
doWhenFailure([&request, &response]()
{
cout << "Request: " << request << "\nresponse: " << response << endl;
});
checkResponseWithAssertion1(response);
checkResponseWithAssertion2(response);
checkResponseWithAssertion3(response);
checkResponseWithAssertion4(response);
}
Я хочу напечатать некоторую дополнительную информацию тогда и только тогда, когда ожидания / утверждения не оправдаются.
Я знаю, что могу сделать что-то вроде этого:
#define MY_ASSERT_EQ(lhr, rhs, message) if(lhs != rhs) ASSERT_EQ(lhs, rhs) << message
но такое решение неудобно, потому что:
тот факт, что делать то, что вы хотите сделать, трудно запах кода. В частности, эти два теста (1) делают слишком много и (2) не читаются, в том смысле, что они не описывают, что делает тестируемое устройство.
Я рекомендую два чтения: Юнит-тесты ПЕРВЫЕ и книга Современное программирование на C ++ с тестовой разработкой.
Вместо того, чтобы пытаться вызвать 4 функции, каждая из которых проверяет что-то, а затем задается вопросом, как напечатать сообщение об ошибке в случае сбоя, я предлагаю следующее:
В конце этого процесса вы должны оказаться в ситуации, когда ваша цель распечатать дополнительную информацию о сбое теста может быть достигнута просто с помощью чего-то вроде:
ASSERT_THAT(Response, EQ("something")) << "Request: " << request;
Примечание: также, если лучше, чем отправная точка, я не считаю приведенный выше пример достаточно хорошим. Имя теста должно быть настолько хорошим, настолько наглядным, чтобы вы могли получить нулевую информацию, напечатав значение request
,
Я понимаю, что это своего рода философский ответ; с другой стороны, это вытекает непосредственно из моего опыта в попытке написать хорошие, поддерживаемые тесты. Написание хороших тестов требует той же заботы, что и написание хорошего кода, и это окупится много раз 🙂
Других решений пока нет …