JUnit消息是否应说明成功或失败的条件?

Jas*_*hen 62 java junit unit-testing

我可以用两种方式之一来编写断言消息.陈述成功:

assertEquals( "objects should be identical", expected, actual );
Run Code Online (Sandbox Code Playgroud)

或说明被打破的情况:

assertEquals( "objects aren't identical", expected, actual );
Run Code Online (Sandbox Code Playgroud)

JUnit中是否有这样的标准?如果没有,每一方的论据是什么?

PS我在网上看到的文章证明了这两个没有解释,所以只是说"搜索谷歌"不是一个答案!

[UPDATE]

每个人都对我使用的事实感到困惑assertEquals,因此消息可能毫无用处.但当然那只是因为我想简单地说明这个问题.

所以想象一下:

assertTrue( ... big long multi-line expression ... );
Run Code Online (Sandbox Code Playgroud)

消息有用的地方.

Jon*_*eet 31

我甚至很少打扰消息,至少对于assertEquals.任何明智的测试跑步者都会解释你正在使用assertEquals的两件事情本来是平等的.您的消息都没有提供更多信息.

我经常发现单元测试失败是暂时的 - 我会很快找出错误并修复它."发现什么是错的"通常涉及足够的细节,单个消息不会产生太大的影响.考虑"通过消息节省时间"vs"花时间思考消息":)

编辑:好的,我可以使用一个消息的一种情况:当文本中有一个紧凑的描述时,从对象的字符串表示中不明显.

例如:"比较存储为毫秒的日期"的"预期日期为12月1日".

我不会担心你是如何准确地表达它的:只要确保从你的意思中你的信息显而易见."应该是"或"不是"是好的 - 只是"12月1日"并不明显.

  • 在进行单元测试时,我发现我将测试方法命名得越多,因此很清楚预期的行为是什么,我需要为assertEquals(),fail()指定消息的次数越少.如果我确实需要一条消息,通常会表明测试过多,这可能意味着需要修改测试中的代码.拥有良好的测试名称还有许多其他优点. (11认同)
  • 我倾向于同意,但你没有回答这个问题.*当*消息有意义时 - 有时它确实如此 - 你怎么说出来?我问一个API定义问题,所以说"不要使用API​​"不是答案. (4认同)
  • 这是添加到断言失败的消息的示例 - assertEquals("当没有现有的对冲时滚动值不为零.",新的BigDecimal("0.00"),hedgeValue.getRoll()) - 它告诉任何人看到断言失败,为什么你期望2个值相等. (2认同)

Ret*_*mür 22

根据junit API,消息是"AssertionError的标识消息",因此它不是描述应该满足的条件的消息,而是描述如果不满足条件则出错的消息.所以在你的例子中"对象不相同"似乎更符合要求.


Mat*_*ola 9

与许多其他人不同,我觉得使用消息非常有用,原因有很多:

  1. 查看测试失败日志的人可能不是编写测试的人.阅读代码并了解断言要解决的案例需要花费一些时间.有用的信息可以节省时间.

  2. 即使在测试开发人员正在查看日志的情况下,自编写测试以来可能已经过了几天或几个月,并且消息可以节省时间.

我的建议是写一条消息,说明预期的行为.例如:

assertEquals("The method should be invoked 3 times", 3, invocationCount);
Run Code Online (Sandbox Code Playgroud)