将 JUnit 类分离到特殊的测试包中?

发布于 2024-08-23 18:39:14 字数 914 浏览 4 评论 0 原文

我正在通过阅读 Craftsman 文章(单击 按主题下的 >Craftsman)在我上一个问题的回答中推荐,“学习 JUnit 和正确软件工程的示例项目”。到目前为止我很喜欢它!

但现在我想坐下来亲自尝试一下。我有一个问题,希望只需要一个简单的答案。

如何组织 JUnit 测试类和实际代码?我主要讨论包结构,但任何其他值得注意的概念也会有所帮助。

您是否将测试类放在 org.myname.project.test.* 中,将普通代码放在 org.myname.project.* 中?您是否将测试课程与普通课程放在一起?您是否更喜欢在类名前加上 Test 前缀而不是后缀?

我知道这似乎是我不应该这么快担心的事情,但我是一个非常以组织为中心的人。我几乎是那种花更多时间找出方法来跟踪要完成的事情的人,而不是真正把事情做好。

我有一个项目,目前被整齐地划分为包,但该项目变得一团糟。我不想尝试重构所有内容并编写测试,而是想重新开始,首先进行测试。但首先我需要知道我的测试去哪里了。


编辑:我完全忘记了 Maven,但似乎你们大多数人都在使用它!过去,我有一个特定的用例,Maven 对我来说完全崩溃了,但 Ant 给了我所需的灵活性,所以我最终选择了 Ant,但我想也许我只是采取了错误的方法。我想我会再次尝试 Maven,因为听起来它很适合测试驱动开发。

I am learning the concepts of Test-Driven Development through reading the Craftsman articles (click Craftsman under By Topic) recommended in an answer to my previous question, "Sample project for learning JUnit and proper software engineering". I love it so far!

But now I want to sit down and try it myself. I have a question that I hope will need only a simple answer.

How do you organize your JUnit test classes and your actual code? I'm talking mainly about the package structure, but any other concepts of note would be helpful too.

Do you put test classes in org.myname.project.test.* and normal code in org.myname.project.*? Do you put the test classes right alongside the normal classes? Do you prefer to prefix the class names with Test rather than suffix them?

I know this seems like the kind of thing I shouldn't worry about so soon, but I am a very organization-centric person. I'm almost the kind of person that spends more time figuring out methods to keep track of what to get done, rather than actually getting things done.

And I have a project that is currently neatly divided up into packages, but the project became a mess. Instead of trying to refactor everything and write tests, I want to start fresh, tests first and all. But first I need to know where my tests go.


edit: I totally forgot about Maven, but it seems a majority of you are using it! In the past I had a specific use case where Maven completely broke down on me but Ant gave me the flexibility I needed, so I ended up attached to Ant, but I'm thinking maybe I was just taking the wrong approach. I think I'll give Maven another try because it sounds like it will go well with test-driven development.

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

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

发布评论

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

评论(3

冷默言语 2024-08-30 18:39:14

我更喜欢将测试类放入与它们测试的项目类相同的包中,但放在不同的物理目录中,例如:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

在 Maven 项目中,它看起来像这样:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

主要的一点是我的测试类可以访问(并且测试!)包范围的类和成员。

如上面的示例所示,我的测试类具有被测试类的名称加上 Test 作为后缀。这有助于快速找到它们 - 尝试在数百个测试类中搜索并不是很有趣,每个测试类的名称都以 Test 开头...

Update 受到 @Ricket 的启发评论:这样,测试类(通常)会在按项目按字母顺序排列的类名称列表中紧随其测试伙伴之后显示。 (有趣的是,我日复一日地受益于这一点,却没有意识到如何......)

更新2:很多开发人员(包括我自己)喜欢Maven,但似乎至少有同样多的开发人员(包括我自己)喜欢Maven。谁不这样做。恕我直言,它对于“主流”Java 项目非常有用(我将大约 90% 的项目归入这一类别......但其他 10% 仍然是相当少数)。如果能接受Maven约定,那么使用起来就很容易;但如果没有,生活就会变成一场痛苦的挣扎。对于许多在 Ant 上社交的人来说,Maven 似乎很难理解,因为它显然需要一种非常不同的思维方式。 (我自己从未使用过 Ant,无法比较两者。)有一件事是肯定的:它使单元(和集成)测试成为流程中自然的、一流的步骤,这有助于开发人员采用这一基本实践。

I prefer putting the test classes into the same package as the project classes they test, but in a different physical directory, like:

myproject/src/com/foo/Bar.java
myproject/test/com/foo/BarTest.java

In a Maven project it would look like this:

myproject/src/main/java/com/foo/Bar.java
myproject/src/test/java/com/foo/BarTest.java

The main point in this is that my test classes can access (and test!) package-scope classes and members.

As the above example shows, my test classes have the name of the tested class plus Test as a suffix. This helps finding them quickly - it's not very funny to try searching among a couple of hundred test classes, each of whose name starts with Test...

Update inspired by @Ricket's comment: this way test classes (typically) show up right after their tested buddy in a project-wise alphabetic listing of class names. (Funny that I am benefiting from this day by day, without having consciously realized how...)

Update2: A lot of developers (including myself) like Maven, but there seems to be at least as many who don't. IMHO it is very useful for "mainstream" Java projects (I would put about 90% of projects into this category... but the other 10% is still a sizeable minority). It is easy to use if one can accept the Maven conventions; however if not, it makes life a miserable struggle. Maven seems to be difficult to comprehend for many people socialized on Ant, as it apparently requires a very different way of thinking. (Myself, having never used Ant, can't compare the two.) One thing is for sure: it makes unit (and integration) testing a natural, first-class step in the process, which helps developers adopt this essential practice.

仅此而已 2024-08-30 18:39:14

我将测试类放在与他们正在测试的包相同的包中,但位于不同的源文件夹或项目中。以这种方式组织我的测试代码使我能够轻松地单独编译和打包它,以便生产 jar 文件不包含测试代码。它还允许测试代码访问包私有字段和方法。

I put my test classes in the same package as what they are testing but in a different source folder or project. Organizing my test code in this fashion allows me to easily compile and package it separately so that production jar files do not contain test code. It also allows the test code to access package private fields and methods.

躲猫猫 2024-08-30 18:39:14

我使用 Maven。 Maven 提倡的结构是: -

src/main/java/org/myname/project/MyClass.java

src/test/java/org/myname/project/TestMyClass.java

即测试类的测试类名称前面带有 Test ,与主测试处于并行目录结构中。

将测试类放在同一包(但不一定是目录)中的优点之一是您可以利用包范围方法来检查或注入模拟测试对象。

I use Maven. The structure that Maven promotes is:-

src/main/java/org/myname/project/MyClass.java

src/test/java/org/myname/project/TestMyClass.java

i.e. a test class with Test prepended to the name of the class under test is in a parallel directory structure to the main test.

One advantage of having the test classes in the same package (not necessarily directory though) is you can leverage package-scope methods to inspect or inject mock test objects.

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