java我们从哪里开始使用单元测试？

Question

我们从哪里开始使用单元测试
我对从哪里开始使用单元测试有些怀疑
我在RAD中使用Junit进行单元测试。我是在所有代码都准备好部署或者可能在部署之后才这么做的。我不明白为什么我们在代码几乎准备好部署之后还要进行单元测试
我的问题是我们应该什么时候开始单元测试

我还有一些问题
我在单元测试中所做的是从一个类中提取一个方法，并为该方法创建一个测试类
在这个类中，我给这个方法提供了一些输入值，并期望从数据库中得到尊重的输出值
现在，单一测试类不需要输入值->；将其传递给方法->；从原始类调用方法->；数据库连接->；正在从数据库中获取值->；将其返回到测试类

如果测试成功运行，Junit控制台将显示绿色条，否则显示红色条
带有错误原因的红色条。但它不会生成任何单元测试报告

现在是我的问题
我在做正确的单元测试吗？由于单个单元测试方法包含所有代码流并给出结果

Answer 1

进行认证开发需要遵循定义的开发模型。最常用的模型是V模型，简单地说，它定义了需求、规范、子规范（例如组件、模块或单元的规范）等。在V的左分支上自上而下。当规范定义了一个不能合理地分解为更小部分的原子单元时，你最终会到达V的底部

在V模型的右侧分支上，您可以验证所开发的模块是否符合其规格和/或要求。通常用于并行创建测试，或在实现UUT（被测单元）之前创建测试。 通过这种方式，您可以测量任何模块从一开始就适合其框架，甚至在进行一些返工时

正如其他人所说，尽可能使用mock等工具使测试尽可能简单。您还应该自动化您的测试，至少是那些与位于V底部附近的模块相关的测试，因为这些测试通常比顶部附近的测试运行得更频繁

当你的测试有一个定义良好的输出时，做正确的报告就容易多了。我们通常有一个枚举结构（通过、失败、错误）、一个状态号和一条消息文本

Answer 2

您应该尽早开发单元测试。事实上，最好的解决方案是在实现要测试的类之前开发它们。然后，每次向类中添加重要功能时，都要运行它们

顾名思义，单元测试用于测试操作的“单元”。你不应该让一个测试执行太多。此外，单元测试应该是测试单个类的功能

你在这里描述的更像是系统测试。这是一件很好的事情，但它与单元测试完全不同

Answer 3

如果你还没有开始单元测试的话，最好现在就开始。单元测试最有效的用途是测试驱动开发（TDD），在TDD中，您在实现每个方法时为其编写测试（编写一个失败的测试，然后实现该方法以使其通过）。然而，现在添加测试还不算晚。JUnit测试巩固了关于代码的某些假设，这些假设可能会在以后发生变化。如果假设发生变化，测试就会中断，你可能会从一些很难检测到的错误中解脱出来

我不知道有什么报表工具，但您可以添加一个JUnit ANT任务，它将测试结果输出到构建控制台（或者日志，如果捕获了ANT输出）

数据库测试听起来像小型集成测试，而不是单元测试。这很好，但是如果测试太慢，你可能想考虑使用模拟对象（通过像JMOCK或EasyMoCK之类的框架）来代替真实的DB连接。这将方法的逻辑与数据库的状态和行为隔离开来，并允许您运行测试，而无需担心数据库是否正在运行并存储测试数据

有用的链接：

http://en.wikipedia.org/wiki/Test-driven_development

http://www.jmock.org/

http://easymock.org/

http://ideoplex.com/id/25/ant-and-junit

http://ant.apache.org/manual/Tasks/junit.html

http://misko.hevery.com/code-reviewers-guide/（编写单元可测试代码指南）

[编辑-回应评论]： 关于你所做的是否是正确的单元测试，从技术上来说，答案是“否”。正如我所说，它更像是一个集成测试，这很好，但它做得太多，依赖性太多，不能被视为真正的单元测试。理想情况下，单元测试将测试方法中的逻辑，而不是依赖关系。上面提到的编写可测试代码的指南（以及Misko Hevery的相关博客）提供了一些很好的建议，说明如何编写带有接缝的代码，以插入依赖项的模拟。迈克尔·费瑟在他的优秀著作Working Effectively with Legacy Code中深入探讨了这个问题

关键因素是依赖项注入：可测试方法不寻找它们的依赖项——它们在构造函数中或作为参数接收它们。如果这需要太多重构，可以尝试一些技巧，例如将查找依赖项的代码移动到可以覆盖的受保护或包可见方法中。然后在一个子类上运行测试，该子类从这些方法返回模拟对象