繁体   English   中英

有效的Java项目13和TDD

[英]Effective Java Item 13 and TDD

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

第13项(我正在看第二版)的标题为“最小化类和成员的可访问性”。 在几页之后,他说:

为了方便测试,您可能会想让类,接口或成员*更易于访问。 ...可以将公共类包的私有成员设为私有,以便对其进行测试,但是将可访问性提高到更高水平是不可接受的...幸运的是,也没有必要,因为可以使测试作为要测试的程序包的一部分运行,从而可以访问其程序包专用元素。

*“成员”一词的意思是“字段,方法,嵌套类和嵌套接口”。

作为TDD的新手,但逐渐找到了自己的脚,我知道当前的共识似乎是不将测试类与应用程序代码包一起包括在内,甚至不在src \\ test和src \\ main下具有匹配的结构:主要是TDD专家似乎很容易以其他方式构建测试目录(例如,您有一个目录称为“ unittests”,另一个目录名为“ functionaltests”,另一个目录名为“ e2etests”)。

具体来说,我在“测试指导下的面向对象的增长软件”中关注了拍卖应用程序的TDD开发。 作者对添加数百种公共方法毫不犹豫。 此外,在一章之后,我查看了下载的“到目前为止的结构”,他完全改变了测试目录的结构,将事物划分为测试类别。

至少在过去,是否有经验丰富的TDD派发者认为这是两难的根源? 如果是这样,您如何解决?

作为一个实际的例子,我通过开发Lucene索引应用程序来尽力使用TDD技术:它对文档进行索引,然后让您查询它们。 当前,所有应用程序类都在同一包中。 真正需要公开的唯一方法是在一类中使用main 但是,当然,我有很多公共方法:如果不是因为我正在使用TDD,它们可能都是私有的。

PS没有“方法可见性”的标签,所以我选择了“类可见性”

后来

看来我可能已被“成长面向对象...”中采用的方法引向了一条相当不幸的道路,在该方法中,大概是因为对公共方法的证明而过度使用了公共方法。 哈。

如果您想划分测试类别,是否有人会使用这种方法:

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

而且,例如:
\\src\\func_tests\\java\\core\\MainTest.java

\\src\\e2e_tests\\java\\core\\MainTest.java

因为可以将测试作为要测试的软件包的一部分运行

这并不意味着您必须将测试与主类放在相同的目录中,它们只必须位于同一包中即可,这可以是单独的目录。

假设您有一个包com.acme.foo 因此,您的目录结构可能是:

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

MainClassTest是在同一个包MainClass所以它可以访问包私人的东西。 但是这些是单独的目录,因此生成的JAR将不包含MainClassTest

我不确定这在Gradle中是如何工作的,因为我正在使用Maven,但是我想那里的概念是相似的。 因此,我将牢记Maven进行解释。 Maven项目中的典型设置如下所示:

在此处输入图片说明

在项目的根目录上有srctarget 将在构建过程中创建的所有内容放入target文件夹。 这意味着src包含我们实际项目的源代码。 src还有另外两个目录: maintest 只需将main内容放入生产代码中即可交付的所有内容。 test目录包含main树的测试代码。

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

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM