Тест Junit, который создает другие тесты - PullRequest
Новая
       9

Тест Junit, который создает другие тесты

3 голосов
/ 15 апреля 2010

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

Поскольку у нас более 30 000 файлов, каждый из которых по 1-5 секунд для анализа этого теста будет запущен в своем собственном наборе. Проблема в том, что мне нужен способ, чтобы один фрагмент кода выполнялся как один тест junit для каждого файла, чтобы в случае сбоя 12 файлов из 30 000 файлов я мог видеть, какие из 12 сбоев, а не только один, вызвали исключение времени выполнения и остановили тест .

Я понимаю, что это не настоящий «модульный» способ тестирования, но эта симуляция очень важна, чтобы убедиться, что наши поставщики контента находятся под контролем и не проверяют недопустимые файлы.

Есть предложения?

Ответы [ 3 ]

5 голосов
/ 15 апреля 2010

Я думаю, что вы хотите параметризованные тесты. Это доступно, если вы используете JUnit4 (или TestNG). Поскольку вы упомянули JUnit, вам нужно просмотреть документацию к аннотациям @RunWith(Parameterized.class) и @Parameters.

3 голосов
/ 15 апреля 2010

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

Возможно, лучшее решениебыть тестом TestNG с DataProvider для передачи списка путей к файлам для чтения.TestNG создаст и запустит один тест для каждого переданного параметра пути к файлу.

2 голосов
/ 15 апреля 2010

Ответ Junit3: создайте TestSuite, который создает необходимые вам экземпляры TestCases, причем каждый TestCase инициализируется в соответствии с вашими динамическими данными. Комплект будет работать как единое целое в одном экземпляре JVM, но отдельные TestCases не зависят друг от друга (вызывается setUp, tearDown, обработка ошибок правильна, отчеты дают то, что вы просили, и т. Д.)

Реальная реализация может быть немного неуклюжей, потому что TestCase связывает Имя теста с МЕТОДОМ, который нужно запустить, но это можно обойти.

Обычно мы просто объединяем комплект с динамическими тестовыми примерами в одном классе и используем метод suite () для получения TestSuite. Например, задача Ant JUnit достаточно умна, чтобы заметить это. 

public class DynamicTest extends TestCase {
   String filename ;

   public DynamicTest ( String crntFile ) {
      super("testMethod");
      filename = crntFile ;
   }

   // This is gross, but necessary if you want to be able to
   // distinguish which test failed - otherwise they all share
   // the name DynamicTest.testMethod.
   public String getName() {
      return this.getClass().getName() + " : " + filename ;
   }



   // Here's the actual test
   public void testMethod() {
      File f = new File( filename ) ;
      assertTrue( f.exists() ) ;
   }

   // Here's the magic
   public static TestSuite suite() {

      TestSuite s = new TestSuite() ;

      for ( String crntFile : getListOfFiles() ) {
          s.addTest( new DynamicTest(crntFile ) ) ;
      }

      return s ;
   }
}

Конечно, вы можете отделить TestSuite от TestCase, если хотите. Тем не менее, TestCase не работает в одиночку, поэтому вам нужно быть осторожным с соглашениями об именах, если ваши тесты обнаруживаются автоматически.

...