使用NetBeans 7.4 beta提示进行更好的基于JUnit的单元测试

在上一篇文章中，我写了NetBeans 7.4 beta中提供的提示，这些提示提高了开发人员避免Java异常处理带来的讨厌的运行时问题的能力。在本文中，我将研究如何使用NetBeans 7.4 beta提供的另外两个提示使单元测试在执行单元测试期间更加正确和清晰。这些是“ Assert.assertEquals的不可转换参数”和“ Assert.assertEquals的参数顺序错误”提示。

就我从轶事证据和与其他Java开发人员的交谈中所知，JUnit仍然是Java环境中使用最广泛的单元测试框架。这些大多数JUnit用户都非常熟悉JUnit的Assert类及其许多重载的assertEquals方法。 NetBeans 7.4 beta现在提供了两个提示，以使更容易适当地使用这些assertEquals方法。

尽管许多Assert.assertEquals()方法对于要声明为相等的“期望”和“实际”参数都有非常特定的数据类型，但是有一个版本可以接受两个对象，这意味着两个不同类型的参数不可能被认为是“相等”的方法仍然可以传递给该方法。编译器无法阻止这种情况，但是NetBeans 7.4 beta包含了“ Assert.assertEquals的不可转换参数”提示来解决该特定情况。没有这样的提示，一个人更有可能直到他或她运行JUnit测试并看到失败的断言才意识到自己的错误。

我在使用JUnit时遇到的最常见问题之一（也是我喜欢Hamcrest的流畅API 的原因之一）是，我似乎无法确切地记住assertEquals方法的参数顺序。通过猜测，我有50/50的几率是正确的。诸如NetBeans之类的现代Java IDE在编写新的JUnit代码时有很大帮助，因为它们的方法完成功能将指示首先指定“ expected”参数，然后指定“ actual”参数。更常见的是，这是读取代码而不是编写代码时的问题，因为没有方法完成可以帮助我读取代码。 NetBeans 7.4 beta通过突出显示我通过“ Assert.assertEquals参数的错误顺序”提示混淆了参数顺序的情况来解决此问题。启用该提示（默认情况下为默认），我可以在运行时甚至在没有方法完成的情况下，快速识别出乱序的参数。

上面讨论的两个提示都可以在非常简单的单元测试类中进行演示。

CalculatorTest.java的一部分

/*** Test Calculator.sum(int ...).*/
@Test
public void TestSumIntegers()
{final Calculator calculator = new Calculator();Assert.assertEquals(calculator.add(1, 2, 3, 4, 5), 15);Assert.assertEquals("15", calculator.add(1, 2, 3, 4, 5));
}

上面的单元测试方法正在测试的代码对于此讨论并不重要。相反，重点是在两种情况下使用Assert.assertEquals 。上面显示的两种情况都是不正确的，并强制演示了前面讨论的两个NetBeans提示。断言两个对象相等的第一次尝试是将参数按错误的顺序放置。应首先列出“预期”值（硬编码为15），然后是由测试方法计算出的“实际”值。断言两个对象相等的第二次尝试总是会失败，因为类型不匹配：第一个参数是String，第二个参数是整数。在这两种情况下，单元测试代码都可以毫无抱怨地进行编译。但是，在运行单元测试时，两个断言总是会失败。实际上，这些测试结果可能会无意中被解释为正在测试的代码的问题，直到有人更深入地查看测试失败为止。

接下来的两个屏幕快照演示了NetBeans 7.4 beta标记了两个有问题的单元测试断言语句。

orderParametersAssertEqualsIncorrect

parametersAssertEqualsInconvertibleTypes

关于“ Assert.assertEquals参数的顺序不正确”提示，有一点需要注意。当断言语句类似于我的示例中所示的语句时，它会很好地工作：提供一个硬编码的期望值作为“实际”值，同时提供一个明显的计算值作为“期望”值。下一个屏幕快照说明了这一点。提示仅标记了我之前显示的语句，即使顺序不正确，也未标记其他将实际与预期进行比较的方法。

orderParametersPickyAboutDetection

最后显示的屏幕快照表明，在语句中直接访问这些值的情况下，NetBeans提示只能检测到错误的assertEquals参数顺序（应该在实际值之前预期，而不是在实际值之前预期）。为第一个[expected]参数执行，并为第二[actual]参数提供预期的硬编码值）。

本博客文章中涉及的两个提示使使用常用的JUnit Assert.assertEquals方法更容易发现问题，这些问题只有在没有提示的情况下分析单元测试运行结果才可能被发现。尽管这些提示警告开发人员的两个问题通常很容易检测和修复，但是与NetBeans IDE在运行测试之前告诉您它们是错误的相比，检测和修复这些问题仍然更加困难且耗时。

参考：来自NetBeans 7.4 beta的更好的基于JUnit的单元测试，来自我们的JCG合作伙伴 Dustin Marx，来自Inspired by Actual Events博客。