有效的Java Item 13和TDD

Question

我只是用谷歌搜索“Joshua Bloch TDD”......没什么大不了的，这是一个巨大的耻辱，因为我真的很想知道他在这件事上要说些什么。

第13项（我正在看第2版）的标题是“尽量减少班级和成员的可访问性”。几页之后，他说：

  

为了便于测试，您可能想要创建一个类，接口   或会员*更容易访问。 ......私下是可以接受的   公共类package-private的成员，以便测试它，但它   提高可访问性是不可接受的......   幸运的是，它也没有必要，因为可以进行测试   正在测试的软件包的一部分，从而获得对其的访问权限   包私有元素。

* by“members”他的意思是“字段，方法，嵌套类和嵌套接口”。

作为一个TDD新手，但逐渐找到了我的脚，我知道目前的共识似乎不是包含测试类与应用程序代码包，甚至在src \ test和src \ main下都没有匹配的结构：大多数TDD专家似乎很容易以其他方式构建他们的测试目录（例如，您有一个名为“unittests”的目录，另一个名为“functionaltests”，另一个名为“e2etests”）。

具体来说，我在“以测试为导向的面向对象的软件”中遵循了拍卖应用程序的TDD开发。作者对于添加数百种公共方法没有任何疑虑。此外，经过一章我查看了下载的“迄今为止的结构”，他完全改变了测试目录结构，将事物划分为测试类别......

是否有任何经验丰富的TDD手，至少在过去，他发现这是一个两难的根源？如果是这样，你是如何解决的？

作为一个实际的例子，我通过开发一个Lucene索引应用程序来削减TDD技术：它索引文档，然后让你查询它们。目前，所有app类都在同一个包中。实际需要公开的唯一方法是在一个类中main。然而，当然，我有很多很多公共方法：如果不是因为我使用的是TDD，它们都可能是私有的。

PS没有“方法可见性”的标签，所以我选择了“class-visibility”

后

似乎我可能已经被“面向生长的面向对象......”所采用的方法引向了一条相当不幸的道路，其中公共方法的过度使用可能只是因为它是对技术的证明。哈

如果您想分割您的测试类别，是否有人使用过这种方法：

\src\unit_tests\java\core\MainTest.java

但也，例如：
\src\func_tests\java\core\MainTest.java
和
\src\e2e_tests\java\core\MainTest.java？

Answer 1

  

因为测试可以作为被测试包的一部分运行

这并不意味着您必须将测试作为主类放在相同目录中，它们只需要位于相同的包中，这很可能是单独的目录。

假设您有一个包com.acme.foo。所以你的目录结构可能是：

src
  main
    java
      com
        acme
          foo
            MainClass
  test
    java
      com
        acme
          foo
            MainClassTest

MainClassTest与MainClass位于同一个包中，因此可以访问包私有内容。但这些是单独的目录，因此生成的JAR不会包含MainClassTest。

Answer 2

我不确定这在Gradle中是如何工作的，因为我正在使用Maven，但我想这里的概念是相似的。因此，我会用Maven解释它。 Maven项目中的典型设置如下所示：

在项目的根级别上有src和target。在target文件夹中，一切都在构建过程中创建。这意味着src包含我们实际项目的来源。在src下，还有另外两个目录：main和test。简单地将main放入将要交付的生产代码中的所有内容。 test目录包含main树的测试代码。

因此，通常src/main/java目录中的相同包层次结构也存在于src/test/java中，因此对于具有相同包定义的测试类，可以访问生产类的所有成员它位于main分支。