VS2012 - Отключить параллельные тестовые прогоны

Question

У меня есть некоторые модульные тесты (C++), работающие в тестовой среде Visual Studio 2012.

Из того, что я могу сказать, тесты проходят параллельно. В этом случае тесты наступают друг на друга - я не хочу запускать их параллельно!

К примеру, у меня есть два испытания, в которых я добавил точки останова, и они поражают в следующем порядке:

1. Test1 TEST_CLASS_INITIALIZE
2. Test2 TEST_CLASS_INITIALIZE
3. Test2 TEST_METHOD
4. Test1 TEST_METHOD

Если инициация для теста 1 запускается сначала, то все ее методы тестирования должны до завершения чего-либо, связанного с Test2, запускается!

После нескольких интернет-поиска я достаточно смущен. Все, что я читаю, говорит Visual Studio 2012 does not run tests concurrently by default, и вам нужно перепрыгнуть через обручи, чтобы включить его. Мы, конечно, не включили его в наш проект.

Любые идеи о том, что может произойти? Я пропустил что-то принципиальное здесь?

Answer 1

Я пропустил что-то фундаментальное здесь?

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

Конечно, есть тестовые примеры, которые ожидают, что какой-то основной код детали будет работать, это может быть собственный код или часть среды/библиотеки, с которой вы работаете. Когда дело доходит до этого, программист должен знать, какие данные или объект ожидать в результате.

Здесь Mock Objects вступает в игру. Mock-объекты позволяют вам подражать части кода и гарантировать, что объект обеспечивает именно то, что вы ожидаете, поэтому вы не полагаетесь на другие (трудоемкие) службы, такие как HTTP-запросы, потоки файлов и т. Д. Вы можете read more here.

Когда проект становится сложным, установка занимает довольно много строк и код начинает дублировать. Решением является метод Setup и TearDown. Соглашение об именах отличается от рамок к фрейму, Setup может называться beforeEach или TestInitialize и TearDown также может отображаться как afterEach или TestCleanup. Имена для NUnit, MSTest и xUnit.net можно найти на xUnit.net codeplex page.

---

Простой пример приложения:

• он должен прочитать конфигурационный файл
• он должен проверить, если файл конфигурации действует
• он должен обновить конфигурации пользователя

То, как я собирался строить и тестировать это:

• есть метод для чтения конфигурации и второй, чтобы проверить это

• имеет геттер/сеттер для пользовательских настроек

• метод испытаний для чтения, если она возвращает желаемый результат (объект, строку или однако вы «ве разработал его)

• создать макет конфигурации, которые вы ожидаете от метода чтения и испытания, если метод принимает его
  • на данный момент, вы должны создать несколько фиктивной конфигу, которые проверяют все возможные сценарии, чтобы увидеть, работает ли он для всех возможных сценариев и исправить их соответственно. Это также называется code coverage.
• создать фиктивный объект принимаемой конфигурации и использовать установщик для обновления конфигурации пользователя, а затем использовать, чтобы проверить, если он был установлен правильно

Это основной принцип Test-Driven Development (TDD).

Если набор тестов настроен так, как описано, и все испытания проходят, все эти части, соединенные вместе, должны работать отлично. Дополнительный тест, например, End-to-End (E2E), не обязательно необходим, я использую их только для обеспечения того, чтобы весь поток приложений работал и чтобы легко поймать ошибку (например, ошибка подключения HTTP).