此单元测试是否必须与其测试的控制器位于同一包中?

发布于 2024-09-28 14:57:33 字数 1502 浏览 2 评论 0原文

根据此示例,它与其测试的控制器位于同一包中。

为什么这是必要的?

我认为将所有单元测试放在一个 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!");
    }
}

According to this example, it goes in the same package as the controller it tests.

Why is that necesssary?

I think it would be tidier to have all of my unit tests in a testing package - would there be a problem with doing so?

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!");
    }
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

没︽人懂的悲伤 2024-10-05 14:57:33

将它们保存在同一个包中可以测试包私有的对象和方法。
为了保持整洁,请通过创建并行源树将测试放在“同一”包中。

src/
  com/
    example/
      MyClass.java

tests/
  com/
    example/
      MyClassTest.java

两个源代码树都可以编译到相同的输出目录或以其他方式添加到类路径中,从而就 JVM 而言,它们位于同一个包中。

Keeping them in the same package allows testing of package-private objects and methods.
To keep things tidy, put tests in the "same" package by creating a parallel source tree.

src/
  com/
    example/
      MyClass.java

tests/
  com/
    example/
      MyClassTest.java

Both source trees can be compiled to the same output directory or otherwise added to the classpath, resulting in them being in the same package as far as the JVM is concerned.

鸵鸟症 2024-10-05 14:57:33

单元测试可以在任何包中。本质上,它们只是用于测试被测试类的行为的单独类。

这里最重要的问题是 JUnit 测试类的放置对于它们所属的项目来说是一个常数。即它们要么总是在同一个包中,要么在名为 test 的子包中,要么完全在单独的包中。

我的偏好是将 JUnit 测试类放在一个单独的包中,通过将顶级名称替换为“test”来定义,因此 org.util.strings.StingUtil 将有一个名为 的 Junit 测试类test.util.StringUtilTest

这样就可以很容易地找到测试类,并且可以轻松地将它们分为库 .jar 及其测试 .jar。此外,您也不会冒 JUnit 测试无意中使用对测试类的包级访问的风险;测试类必须使用与世界其他部分相同的接口。 (在我看来,专门用于测试支持的包级挂钩是邪恶的,因此最好通过将测试放在其他地方来确保它们没有用处。)

Unit tests can be in any package. In essence they are just separate classes used to test the behaviour of the class being tested.

The most important issue here is that placement of the JUnit test classes is a constant for the project they are part of. I.e. either they are always in the same package, or in a sub-package with name test, or in a separate package altogether.

My preference is to put JUnit test classes in a separate package defined by replacing the top-level name with 'test', so org.util.strings.StingUtil would have a Junit test class named test.util.StringUtilTest.

This way it is very easy to locate the test classes and they can easily be separated into library .jars and their test .jars. Also you do not run the risk that the JUnit test inadvertantly uses package-level access to the class tested; the test class has to use the same interface as the rest of the world. (In my view package level hooks specifically for test support are evil, so better make sure they are not useful by placing the test elsewhere.)

ゃ懵逼小萝莉 2024-10-05 14:57:33

一定是这样吗?不,

应该这样吗?这就是惯例。

当生产环境发生冲突时,无论您如何组织项目,具有适当属性的 Ant 任务都可以删除所有测试类。因此,物理位置在这方面并不重要。

对于正常的“源”干扰,最好让测试用例靠近相关源代码,这样您就可以更轻松地发布源代码。

Java 具有包级访问(类似于私有和公共访问),但我认为这不会经常使用。

最重要的是你有单元测试。其余的在我看来并不那么重要。

Does it have to be? No.

Should it be? That's the convention.

When jarring for production, Ant tasks with the proper attributes can remove all the test classes no matter how you organize your project. So the physical location doesn't much matter in this regard.

For normal 'source' jarring, it's nicer to have the test cases in close proximity to the related source code so you can more easily make source releases.

Java has package-level access (similar to private and public access) but I don't think this is used too often.

The big thing is that you have unit tests. The rest isn't so important IMO.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文