2010-08-26 5 views
48

Это относительно открытый вопрос. Если я создал приложение в проекте в Eclipse, а затем хочу протестировать этот проект, должен ли я создать код JUnit в том же проекте или создать отдельный проект. Например ...Eclipse junit тестирование в том же проекте

ShopSystem Возможно, имя моего основного проекта - должен ли я создать проект под названием say, ShopSystemTest?

В целом - как далеко «прочь» должен быть сохранен тестовый код из основной папки проекта? Если я храню тестовый код в основном проекте, а затем экспортирую основной проект в качестве исполняемой банки, он будет использовать код тестирования с ним, что не идеально ...

Предложения?

ответ

59

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

Вы можете создать вторую исходную папку (например, test), где вы помещаете тестовые классы в те же пакеты, что и тестируемые классы. Это также позволяет вам тестировать частные классы, не заполняя ваши основные исходные пакеты тестовыми классами.

Ваша структура исходной папки/пакет будет выглядеть следующим образом:

-sources 
    -main 
     -my.package 
      -MyClass.java 
    -test 
     -my.package 
      -MyClassTest.java 

Вы можете настроить сборку, чтобы не включать в папку с test источника при упаковке JAR.

4

Обычно у вас есть -

/src/main/java (for codes) 

/src/test/java (for tests) 
3

Рассмотрим Maven путь: В проекте Maven, soruces организованы таким образом

src 
|--main 
|  |--java 
|--test 
     |--java 

Ваш исходный код идет в SRC/основной/Java, ваш JUnit тестовый код идет в src/test/java, они оба являются исходной папкой (и, как следствие, вы можете поместить свой код jUnit в тот же пакет, что и ваш Java-код, но в другой исходной папке).

Интересно, что для обычного кодирования ваши классы jUnit находятся в пакетах кода, но при создании jar вы можете использовать классы, исходящие только из src/main/java, и не выпускать ваши тесты.

19

Мне нравится соглашение с maven: есть отдельный исходный дерево для основного и теста в одном проекте, основной код развертывается, тестовый код - нет. Структуры пакетов могут быть (но не обязательно) идентичными.

project 
    src 
     main 
      java  // source files 
      resources // xml, properties etc 
     test 
      java  // source files 
      resources // xml, properties etc 

И в затмении, когда вы выбираете new -> JUnit test case, вы просто изменить исходную папку для SRC/тест/Java и оставить предложенный пакет как есть.

(Одним из преимуществ, остающиеся в том же пакете будет иметь доступ к защищенным и пакету контекстных членам, хотя это не «правильное» модульное тестирование поведение)


Update: Вот код чтобы проиллюстрировать мою последнюю точку:

главный класс (в SRC/главная/Java):

package com.test; 
public class Foo{ 

    static class Phleem{ 
     public Phleem(final String stupidParameter){ 
     } 
    } 

    String bar; 
    protected String baz; 
    protected Object thingy; 

} 

Тест класс (в ср c/test/java)

package com.test; 
import org.junit.Test; 

public class FooTest{ 

    @Test 
    public void testFoo(){ 
     final Foo foo = new Foo(); 
     foo.bar = "I can access default-scoped members"; 
     foo.baz = "And protected members, too"; 
     foo.thingy = new Foo.Phleem("And I can access default-scoped classes"); 
    } 

} 
+0

«Доступ к защищенным и ограниченным пакетам элементам» - для доступа к защищенным членам вам необходимо подклассифицировать тестируемый класс. То, что вы имеете в виду, - это доступ к классам с ограниченным охватом, не так ли? – Henning

+0

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

+0

Ой! Я не знал, что «защищенный» разрешен доступ к другим классам в одном пакете. Ладно, это проясняет, спасибо. – Henning

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