Запуск JUNIT Test Suites в указанном порядке с использованием ANT

Question

В следующем примере

   1. <target name="tests.unit">  
   2.   <junit>  
      3.     <batchtest>  
      4.       <fileset dir="tsrc">  
      5.         <include name="**/Test*.java"/>  
      6.         <exclude name="**/tests/*.java"/>  
      7.       </fileset>  
      8.     </batchtest>  
      9.   </junit>  
     10. </target>  
     11. <target name="tests.integration">  
     12.   <junit>  
     13.     <batchtest>  
     14.       <fileset dir="tsrc">  
     15.         <include name="**/tests/Test*.java"/>  
     16.       </fileset>  
     17.     </batchtest>  
     18.   </junit>  
     19. </target>  

Если у меня есть несколько TestSuites в папке ** / tests /. Как он узнает, какой набор тестов запустить в первую очередь, если я запускаю цель tests.integration? Если у меня есть TestSuite1.java, TestSuite2.java и TestSuite3.java, я бы хотел, чтобы наборы тестов запускались в порядке, указанном в имени файла.

Answer 1

Вы можете создать базовый тестовый класс, поставить логин в setUp() и наследовать все ваши тестовые наборы от этого (и, конечно, вызывать super.setUp() везде).

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

Для тех тестовых случаев, когда помимо логина вам также нужен продукт, вы создаете второй базовый тестовый класс, который расширяет первый и добавляет создание продукта к его setUp().

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

Вероятно, будет медленнее выполнять 5000 юнит-тестов таким образом, но намного, намного безопаснее. Если вы начинаете зависеть от порядка выполнения ваших юнит-тестов, вы наступаете на скользком склоне. Очень трудно заметить, что вы случайно ввели дополнительную зависимость между двумя модульными тестами, если их порядок фиксируется вашей конфигурацией. Например. Вы устанавливаете определенное свойство продукта или изменяете глобальную настройку конфигурации в одном модульном тесте, затем тестируете что-то другое на своем продукте в следующем тестовом примере - и это работает только потому, что предыдущий модульный тест настроил эту конкретную вещь путь. Это рано или поздно приводит к неприятным сюрпризам.

Answer 2

Если в JUnit нет новых функций, это сложно сделать.

TestNG может управлять им с зависимыми группами.

Вот вам вопрос: почему заказ имеет значение? Модульные тесты не должны иметь зависимостей. Если вы делаете это, возможно, это действительно интеграционные тесты.

FitNesse может быть лучше.

Answer 3

Да, я пытаюсь создать набор тестов для функциональных, а не модульных тестов. Я пытаюсь использовать junit для сборки пакета функциональных тестов. Я использую селен, который основан на Junit.

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

1. TestLogin
2. TestCreateProduct
3. TestReadProduct

В приведенных выше тестовых примерах я не могу прочитать любой продукт до того, как он будет создан, и что я вошел в систему и не могу создать продукт до того, как войду в систему. Я видел много комментариев об использовании методов setUp () и tearDown (), но это наверняка означало бы много дублирования.

Если, например, мне нужно сделать тест-кейс TestReadProduct независимым, мне потребуется поместить функциональность TestLogin и TestCreateproduct в метод setUp () для тест-кейса TestCreateProduct. Конечно, это кошмар обслуживания. Представьте себе необходимость поддерживать 5000 тестовых случаев. Мне бы пришлось сделать много изменений во многих местах, если функциональность TestLogin изменилась.

Я думаю об использовании опции «зависит» в ANT.

как то так

<target=TestReadProduct depends=TestLogin, TestCreateProduct>

нет лучшего способа сделать это?