Tho*_*n79 11 language-agnostic documentation unit-testing
我想知道那些记录单元测试如何记录它的人.据我所知,大多数TDD粉丝声称"代码说话",因此测试文档不是很重要,因为代码应该是自我描述的.很公平,但我想知道如何记录单元测试,而不是是否记录它们.
我作为开发人员的经验告诉我,理解旧代码(包括单元测试)很困难.
那么在测试文档中重要的是什么？何时测试方法名称的描述性不够,以便证明文档合理？
Ore*_*ost 11
根据Thorsten79的要求,我将详细说明我的评论作为答案.我原来的评论是:
"代码说话"是不幸的是完全错误的,因为一个非开发者无法读取代码,而他至少可以部分地阅读和理解生成的文档,这样一来他就可以知道是什么测试的测试.这在客户完全理解域并且无法读取代码的情况下尤其重要,并且在单元测试也测试硬件时变得更加重要,例如在嵌入式世界中,因为那时您可以测试可见的内容.
当你进行单元测试时,你必须知道你是为你(或你的同事)写的,还是你也是为别人写的.很多时候,您应该为您的读者编写代码,而不是为了您的方便.
在我公司的混合硬件/软件开发中,客户知道他们想要什么.如果他们的现场设备在接收某个总线命令时必须进行复位,则必须有一个单元测试发送该命令并检查设备是否被重置.我们现在正在这里使用NUnit作为单元测试框架,以及一些可以发送和接收命令(甚至按下按钮)的自定义软件和硬件.这很棒,因为唯一的选择就是手动完成所有操作.
客户绝对想知道哪些测试,他甚至想自己运行测试.如果测试没有正确记录,他不知道测试做什么和不能检查,如果他认为他需要所有的测试都在那里,并运行测试的时候,他不知道它会做.因为他无法读取代码.他比我们的开发人员更了解使用过的总线系统,但他们无法读取代码.如果测试失败,他不知道为什么甚至不能说他认为测试应该做什么.这不是一件好事.
我们已经正确记录了单元测试
正确地说,在这种情况下意味着:写出非开发人员可以理解的清晰语言.你可以保持技术,但不要只写你能理解的东西.对于任何其他评论和任何代码,后者当然也很重要.
独立于我们的确切情况,我认为这是我在单元测试中一直想要的,即使它们是纯软件.客户可以忽略他不关心的单元测试,例如基本功能测试.但只是拥有那里的文档永远不会受到伤害.
正如我在评论中写到的另一个答案:此外,如果您(或您的老板,同事或测试部门)想要检查哪些测试以及哪些测试,生成的文档也是一个很好的起点他们这样做,因为你可以浏览它而不需要挖掘代码.