2010-06-29 4 views
18

Я только что обнаружил при создании некоторых тестов CRUD, которые вы не можете установить в одном тесте и прочитать в другом тесте (данные возвращаются к его инициализации между каждым тестом).Передача данных JUnit между тестами

Все, что я пытаюсь сделать, это (C) восстановить объект с одним тестом и (R) и его следующий. У JUnit есть способ сделать это, или он идеологически закодирован так, что тесты не могут зависеть друг от друга?

+0

[Вот решение я придумал и объяснение недостатков использования статических переменных] [1] [1]: http://stackoverflow.com/questions/17885221/how-to-save-non-static-properties-state-between-junit-test-methods-answer –

+0

@JacobKo Ваша ссылка ведет на страницу не найдена – OrwellHindenberg

ответ

15

Ну, для юнит-тестов ваша цель должна состоять в том, чтобы проверить наименьшую изолированную часть кода, как правило, методом методом. Таким образом, testCreate() - это тестовый пример, а testRead() - другой. Тем не менее, нет ничего, что помешало бы вам создать testCreateAndRead() для проверки двух функций вместе. Но тогда, если тест не сработает, в каком модуле кода происходит сбой теста? Вы не знаете. Те такие тесты больше похожи на интеграционный тест, к которому следует относиться по-разному.

Если вы действительно хотите это сделать, вы можете создать переменную статического класса для хранения объекта, созданного testCreate(), а затем использовать его в testRead().

Как я понятие не имею, какую версию JUnit вы говорите, я просто забрать древнюю один Junit 3,8:

Уттерли некрасивый, но работаю:

public class Test extends TestCase{ 

    static String stuff; 

    public void testCreate(){ 
     stuff = "abc"; 
    } 

    public void testRead(){ 
     assertEquals(stuff, "abc"); 
    } 
} 
+0

Это * - интеграционный тест - duh, CRUD означает доступ к базе данных , – orbfish

+0

Кстати, хорошая идея о статической переменной, если она работает. Я должен попробовать. – orbfish

+0

Это сработало, спасибо! – orbfish

11

JUnit способствует независимым тестам. Один из вариантов - поставить два логических теста в один метод @Test.

TestNG был частично создан для обеспечения таких зависимостей между тестами. Он обеспечивает локальные объявления тестовых зависимостей - он запускает тесты в допустимом порядке и не запускает тесты, зависящие от неудавшегося теста. См. Примеры http://testng.org/doc/documentation-main.html#dependent-methods.

+0

Итак, это * идеология! Я боялся этого. Я подумал, подумал об этом, что есть некоторые новые аннотации, связанные с зависимостью intertest, но, возможно, я читал о TestNG. – orbfish

+0

Это действительно идеально подходит для модульных тестов, чтобы быть независимыми как в состоянии, так и в порядке. JUnit поддерживает идеал. TestNG поддерживает как идеальные, так и прагматические исключения. Седрик Боуст, автор TestNG, более подробно обсуждает вопросы в источниках ниже. Он подтвердил намерение Юнит с Бек и Гамма и обнаружил недостатки в работе над подходом JUnit со статическими членами. * Запись блога Beust's 2004 http://beust.com/weblog/2004/02/08/junit-pain/ * Первые несколько страниц книги Беуста «Тестирование Java следующего поколения: TestNG и расширенные концепции», Addison -Wesley, 2008. –

+0

Я согласен со всем этим, для модульных тестов. Но тесты CRUD - это доступ к базе данных и, следовательно, не модульные тесты. Жаль, что JUnit, который является настолько гибким и распространенным, должен быть ограничен каким-либо образом, ограничивающим его только модульными тестами. – orbfish

3

Сколько времени на проведение этих испытаний? Если не много, то зачем потеть. Конечно, вы создадите какой-то объект без необходимости, но сколько это вам стоит?

@Test 
void testCreateObject() { 
    Object obj = unit.createObject(); 
} 

@Test 
void testReadObject() { 
    Object obj = null; 
    try { 
     obj = unit.createObject(); // this duplicates tests aleady done 
    } catch (Exception cause) { 
     assumeNoException(cause); 
    } 
    unit.readObject(obj); 
} 
+0

Хорошая точка. Более того, я должен придумать тестовые данные, чтобы обеспечить уникальность в 2 createObject(), но это может быть путь. – orbfish

+1

Я предполагаю, что часть меня сопротивляется написанию одного и того же кода «создать» дважды. Я переборщил, сухо. – orbfish

+0

@orbfish Это так же СУХОЙ, как вы можете получить, не введя зависимости между тестами. @emory вызов 'unit.readObject' должен быть выполнен в блоке' try'. Вы полагаетесь на содержимое предложения 'catch', чтобы избежать« NullPointerException »или что-то в этом роде. – MauganRa

2

в этом простом примере, переменная изменяется в тест-A, и может быть использовано в тесте В

public class BasicTest extends ActivityInstrumentationTestCase2 { 
    public BasicTest() throws ClassNotFoundException { 
     super(TARGET_PACKAGE_ID, launcherActivityClass);   
    } 

    public static class MyClass {  
     public static String myvar = null;    
     public void set(String s) { 
      myvar = s; 
     }    
     public String get() { 
      return myvar; 
     } 
    } 

    private MyClass sharedVar; 

    @Override 
    protected void setUp() throws Exception { 
     sharedVar = new MyClass(); 
    } 

    public void test_A() { 
     Log.d(S,"run A"); 
     sharedVar.set("blah"); 
    } 

    public void test_B() { 
     Log.d(S,"run B");  
     Log.i(S,"sharedVar is: " + sharedVar.get());   
    } 

} 

Выходной результат является:

запустить

пробег B

ДелитьVar is: blah

+0

Ваш пример не содержит аннотации @Test. Я попробовал ваш код с добавлением «@Test» и не повезло. Вы пробовали это? У меня создалось впечатление, что тесты JUnit должны содержать хотя бы одну такую ​​аннотацию. – OrwellHindenberg

1

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

static String storage; 
@Test 
public void method1() { 
    storage = "Hello" 
} 

@Test 
public void method2() { 
    Assert.assertThat(something, is(storage)); 
} 
+0

Я узнал, так как я изначально просил, чтобы это было плохо. ;) – orbfish

Смежные вопросы