Испытание Junit, которое создает другие тесты

Question

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

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

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

Любые предложения?

Answer 1

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

Answer 2

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

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

Answer 3

Ответ на вопрос Junit3: создайте TestSuite, который создает экземпляры тестовых областей, которые вам нужны, с каждой тестовой базой, инициализированной в соответствии с вашими динамическими данными. Набор будет работать как единое целое внутри одного экземпляра JVM, но отдельные TestCase не зависят друг от друга (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 не стоит на месте, поэтому вам нужно будет позаботиться о своих соглашениях об именах, если ваши тесты будут автоматически обнаружены.