编写单元测试标准

我计划在我的团队中引入一套标准来编写单元测试.但要包括什么？

这两个帖子(单元测试命名最佳实践和单元/集成测试中文件系统依赖关系的最佳实践)给了我一些思考的东西.

我的标准中应该涵盖的其他领域应该是如何设置测试类以及如何组织它们.例如,如果您有一个名为OrderLineProcessor的类,那么应该有一个名为OrderLineProcessorTest的测试类.如果在该类上有一个名为Process()的方法,那么应该有一个名为ProcessTest的测试(可能更多来测试不同的状态).

还包括其他什么东西？

贵公司是否有单元测试标准？

编辑:我正在使用Visual Studio Team System 2008,我在C#.Net中开发

看看Michael Feathers关于什么是单元测试(或什么使得单元测试单元测试不好)

看看"安排,行动,断言"的想法,即测试只按固定顺序做三件事的想法:

排列测试所需的任何输入数据和处理类

执行测试中的操作

使用一个或多个断言测试结果.是的,它可以是多个断言,只要它们都可以测试所执行的操作.

了解行为驱动开发,以便将测试用例与需求保持一致.

此外,我对标准文档的看法是,除非必须,否则不应该编写它们 - 已经有很多可用的资源.链接到他们而不是重复他们的内容.为想要了解更多信息的开发人员提供阅读列表.

你应该看看"实用单元测试"系列. 这是C#版本,但Java还有另一个版本.

关于你的规范,我不会过分夸大.你有一个非常好的开始 - 命名约定非常重要.我们还要求目录结构与原始项目匹配.覆盖范围还需要扩展到边界案例和非法值(检查异常).这是显而易见的,但你的规范是写下这个论点的地方,你将来不可避免地会遇到那些不想测试通过非法值的人.但是,不要让规范超过几页,否则没有人会将它用于与上下文相关的任务.

更新:我不同意Potato Head先生每单元测试只有一个断言.这在理论上听起来很不错,但在实践中,它导致的大多是冗余测试或人在做吨的工作在建立和拆除,要么负荷本身应进行测试.

我遵循TDD的BDD风格.请参阅:http : //blog.daveastels.com/files/BDD_Intro.pdf http://dannorth.net/introducing-bdd http://behaviour-driven.org/Introduction

简而言之,这意味着

测试不被视为"测试",而是作为系统行为的规范(以下称为"规范").规范的目的不是验证系统在任何情况下都能正常工作.他们的目的是指定行为并推动系统的设计.

spec方法名称被写为完整的英语句子.例如,球的规格可以包括"球是圆的"和"当球击中地板然后它反弹".

生产类和规范类之间没有强制的1:1关系(并且为每种生产方法生成测试方法都是疯狂的).相反,系统的行为与规格之间存在1:1的关系.

前段时间我写了TDD教程(你开始使用提供的测试开始编写俄罗斯方块游戏),它将这种编写测试的样式显示为规范.您可以从http://www.orfjackal.net/tdd-tutorial/tdd-tutorial_2008-09-04.zip下载该教程中仍然缺少有关如何进行TDD/BDD的说明,但示例代码已准备就绪,因此您可以看到测试的组织方式并编写传递它们的代码.

您会注意到,在本教程中,生产类被命名为Board,Block,Piece和Tetrominoe,它们以俄罗斯方块游戏的概念为中心.但测试类围绕俄罗斯方块游戏的行为:FallingBlocksTest,RotatingPiecesOfBlocksTest,RotatingTetrominoesTest,FallingPiecesTest,MovingAFallingPieceTest,RotatingAFallingPieceTest等.