当我第一次听说可以使用JUnit等框架进行单元测试时，我很惊讶这是一个多么简单但功能强大的概念。它取代了随机测试，允许您保存测试代码并在需要时运行它们。据我了解，对单元测试没有太多误解的余地。但是在过去的几年里，我确实看到了几种或多或少不正确的单元测试使用方式。以下是按重要性排序的5项：1.使用协作逻辑测试算法。如果算法逻辑与协作逻辑代码分开，那么它最容易测试（请参阅可选单元测试-成本和收益）。否则，您必须先通过作业队列提交作业，然后才能测试您的逻辑。任务队列部分只会使事情复杂化。除非你想测试任务队列本身，否则你应该将调用run方法时执行的逻辑分离出来单独测试。这样，编码和测试都将更易于编写和管理。2.模拟考试过多。也许单元测试的最大好处是它迫使您编写可以单独测试的代码。也就是说，您的代码变得模块化。当您围绕所处理的对象对所有事物进行建模时，没有什么会迫使您将各个部分分开。您会发现，使用这样编写的代码，很难在周边添加单独的部分-因为所有内容都纠缠在一起。BillWake最近在推特上写道：“多么讽刺——模拟测试框架越强大，你改进设计的压力就越小。”3.不要使用断言。有时我看到一些测试，它们创建了一个对象，调用了一些方法，然后就没有了。可能是在循环中这样做，创建和调用有些区别。但是，没有断言用于进行任何检查。这完全没有意义-没有检查您的代码是否按预期工作。当然，代码运行了，但仅此而已。如果抛出异常，我们会注意到它，但不会验证任何其他内容。4.在测试代码中保留打印语句。我认为这是手动测试的后遗症——您想查看对象的值以判断它们是否正确。但是所有检查都应该使用断言来完成。如果单元失败，您也能看到它，因为测试也会失败。测试通过后，不应打印任何内容。在编写测试代码时，有时使用print语句很有用。但是在需要打印的地方应该设置一个flag，在测试的时候屏蔽掉。5、查看日志信息，不查看运行结果。幸运的是，这并不常见，但我见过一位非常有能力的开发人员这样做。要知道真正重要的是方法的结果，而不是日志中打印的内容，因为即使代码有错误，测试也可能通过。好吧，我说得很清楚了。后三个问题很容易避免。前2个问题需要更多的努力，但会导致代码分离良好。测试愉快！英文原文：5UnitTestingMistakes翻译链接：http://www.oschina.net/translate/5-unit-testing-mistakes
