Запуск каждого теста <batchtest> в отдельной виртуальной машине с помощью JUnit в Ant

Question

У меня есть файл сборки Ant, который использует batchtest junit для тестирования всех тестовых классов.

Предположим, у меня есть класс

class MyTest{ 
    @BeforeClass 
    public static void setUpBeforeClass(){ 
     //some stuff 
    } 

    @Test 
    public void test1(){ 
    } 

    @Test 
    public void test2(){ 
    } 
} 

Я знаю, что JUnit создает новый экземпляр класса MyTest для каждого метода испытаний, но то, что я хочу, что новый VM должен быть создан для каждого метода испытаний. Я хочу, чтобы каждый метод тестирования ром находился в отдельной виртуальной машине и хотел, чтобы загрузчик классов загружал MyTest снова для каждого метода тестирования. Это возможно?

Я попытался прочитать документацию и попытался это решение:

<junit fork="yes" reloading="true" forkmode="perTest"> 
    <batchtest> 
    </batchtest> 
</junit> 

Но даже после использования этих параметров для каждого из моего метода испытаний метод setUpBeforeClass называется только один раз. Я делаю что-то неправильно?

EDIT:

Почему я хочу, чтобы сделать это?

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

Answer 1

Единственный возможный способ, я вижу, что работа состоит в том, чтобы иметь несколько экземпляров <test> элементов.

Проблема в том, что вы должны указать для каждого элемента <test> какие методы вы хотите запускать. Я создал единственный тестовый класс, в котором есть статический инициализатор и два теста. При следующей <junit> задачи я был в состоянии сделать то, что вы хотите:

<junit fork="yes"> 
    <classpath> 
     <path refid="classpath" /> 
    </classpath> 
    <formatter type="xml"/> 
    <test name="TestSimple" methods="testOne" toDir="firstRun" /> 
    <test name="TestSimple" methods="testTwo" toDir="secondRun" /> 
</junit> 

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

test: 
    ... 
    [junit] Executing 'C:\Program Files\Java\jdk1.7.0_25\jre\bin\java.exe' with arguments: 
    [junit] '-classpath' 
    ... 
    [junit] 'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner' 
    [junit] 'TestSimple' 
    [junit] 'methods=testOne' 
    ... 
    [junit] Executing 'C:\Program Files\Java\jdk1.7.0_25\jre\bin\java.exe' with arguments: 
    [junit] '-classpath' 
    ... 
    [junit] 'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner' 
    [junit] 'TestSimple' 
    [junit] 'methods=testTwo' 
    ... 
    [junit] Test TestSimple FAILED 

Я также вижу оператор System.out, который я поставил в статическом инициализаторе в отчете каждого теста.

Важная деталь здесь является то, что вы должны сделать каждый <test> тег переориентировать свой отчет в другой каталог, используя атрибут toDir или изменить имя выходного файла, используя атрибут outfile. Это потому, что имя файла отчета использует имя класса, а не метод, который вы используете. Это означает, что второй запуск перезапишет отчет первого запуска.

В вашем конкретном случае вы можете использовать <batchtest> для всех тестов, которые могут работать в одной и той же JVM без проблем, и добавить тег <exclude>, чтобы избежать проблемных тестов. Затем добавьте конкретный тег <test> для каждого проблемного теста.

Они делают это потому, что атрибут methods специально разработан для повторного запуска определенных методов или отдельных тестов, которые работают слишком медленно.Из documentation:

Методы атрибута могут быть полезны в следующих случаях:

• Метод испытания не удалось, и вы хотите, чтобы повторно запустить метод испытания на тесте исправить или повторно запустите тест под отладчиком Java, не получив , чтобы дождаться, пока другие методы тестирования (возможно, длительные) не пройдут до .
• Один или несколько методов тестирования работают медленнее, чем ожидалось , и вы хотите повторно запустить их под профилировщиком Java (без накладных расходов при запуске профайлера, в то время как другие методы тестирования выполняются ).

Но лично, и исходит от человека, который столкнулся с той же проблемой, как вы до этого, статические инициализаторы сосать! Я бы очень старался избавиться от них как можно скорее. И, цитируя @PeterNiederwieser, наличие новой JVM для каждого набора тестов сделает запуск вашего тестового пакета очень медленным!