对于普通班级来说,进行单元测试覆盖是一种好习惯

Question

这是一个完全没有行为的类的例子.所以问题是我应该为它做单元测试覆盖,因为我认为它没有必要,因为它确实有任何行为.

public class Employee
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Address Address { get; set; }
}

我的代码覆盖率结果抱怨我没有为该课程做过任何报道

Answer 1

我从不为这些做过测试. 没有行为要测试.

如果有任何非平凡的行为代码(也许是验证代码),那么我会为它编写一个测试.

Answer 2

我从Martin Fowler那里找到了这篇有趣的文章:

测试覆盖率是查找未经测试的代码库部分的有用工具.测试覆盖率作为测试有多好的数字陈述几乎没用.

===

对象导师的这个有趣的引用:

它可能不是强制性的,如果您的目标是100%覆盖率,您将专注于该目标,而不是专注于为代码行为编写最佳测试.

Answer 3

我可以接受或离开它.但是,虽然现在几乎没有明显的好处,但如果程序员后来出现,将其转换为传统的,成员字段支持的属性,并在简单的情况下摸索实现,您将被覆盖.

但我个人实际上并不打扰,因为我的时间有限,而且我有更重要的测试要写,这将为我的降压提供更大的帮助.

Answer 4

Kent Beck在他的"按示例进行测试驱动开发"中列出了您应该测试的内容:

• 条件语句
• 循环
• 操作
• 多态性

你的班级没有这些.

通常会问自己一个问题,"如果我用单元测试覆盖这些代码,我会得到什么？" .如果"指向某些指标"是您可以提出的唯一答案,则可能不值得为此类代码编写测试.你会花时间,产生额外的代码,什么都得不到(代码覆盖"点"没什么价值 - 至少在这种情况下).

另外,看看这两个问题(它们都解决了类似的问题,答案主要解决一个重要问题 - [在大多数情况下]总会有人为你所做的事付钱 - 并且有人可能不会很高兴知道你花时间提高评级,因为这是它本质上是):

• 你的测试有多深？
• 何时进行单元测试？

定论？我同意其他人说你不应该测试这些课程.

Answer 5

这并不是一个坏主意......例如,假设你开发了一个后端来存储未来的数据(例如数据库).您可以get; set;使用其他自定义功能替换通用调用.进行单元测试可确保始终执行代码,并且不会在转换中引入错误.

即使是一个非常简单的测试,它会检查您是否可以创建对象,设置字段以及读回相同的值,这表明您正在使用预期的行为来执行代码.即使对您来说显而易见,该代码的未来开发人员也可以使用该示例进行绘制,并确保所有更改都符合您的原始设计目标.

我也是这样看待:在开发测试时几乎没有任何伤害,具有一些非常可能的长期优势.现在只需几分钟就可以跟踪线下引入的问题.

Answer 6

替代方案:您没有覆盖此特定类的事实暗示有一些代码使用此类,并且该代码也没有测试覆盖率.我先解决这个问题,看看是否需要更多的测试.

至于测试这样的仅数据对象:如果此对象是库/单元的外部合同的一部分,我肯定会添加显式测试.您承诺您的代码将返回/使用此数据.如果没有测试验证您可以更改代码的内部并更改此类,您将违背承诺,没有任何阻止您.