Тестовый фреймворк для тестирования компонентов

Question

Я ищу тестовый фреймворк, соответствующий моим требованиям.Ниже приведены шаги, которые мне нужно выполнить во время автоматического тестирования:

• Настройка (Есть несколько входных файлов, которые необходимо прочитать или скопировать в определенные папки.)
• Выполнить (Запустить автономный модуль)
• Демонтировать (Очистить, чтобы привести систему в прежнее состояние)

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

Для этого я оцениваю PyUnit, cppunit с scons.Подумал о том, чтобы задать этот вопрос, чтобы убедиться, что я нахожусь в правильном направлении.Можете ли вы предложить какие-либо другие инструменты для тестирования фреймворка?И какие еще требования следует учитывать для правильного выбора тестовой платформы?

Answer 1

После прочтения этой статьи http://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle некоторое время назад я пошел на CxxTest.

После того, как вы все настроили (например, вам нужно установить Python), писать тесты довольно легко (я был совершенно новичком в модульных тестах).

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

Answer 2

Попробуй гуглтест АКА gTest ( тест) он ничем не хуже любого другого фреймворка модульного тестирования, но с таким же успехом может превзойти некоторые из них по простоте использования.Не совсем тот инструмент для интеграционного тестирования, который вы ищете, но его можно легко применить в большинстве случаев.Это википедия страница также может быть полезна для вас.

Вот копия образца на странице проекта gTest:

#include <gtest/gtest.h>

namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
 protected:
  // You can remove any or all of the following functions if its body
  // is empty.

  FooTest() {
    // You can do set-up work for each test here.
  }

  virtual ~FooTest() {
    // You can do clean-up work that doesn't throw exceptions here.
  }

  // If the constructor and destructor are not enough for setting up
  // and cleaning up each test, you can define the following methods:

  virtual void SetUp() {
    // Code here will be called immediately after the constructor (right
    // before each test).
  }

  virtual void TearDown() {
    // Code here will be called immediately after each test (right
    // before the destructor).
  }

  // Objects declared here can be used by all tests in the test case for Foo.
};

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
  // Exercises the Xyz feature of Foo.
}

Scons могли бы позаботиться о создании вашего .cc когда они будут изменены, gTest можно будет использовать для настройки и демонтажа ваших тестов.

Я могу только добавить, что в некоторых случаях мы используем gTest, а почти во всех остальных - собственную платформу автоматизации тестирования.Часто бывает так, что с такими инструментами бывает проще написать свой собственный, чем пытаться настроить какой-то другой в соответствии с вашими требованиями.

Одним из хороших вариантов IMO, и это то, к чему движется наша платформа автоматизации тестирования, является использование тесты на нос, в сочетании с библиотекой общих подпрограмм (таких как запуск / остановка служб, получение статуса чего-либо, включение / отключение регистрации в определенных компонентах и т.д.).Это дает вам гибкую систему, которая также довольно проста в использовании.И поскольку он использует python, а не C ++ или что-то в этом роде, больше людей может быть занято созданием тестовых примеров, включая QES, которые не обязательно должны уметь писать на C ++.