Этот модульный тест должен быть в той же упаковке, что и контроллер, который он тестирует? - PullRequest
Новая
       10

Этот модульный тест должен быть в той же упаковке, что и контроллер, который он тестирует?

0 голосов
/ 23 октября 2010

Согласно этому примеру , он идет в том же пакете, что и проверяемый контроллер.

Почему это необходимо?

Думаю, было бы лучше, если бы все мои юнит-тесты были в пакете testing - не будет ли проблем с этим? 

package com.example.web.controllers;

...imports...

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"/testApplicationContext.xml"})
public class HomeControllerSysTest extends AbstractJUnit4SpringContextTests {

    private static final Logger log = Logger.getLogger(
            HomeControllerSysTest.class.getName());
    private final LocalServiceTestHelper helper =
            new LocalServiceTestHelper(new LocalDatastoreServiceTestConfig());

    @Before
    public void setUp() {
        helper.setUp();
    }

    @After
    public void tearDown() {
        helper.tearDown();
    }

    @Test
    public void testHomeController() throws IOException {
        final String url = "http://localhost:8080/movie/test";

        final WebClient webClient = new WebClient();
        final HtmlPage page = webClient.getPage(url);
        assertEquals("The Page Title", page.getTitleText());

        // there are many different methods to query everything on your
        // page. Please refer to the HttpUnit homepage
        HtmlElement header = page.getElementsByTagName("h1").get(0);
        assertNotNull(header);

        String headerValue = header.getNodeValue();
        assertEquals(headerValue, "Hello World!");
    }
}

Ответы [ 3 ]

6 голосов
/ 23 октября 2010

Хранение их в одном пакете позволяет тестировать приватные объекты и методы пакета. Чтобы сохранить порядок, поместите тесты в один и тот же пакет, создав параллельное исходное дерево. 

src/
  com/
    example/
      MyClass.java

tests/
  com/
    example/
      MyClassTest.java

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

3 голосов
/ 23 октября 2010

Должно ли это быть? Нет.

Должно ли это быть? Это соглашение.

При создании приложения Ant задачи с соответствующими атрибутами могут удалить все тестовые классы, независимо от того, как вы организовали свой проект. Таким образом, физическое местоположение не имеет большого значения в этом отношении.

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

Java имеет доступ на уровне пакетов (аналогичный частному и общедоступному доступу), но я не думаю, что это используется слишком часто.

Самое главное, что у вас есть модульные тесты. Остальное не так важно, ИМО.

1 голос
/ 23 октября 2010

Юнит-тесты могут быть в любой упаковке. По сути, это просто отдельные классы, используемые для проверки поведения тестируемого класса.

Самым важным вопросом здесь является то, что размещение тестовых классов JUnit является константой для проекта, частью которого они являются. То есть либо они всегда находятся в одном пакете, либо в подпакете с именем test, либо в отдельном пакете.

Я предпочитаю помещать тестовые классы JUnit в отдельный пакет, определяемый заменой имени верхнего уровня на 'test', поэтому org.util.strings.StingUtil будет иметь тестовый класс Junit с именем test.util.StringUtilTest.

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

...