将单元测试引入现有项目

3
我正在处理一个现有的Java EE项目,其中包含各种在Eclipse中开发的Maven模块,并使用Java 1.6捆绑在一起并部署在JBoss上。我有机会准备任何框架并记录如何将单元测试引入项目。
您能给出以下建议吗?
- JUnit是我期望开始的地方,这仍然是Java开发人员的首选吗? - 有没有值得设置为标准的模拟框架?JMock? - 应该设置哪些规则 - 代码覆盖率,还是确保它是单元测试而不是集成测试。 - 是否有用于生成漂亮输出供项目经理欣赏的工具?
还有其他需要注意的事项吗?谢谢您的帮助。

EasyMock是最知名的模拟框架(看看谷歌搜索:P)。虽然名称不如jMock酷,但它更好。然而,Mockito允许您跳过创建模拟的一步(设置完成后无需重放(mock))。 - IAdapter
6个回答

3
关于单元测试框架,主要有两个:jUnit和TestNG。它们都有各自的优点,并且性能相当。我认为jUnit的主要优点是默认集成了Eclipse插件,可以方便地调用测试。
关于模拟框架,我认为它们不是测试方法必需的一部分。当然,它们很有用,但它们解决的是特定目的:测试行为(与测试接口相反-这是jUnit允许的)。使用模拟框架,您可以测试特定类如何实现特定接口。您需要它吗?显然。您首先需要它吗?我不知道。
关于规则,我发现唯一有用的规则是简单的(一如既往):“总是测试至少出现过一次错误的代码。”考虑您的错误跟踪器。每次遇到错误时,都必须有一个单元测试确保没有回归。在我看来,这是获得高质量代码的最快方法。

关于华丽高效的输出,我建议您安装一个持续集成服务器(Hudson)。每次提交代码时,它都会运行所有的测试套件,以确保没有副作用。它将生成图表显示测试运行的数量等等。它还可以集成代码覆盖工具和图表。这个持续集成服务器将成为您真正快速的测试伙伴。


这并不是模拟框架的真正目的。真正的目的是能够测试使用InterfaceB的ClassA,并模拟B以测试A在B执行这个或那个操作时的行为 - 从任何B的实现中完全隔离A的测试(否则您将同时测试两者,那就不是一个单元测试)。 - matt b

3

这是一个比较复杂的问题,以下是我们在$work实践中的一些笔记:

  • JUnit仍然是标准。大部分文档和资料都涉及JUnit。
  • Mockito似乎成为了Java模拟测试的新贵,尽管我们仍然使用JMock并认为它满足我们的需求。
  • 我们使用EclEmma Eclipse插件来检查我们的测试覆盖率,并且很喜欢它。

3
任何可以生成花哨输出以供项目经理欣赏的工具吗?
要小心。在一些项目经理手中,用于显示单元测试计数、覆盖率、代码质量指标、代码行数、提交次数等指标的花哨工具可能非常危险。如果一个(与软件开发实际情况不了解的)项目经理迷恋这些指标,他们会意识不到以下事实:
- 它们不能真实反映项目的健康状况和进展情况。 - 它们可能给出有关个别团队成员表现的完全错误的图片。
你可能会遇到荒唐的情况,其中一个经理向开发人员传达信息,要求他们(例如)尝试实现最大化单元测试覆盖范围的代码,而这根本不是必要的。花费时间在无用的工作上,忽略重要的工作,错过了截止日期。
有任何规则应该设置 - 代码覆盖率,或确保它是单元测试而非集成测试。
- 对于可能易碎/有缺陷的代码部分,代码覆盖率更为重要。可接受的覆盖水平应反映这一点。 - 单元测试与集成测试取决于正在构建的系统的性质和复杂性。 - 事后添加大量的单元级别测试可能是浪费时间的。它应该仅用于标识为有问题/需要维护工作的类。 - 事后添加集成级别测试非常有用,特别是如果项目的原始开发人员已不在场。一个体面的集成测试套件有助于增加您对某些更改不会破坏重要系统功能的信心。但这需要审慎进行。测试套件测试网站外观和感觉的N-th度数可能会让人头疼...也会阻碍进展。

2

0

我一直在对一个C++项目进行单元测试的改进,但这并不愉快。

首先,我要确定大部分“动作”发生在哪里。然后开始对可以轻松测试的函数进行单元测试。

然后,一旦你有了更容易的测试,你就可以开始扩展覆盖范围——攻击那些依赖较少的函数,在调试器中运行几次,看看传入的值是什么,然后编写单元测试来确保你不会破坏任何东西。

不要期望快速解决问题——花了3周(每周5天,每天6小时)才覆盖了20%的代码,但是代码中80%的时间都花费在那段代码上,所以我认为这是值得花费时间的,并且已经发现了相当多的错误。


0
关于测试覆盖率,我认为当你将单元测试引入现有项目时,开始设置覆盖率期望还为时过早。你应该先确保能够集成测试框架并从覆盖工具中获取报告。一旦完成这些步骤,你可以开始监控覆盖率,然后再考虑目标。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接