Работа с дополнительными тестами

Отсутствие способа пропустить тест в CATCH, Google Test и других платформах (по крайней мере, в традиционном смысле, когда вы указываете причину для этого и видите его в выводе), заставило меня задуматься, нужно ли мне это вообще (Я использовал UnitTest++ в моих прошлых проектах).

Обычно, да, не должно быть никаких причин, чтобы пропускать что-либо в настольном приложении - вы либо тестируете это, либо нет. Но когда дело доходит до аппаратного обеспечения - некоторые вещи не могут быть гарантированы.

Например, у меня есть два устройства: одно поставляется со встроенным бипером, а другое - без. В UnitTest++ я бы запросил систему, обнаружил, что бипер не доступен, и просто пропустил бы тесты, которые зависят от него. В CATCH, конечно, я могу сделать нечто подобное: запросить систему во время инициализации, а затем просто исключить все тесты с тегом "beeper" ( особая функция в CATCH).

Однако есть небольшая разница: тестер (кто-то, кроме меня) будет читать выходные данные и не найдет упомянутые дополнительные тесты (тогда как в UnitTest++ они будут помечены как пропущенные, а причина будет указана как часть выходных данных).). Его первые мысли:

  • Это должна быть какая-то старая версия приложения для тестирования.
  • Может быть, я забыл включить Suite X.
  • Что-то, вероятно, сломано, я должен спросить разработчика.
  • Подождите, может быть, они просто пропустили. Но почему? Я все равно спрошу у разработчика.

Более того, он мог просто НЕ заметить, что эти тесты были пропущены, хотя их на самом деле не должно быть (то есть ОС возвращает "false", независимо от того, присутствует ли бипер или нет, что является серьезной ошибкой). Один из вариантов - пометить "пропущенные" тесты как пройденные, но это похоже на ненужный обходной путь.

Есть ли какая-нибудь умная техника, о которой я не знаю (то есть, я не знаю, разделяя необязательные тесты в отдельную программу в целом)? Если нет - тогда я должен придерживаться UnitTest++? Он делает свою работу, но мне действительно нравятся разделы и теги CATCH, которые помогают избежать повторения кода.

Источник

2 ответа

Решение

Если вы определяете наличие бипера программно, у вас есть место, где можно распечатать пропущенные тесты.

Вы можете получить набор тестов, которые соответствуют заданной спецификации теста, например:

  std::vector<TestCase> matchedTestCases;
  getRegistryHub().getTestCaseRegistry().getFilteredTests( testSpec, config, matchedTestCases );

testSpec является экземпляром TestSpec, Вы можете получить текущий от config.testSpec() - или вы можете создать его "на лету" (что может потребоваться, если вы программно фильтруете тесты. В настоящий момент это не задокументировано, так как я хотел вернуться ко всей спецификации тестов и переработать ее. Так получилось, что я сделал это на прошлой неделе. Надеюсь, сейчас это должно быть достаточно стабильным, но я позволю этому разобраться, прежде чем отправлять документацию.

Вы должны быть в состоянии решить это, если вы будете искать "class TestSpec" в коде - хотя вам может быть легче разобрать его из строки, используя parseTestSpec(),

Вы можете получить объект конфигурации с getCurrentContext().getConfig(),

Источник

Неясно, запрашиваете ли вы метод, который применяется к googletest, или к CATCH, или к одному, или к обоим. Этот ответ относится к GoogleTest.

Обычный метод пропуска нежелательных тестов заключается в использовании параметра командной строки, который предоставляется для этой цели, --gtest_filter, Смотрите документацию.

Вот пример его использования для набора тестов, в котором бипер может или не может быть включен:

test_runner.cpp

#include "gtest/gtest.h"

TEST(t_with_beeper, foo) {
    SUCCEED(); // <- Your test code here
}

TEST(t_without_beeper, foo) {
    SUCCEED(); // <- Your test code here
}

int main(int argc, char **argv)
{
    ::testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

Бежать:

./test_runner --gtest_filter=t_with_beeper*

Выход:

Note: Google Test filter = t_with_beeper*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from t_with_beeper
[ RUN      ] t_with_beeper.foo
[       OK ] t_with_beeper.foo (0 ms)
[----------] 1 test from t_with_beeper (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1 ms total)
[  PASSED  ] 1 test.

Бежать:

./test_runner --gtest_filter=t_without_beeper*

Выход:

Note: Google Test filter = t_without_beeper*
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from t_without_beeper
[ RUN      ] t_without_beeper.foo
[       OK ] t_without_beeper.foo (0 ms)
[----------] 1 test from t_without_beeper (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1 ms total)
[  PASSED  ] 1 test.

В отчете не указываются пропущенные тесты, но становится достаточно очевидным, включены ли тесты звукового сигнала, что должно быть достаточно, чтобы избежать любых заблуждений или сомнений, которых вы хотите избежать.

Чтобы включить или отключить тестирование бипера в test_runner Вы можете использовать как:

using namespace std;

int main(int argc, char **argv)
{   
    vector<char const *> args(argv,argv + argc);
    int nargs = argc + 1;
    if (have_beeper()) {
        args.push_back("--gtest_filter=t_with_beeper*");
    } else {
        args.push_back("--gtest_filter=t_without_beeper*");
    }
    ::testing::InitGoogleTest(&nargs,const_cast<char **>(args.data()));
    return RUN_ALL_TESTS();
}

где have_beeper() является логической функцией, которая запрашивает наличие звукового сигнала

Источник
Другие вопросы по тегам