【问题标题】:Unit Testing Asserts Query单元测试断言查询
【发布时间】:2013-11-15 04:58:08
【问题描述】:

我有一个执行各种功能的函数类(我知道,这很令人震惊)。 一个这样的功能是返回给定年份的公共假期列表。 每个计算都有自己的私有函数,因此公共函数实际上只是将各种假期编译成一个列表。

现在我想对此运行一些测试,显然我无法在私有方法上运行测试,所以我在 TestInitialize 方法中拉出列表,然后使用它进行各种测试。

问题是,假设我用list.SingleOrDefault(p => p.HolidayName.Equals("New Year's Day")) 之类的东西退出元旦,那么最好在运行预期的测试之前检查它是否为空(它应该在工作日,据我所知tell 本身就是两个断言...)。

所以,我想有两个问题。
1. 这种情况是每个单元测试1个断言规则的例外吗?还是我需要将空断言和周末断言分开?
2. 据我所知,将有两个断言来确保它不是在周末;一个检查星期几是否不等于星期六,一个检查星期几是否不等于星期日。还是我错了?

【问题讨论】:

  • 为什么不能只测试公共方法?如果它们正常工作,则可以假设它们调用的私有方法正常工作。没有?
  • 我可以的。我仍然有从列表中拉出每个公共假期并检查它是否不为空且正确的问题。
  • 也许是我。争论是否应该在这里或那里检查 null 似乎很挑剔。只要你验证数据真的很重要吗?至于问题 #2 是的,如果您担心域溢出,请务必这样做。换句话说,如果您正在测试int,那么 1 + 1 = 2 就足够了。 2 + 2 = 4 是不必要的,因为它测试的是同一个域。其他仍需要测试的域是负号和大号。

标签: c# unit-testing


【解决方案1】:

其中一个功能是返回给定年份的公共假期列表。

这是你的合同,这是你应该测试的。

每个计算都有自己的私有函数,因此公共函数实际上只是将各种假期编译成一个列表。

这无关紧要,你不应该关心东西从内部看起来如何。

现在,您的主要方法需要在给定年份的每个预期假期进行 1 次单元测试。在此类测试中,您将检查假期详细信息:日期、日期、名称 - 使用 多个断言。除此之外,您的方法可能需要一些边界检查(因为它适用于年份范围)和输入值验证(例如,确保年份实际上代表年份)。

一些建议:

  • 在测试时,始终尝试思考我的方法调用者期望什么?然后围绕这些假设编写测试。您的调用者需要假期列表,这应该是您在测试此方法时的主要关注点。
  • 每次测试 1 个断言是非常危险的误解。这不是关于单个 Assert.AreEqual ... 调用 - 它是关于验证一个逻辑概念(如提到的 herehere)。在您的情况下,holiday 就是这样的概念。您通过检查所有必需的属性来验证它(断言其正确性)。除非您知道假期是什么,否则知道假期有正确的日期是毫无价值的。

【讨论】:

  • 好的,太好了。和我想的一样,谢谢你的确认。在你和 Ondrej 之间,我想我已经得到了答案。
【解决方案2】:

您已经知道您不能测试私有方法,但是您可以测试内部方法,如果在您的情况下将它们设置为内部方法有意义的话。如果没有意义,请将它们设为私有并按照您的尝试对其进行测试。

至于第一个问题,您实际上不必遵守所有规则。如果您是该项目的单身人士,请跟随您的感受。我想不出我写过的任何测试都只包含一个断言。大多数测试框架都可以指出测试过程中到底出了什么问题。首先检查 null 然后检查期望值是一种完美的感觉。

至于第二个问题,您根本不需要两个断言。在您的应用程序中像枚举值一样识别日期是有意义的。

public enum WeekDays
{
    Monday = 0
    Tuesday = 1
    ...
}

然后您可以轻松地断言如下

Assert.IsTrue(holiday.WeekDay < WeekDays.Saturday);

如果您从Monday 开始,您甚至不必为工作日指定int 值。如果您在顶部有 Sunday,请确保给它一个值 6,而 Monday 将为 0。在 MSDN 上阅读更多关于底层 enum 值的信息。

如果你不能或不想将它作为枚举,你仍然可以用一个断言来实现它,尽管它不会那么漂亮。

Assert.IsFalse(holiday.WeekDay.StartsWith("S")); // assuming that the WeekDay is a string

【讨论】:

  • 一个简单的检查,当然 -_- 当我问这个问题时,大脑一定已经崩溃了。
  • 感谢对多个断言的澄清,jimmy_keen 也说了同样的话,是的,对我来说,即使“规则”说 1 断言,首先测试 null 很有意义。我猜这些规则是在测试框架还很基础的时候写回来的。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-04-26
  • 1970-01-01
  • 1970-01-01
  • 2014-08-12
相关资源
最近更新 更多