2013-06-27 4 views
2

Мои тесты интеграции выполняются последовательно, но я хочу распараллелить их. Проблема в том, что все они устанавливают и разрывают одну и ту же строку базы данных, поэтому, если они выполняются параллельно, их данные будут исчезать посреди них, используя ее, когда другой тест очистится.В JUnit, как я могу получить список всех тестов интеграции?

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

Вот как я предполагаю, что это сработает: Итерируйте все классы IntegrationTest, используйте отражение, чтобы получить значение своего поля ROW_ID, поместите его в структуру данных, а затем проверьте наличие дубликатов. Моя проблема в том, что я не знаю, как итерировать все классы IntegrationTest. Все они имеют общую схему именования «* IntegrationTest». Может ли кто-нибудь помочь мне с этим шагом?

И если есть лучший способ выполнить то, что я пытаюсь сделать, во что бы то ни стало дать мне это как ответ.

+4

Вместо того, чтобы вручную указывать идентификатор строки, почему бы вам не использовать последовательность базы данных? –

+0

@MarlonBernardes Это хорошая идея. Возможно, я смогу это сделать. –

+2

Или, возможно, создать поточно-безопасный метод, который увеличивает и возвращает счетчик id. Что-то вроде 'Long row_id = SequenceNumberGenerator.nextVal()' –

ответ

2

У вас есть много различных вариантов, касающихся уникальной проблемы строки ID:

  1. Используйте последовательность базы данных вместо того, чтобы ваш ID вручную.
  2. Внедрите потокобезопасный счетчик и используйте его как свой ROW_ID (см. Пример ниже);

.

public class SequenceNumberGenerator { 

    private static AtomicInteger counter = new AtomicInteger(); 

    public static int nextVal() { 
     return counter.incrementAndGet(); 
    }  
} 

Я также не создавал бы постоянный ROW_ID в каждом тестовом классе (во избежание дублирования). Вместо этого я думаю, что вы можете определить его на суперклассе (который будет расширен всеми интеграционными тестами), установите его значение перед выполнением теста и просто предоставите ему аксессуар для получения. Что-то вроде этого:

//superclass 
private int rowId; 

@Before 
public void generateRowId() { 
    rowId = SequenceNumberGenerator.nextVal(); 
} 

protected int getRowId() { 
    return rowId; 
} 
+0

И сделано. И еще несколько персонажей. –

1

Вы можете использовать категории JUnit. Прочтите this и, возможно, this one. Существуют и другие фреймворки, которые позволяют еще лучше фильтровать (по пакетам/включая подпакеты/включая те, которые начинаются с x/etc), но я не могу запомнить его имя ... однако, я думаю, что вам нужно просто @Categories.

+0

Вы упомянули TestNG? –

+0

Кроме того, это выглядит как шаг в правильном направлении, но я не знаю, как использовать категории для получения экземпляров/классов тестов в категории. –

+0

OK Я просмотрел его, инфраструктура называется [ClasspathSuite] (http://johanneslink.net/projects/cpsuite.jsp). Я не использовал его лично, но мой коллега говорит, что это лучшее, что когда-либо было. Как вы увидите на веб-странице, вы можете фильтровать любые возможные критерии, например, даже с помощью * IntegrationTest – Csaba