将JUnit类分离成特殊的测试包？ [英] Separation of JUnit classes into special test package?
问题描述
通过阅读 Craftsman文章（我正在学习测试驱动开发的概念）在上一个问题的答案中建议点击按主题下的 Craftsman ，用于学习JUnit和适当软件工程的示例项目。到目前为止我喜欢它！
但现在我想坐下来亲自尝试一下。我有一个问题，我希望只需要一个简单的答案。
如何组织JUnit测试类和实际代码？ I我主要讨论的是包结构，但任何其他注意事项也都会有所帮助。
你是否将测试类放在org.myname.project.test中。*和org.myname.project中的普通代码。*？你是否把测试类放在正常的课程旁边？你更喜欢用Test代替类名前缀而不是后缀吗？
我知道这似乎是我不应该这么快就担心的事情，但是我我是一个以组织为中心的人。我几乎那种花费更多时间找出方法来跟踪要做什么的人，而不是实际完成任务。
我有一个项目，目前整齐划分为包，但项目变得一团糟。我没有尝试重构所有内容并编写测试，而是首先尝试新的测试。但首先我需要知道测试的去向。
编辑：我完全忘了Maven，但似乎大多数人都在使用它！在过去，我有一个特定的用例，Maven完全打破了我，但Ant给了我所需的灵活性，所以我最终依附于Ant，但我想也许我只是采取了错误的方法。我想我会再给Maven一次尝试，因为听起来它会很好地适应测试驱动开发。
我更喜欢将测试类放在与他们测试的项目类相同的包中，但是在不同的物理目录中，例如：
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
这里的要点是我的测试类可以访问（并测试！）包范围类和成员。
如上例所示，我的测试类有测试类的名称加上测试作为后缀。这有助于快速找到它们 - 尝试在几百个测试类中搜索并不是很有趣，每个测试类的名称都以测试 ...
$ b
更新：这样一来，测试类（通常）会在他们的测试好友之后出现在项目名称的类别字母列表中。 （有趣的是，我从一天中受益，没有有意识地意识到......）
Update2：很多开发人员（包括我自己）像Maven一样，但似乎至少有很多人没有。恕我直言，它对主流Java项目非常有用（我会将约90％的项目纳入此类别......但其他10％仍然是相当大的少数项目）。如果可以接受Maven惯例，它很容易使用;但如果没有，它会让生活变得悲惨。对于许多在Ant上社交的人来说，Maven似乎很难理解，因为它显然需要一种非常不同的思维方式。 （我自己，从未使用过Ant，无法比较两者。）有一件事是肯定的：它使单元（和集成）测试成为流程中自然的，一流的步骤，这有助于开发人员采用这种基本实践。 / p>
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.
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.
这篇关于将JUnit类分离成特殊的测试包？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
