在本文的上半部分 ，您可能会看到一些不好但很流行的测试示例。 但是我不是一个专业评论家（也被称为“巨魔”或“仇恨者”），没有任何建设性的话就抱怨。 多年的TDD教给我的不仅仅是事情会变得多么糟糕。 有许多简单但有效的技巧，可以使您的测试生活变得更加轻松。

想象一下：您有一家小公司中一间小型会议室的预订系统。 由于某些奇怪的原因，它必须处理离线预订。 人们将他们的预订请求发布到某个前端，每周一次，您会获得一个文本文件，其中包含公司的工作时间以及所有的预订（在当天，多长时间，由谁，在什么时间点提交）订购。 您的系统应根据一些业务规则（先到先得，仅在办公室工作时间内提供此类服务）为房间生成日历。

作为分析的一部分，我们提供了明确定义的输入数据和预期结果，并带有示例。 确实，TDD的情况很好。 可悲的是，在现实生活中从来没有发生过这样的事情。

我们的示例测试数据如下所示：

class TestData {static final String INPUT_FIRST_LINE = '0900 1730\n';static final String FIRST_BOOKING    = '2011-03-17 10:17:06 EMP001\n' +'2011-03-21 09:00 2\n';static final String SECOND_BOOKING   = '2011-03-16 12:34:56 EMP002\n' +'2011-03-21 09:00 2\n';static final String THIRD_BOOKING    = '2011-03-16 09:28:23 EMP003\n' +'2011-03-22 14:00 2\n';static final String FOURTH_BOOKING   = '2011-03-17 10:17:06 EMP004\n' +'2011-03-22 16:00 1\n';static final String FIFTH_BOOKING    = '2011-03-15 17:29:12 EMP005\n' +'2011-03-21 16:00 3';static final String INPUT_BOOKING_LINES =FIRST_BOOKING +SECOND_BOOKING +THIRD_BOOKING +FOURTH_BOOKING +FIFTH_BOOKING;static final String CORRECT_INPUT = INPUT_FIRST_LINE + INPUT_BOOKING_LINES;static final String CORRECT_OUTPUT = '2011-03-21\n' +'09:00 11:00 EMP002\n' +'2011-03-22\n' +'14:00 16:00 EMP003\n' +'16:00 17:00 EMP004\n' +'';
}

现在，我们从一个积极的测试开始：

BookingCalendarGenerator bookingCalendarGenerator =  new BookingCalendarGenerator();@Test
public void shouldPrepareBookingCalendar() {//whenString calendar = bookingCalendarGenerator.generate(TestData.CORRECT_INPUT);//thenassertEquals(TestData.CORRECT_OUTPUT, calendar);
}

看起来我们已经使用“生成”方法设计了BookingCalendarGenerator。 很公平。 让我们添加更多测试。 测试业务规则。 我们得到这样的东西：

@Testpublic void noPartOfMeetingMayFallOutsideOfficeHours() {//givenString tooEarlyBooking = '2011-03-16 12:34:56 EMP002\n' +'2011-03-21 06:00 2\n';String tooLateBooking = '2011-03-16 12:34:56 EMP002\n' +'2011-03-21 20:00 2\n';//whenString calendar = bookingCalendarGenerator.generate(TestData.INPUT_FIRST_LINE + tooEarlyBooking + tooLateBooking);//thenassertTrue(calendar.isEmpty());}@Testpublic void meetingsMayNotOverlap() {//givenString firstMeeting = '2011-03-10 12:34:56 EMP002\n' +'2011-03-21 16:00 1\n';String secondMeeting = '2011-03-16 12:34:56 EMP002\n' +'2011-03-21 15:00 2\n';//whenString calendar = bookingCalendarGenerator.generate(TestData.INPUT_FIRST_LINE + firstMeeting + secondMeeting);//thenassertEquals('2011-03-21\n' +'16:00 17:00 EMP002\n', calendar);}@Testpublic void bookingsMustBeProcessedInSubmitOrder() {//givenString firstMeeting = '2011-03-17 12:34:56 EMP002\n' +'2011-03-21 16:00 1\n';String secondMeeting = '2011-03-16 12:34:56 EMP002\n' +'2011-03-21 15:00 2\n';//whenString calendar = bookingCalendarGenerator.generate(TestData.INPUT_FIRST_LINE + firstMeeting + secondMeeting);//thenassertEquals('2011-03-21\n15:00 17:00 EMP002\n', calendar);}@Testpublic void orderingOfBookingSubmissionShouldNotAffectOutcome() {//givenList<String> shuffledBookings = newArrayList(TestData.FIRST_BOOKING, TestData.SECOND_BOOKING,TestData.THIRD_BOOKING, TestData.FOURTH_BOOKING, TestData.FIFTH_BOOKING);shuffle(shuffledBookings);String inputBookingLines = Joiner.on('\n').join(shuffledBookings);//whenString calendar = bookingCalendarGenerator.generate(TestData.INPUT_FIRST_LINE + inputBookingLines);//thenassertEquals(TestData.CORRECT_OUTPUT, calendar);}

仅此而已。 但是，如果我们得到一些垃圾作为输入怎么办。 还是如果我们得到一个空字符串？ 让我们为此设计：

@Test(expected = IllegalArgumentException.class)public void rubbishInputDataShouldEndWithException() {//whenString calendar = bookingCalendarGenerator.generate('rubbish');//then exception is thrown}@Test(expected = IllegalArgumentException.class)public void emptyInputDataShouldEndWithException() {//whenString calendar = bookingCalendarGenerator.generate('');//then exception is thrown}

IllegalArgumentException很公平。 我们不需要再花哨的方式处理它。 我们已经完成了。 最后，让我们在测试下编写该类：BookingCalendarGenerator。

因此，我们做到了。 结果表明，对于一个方法来说，整个过程有点大。 因此，我们使用了“提取方法”模式的强大功能。 我们将代码片段分为不同的方法。 我们将进行操作的方法和数据分组为类。 我们使用面向对象编程的功能，使用单一职责原理，使用合成（确切地说是分解），最后得到一个像这样的包：

我们有一个公共类，和几个包作用域类。 这些包范围类显然属于公共类。 这是一个清晰的类图：

那些不是愚蠢的数据对象。 这些是成熟的课程。 具有行为，责任感和封装感。 这是我们测试驱动者可能想到的一件事：我们没有针对这些类的测试。 我们只有公共班级。 不好，对吧？ 没有测试一定是不好的。 很坏。 对？

错误。

我们有测试。 我们启动了代码覆盖率工具，然后看到：100％方法和类。 95％的线。 不错（在下一篇文章中，我将达到不确定性的5％）。

但是我们只有一个单元测试类。 这样好吗

好吧，让我强调一下，指出答案：

这是一个UNIT测试。 有理由将其称为UNIT测试！

该单元不必是一个单一的类。 该单元不必是单个包装。 由您决定单位。 这是一个通用名称，因为您的理智和常识应该告诉您停止的地方。

因此，我们有六个班级作为一个单元，有什么大不了的？ 除了其余部分，有人是否要使用其中一个类呢？ 他不会对此进行测试，对吗？

错误。 除了在测试中实际调用的类之外​​，这些类都是包范围的。 这个包裹范围的事情告诉您：“退后一步。 不要碰我，我属于这个包裹。 不要试图单独使用我，我是设计在这里！”。

因此，是的，如果程序员将其中之一删除或公开，则他可能会知道，所有保证都将失效。 写你自己的测试，伙计。

我被问到是否有人要向其中一个类添加某些行为呢？ 他怎么会知道他没有破坏什么？

好吧，他将从测试开始，对吗？ 是TDD，对不对？ 如果您有需求变更，则可以将此变更编码为测试，然后，直到那时，您才开始弄乱代码。 因此，您是安全的。

我看到人们盲目地写每堂课的测试，却没有思考，这让我哭了。 我最近做了很多配对编程，您知道我发现了什么吗？ Java程序员通常不使用package-scope。 Java程序员通常不知道，受保护的意思是：对我来说，我的所有后代和每个人都在同一软件包中。 没错，受保护不仅仅是包范围，更不是一点点。 因此，如果Java程序员不知道包范围实际上是什么，并且与Groovy相反，那是默认的，那么他们如何理解单元是什么？

我能得到多高？

现在，有一个有趣的想法：如果我们可以对一个包进行单个测试，那么我们可以对一个包树进行单个测试。 你知道，像这样：

我们都知道Java包不是真正的树状包，唯一具有目录结构的是按照非常古老的约定，而且我们知道目录结构仅用于解决名称冲突问题，尽管如此，我们还是倾向于使用包，就像name.after.the.dot有意义一样。 就像我们可以将一个包裹隐藏在另一个包裹中一样。 或与他们建立千层面的烤宽面条。

那么可以为一个树形树使用一个测试类吗？

是的。

但是，如果是这样，到哪里结束？ 我们可以从包树一直到应用程序的入口点吗？ 那些……也许是集成测试或功能测试。 我们能做到吗？ 那会好吗？

答案是：可以。 在一个完美的世界中，那会很好。 在我们那肮脏的，悬挂在刀刃上的世界里，那简直是疯了。 为什么？ 因为功能性的端到端测试很慢。 太慢了。 太慢了，以至于您想将它们扔掉，然后到某个地方，而不必总是等待某些东西。 一个充满创造力，持续反馈和闪电般快速安全的地方。

您将返回单元测试。

甚至还有更多原因。 一种是，很难对应用程序的所有流进行端到端测试。 您可能应该对所有主要流程都执行此操作，但是对于错误，连接不良以及所有可能在某一点或另一点抛出的棘手逻辑部分呢？ 不，有时候像这样为集成测试设置环境会太困难了，所以最终还是要用单元测试来测试它。

第二个原因是，尽管功能测试并未在代码上浇注具体的内容，但不会通过在测试用例中重复执行算法来抑制您的创造力，但是它们也没有提供重构的安全性。 当您拥有一个带有单个公共类的程序包时，很明显有人可以安全地做什么，而他不能做什么。 当您将某些内容包含在库或插件中时，它仍然很明显。 但是，如果您有成千上万个公共类，并且要实现一个新功能，则可能要使用其中一些，并且您想知道它们很好。

因此，不，在我们的世界中，仅进行功能测试是没有意义的。 抱歉。 但是为每个类创建测试也没有意义。 出于某种原因，它称为UNIT测试。 用那个

祝您编程愉快，别忘了分享！

参考：“ 测试驱动陷阱”，来自我们JCG合作伙伴 Jakub Nabrdalik的第2部分 ，在Solid Craft博客上。