当前位置:  开发笔记 > 运维 > 正文

应该为简单的POCO域对象编写哪些单元测试?

如何解决《应该为简单的POCO域对象编写哪些单元测试?》经验,为你挑选了2个好方法。

所以标准的敏捷哲学会建议你的域类是简单的POCO,这些POCO是通过数据访问对象使用单独的代理层保持的(就像NHibernate那样).它还建议尽可能提高单元测试覆盖率.

为这些简单的POCO对象编写测试是否有意义?假设我有一个类似下面的类:

public class Container {
 public int ContainerId { get; set;}
 public string Name { get; set;}
 public IList Contents { get; set;}
}

我可以为此编写哪些有用的单元测试?



1> Jeffrey Fred..:

通常,像这样的值对象不需要有自己的测试.您将从使用它来实际执行某些操作的类中获得覆盖.

单元测试旨在测试行为.没有行为?无需测试.



2> tvanfosson..:

实际上,我认为如果你在编写类之前开始为这段代码编写测试,那么你的实现会有所不同.例如,您可能最终编写一个初始化集合的构造函数,以便您可以引用它而无需每次都检查null.我认为即使您认为不需要它们,也可以编写测试.通常在编写测试时,您会发现有很多假设是您在第一次尝试代码时无法解决的.

例如,ContainerId可能小于零吗?尝试将其设置为负值会是错误的吗?是否应该由构造函数初始化集合,即,使用此容器类的类是否必须在访问之前检查null,或者您是否希望保证集合永远不会为null,尽管它可能为空?

也就是说,我通常对这个过程应用一些理智.例如,如果我知道构造函数是内部作用域的,对象只是由Factory类创建的.我将测试工厂方法以确保它们始终生成合法对象,但不一定要测试容器类本身.

无论如何,我想底线是假设类需要测试,尝试编写它们,并且只有当我想不出有意义的测试时才省略它们.

推荐阅读
吻过彩虹的脸_378
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有