Стоит ли включать системные тесты в проект Spring? - PullRequest
Новая
       15

Стоит ли включать системные тесты в проект Spring?

1 голос
/ 16 февраля 2011

Веб-проект My Spring состоит из:

  1. утилитарные занятия;
  2. хранилища;
  3. услуга;
  4. контроллеры.

Испытания следующие:

  1. модульные тесты для классов утилит;
  2. весенние интеграционные тесты для репозиториев с HSQLDB;
  3. модульные тесты для сервисов с фиктивными репозиториями;
  4. модульные тесты для контроллеров с имитационными сервисами.

Также могут быть системные тесты, которые проверяют общую функциональность проекта. Это можно выполнить с помощью внешнего инструмента, такого как Selenium, или с помощью интеграционного тестирования Spring.

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

Я вижу две проблемы с включением системных тестов в проект: 1. они нуждаются в настройке конфигурации, потому что такие тесты не будут выполняться с производственной конфигурацией (например, тестам нужен локальный источник данных, а не тот из JNDI); 2. они не автономны, им нужны внешние ресурсы и так далее. Я не могу просто запустить их как обычные юнит-тесты.

Как вы организуете тестирование вашей системы?

1 Ответ

1 голос
/ 17 февраля 2011

На небольших проектах я держал их в одном месте. В крупных корпоративных проектах (например, для которых вы могли бы эффективно использовать Spring, например) мы обычно организовывали системные тесты в отдельном пакете / проекте. Это помогает отделить их от основной кодовой базы.

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

Большую часть времени логика в системных сценариях будет нацелена на страницы, экраны, веб-вызовы и т. Д., Поэтому повторное использование кода из основного проекта - это красная сельдь. Держите пакеты отдельно, чтобы этого не происходило, и потому что, как только вы этого не сделаете, вам не нужно хранить их в одном месте.

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

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

...