unit-testing - 计数断言

Question

我最近收到管理层的请求，要求我为我们的软件创建测试运行断言数量的报告。他们想要这个，这样他们就可以判断人们是否在编写测试。我倾向于直接告诉他们“不，你不能拥有它，因为你不需要它”，但这似乎并不能满足他们。

部分问题是我们的团队正在编写带有大量断言的长测试用例，他们想说他们已经测试了一些新功能，因为他们已经向现有测试用例添加了更多断言。

所以我的问题是:有没有人有一些好的、权威的(尽可能多的)资源或文章或书籍，甚至描述了应该如何将测试分成测试用例或为什么计算断言是不好的？

我的意思是计算每个测试的断言或断言作为衡量人们是否正确的测试与计算每个测试的代码行数一样有用。但他们就是不买账。我尝试使用 Google 进行搜索，但问题是没有人费心去计算断言，所以我真的不能说“这就是为什么这是个坏主意”。

Answer 1

在软件管理中做出愚蠢决定的想象力真的没有限制，算上断言？？...测试的问题通常是质量问题而不是数量问题。

如果您想要一个受人尊敬的引用，Gerard Meszaros xUnits 模式可能是最受人尊敬的人之一，建议之一是“每次测试验证一个条件”(http://books.google.es/books?id=-izOiCEIABQC&lpg=PT111&ots=YIeYejY-mx&dq=meszaros%20one%20assertion%20per%20test&hl=es&pg=PT110#v=onepage&q=condition&f=false)

但是...如果问题出在人们添加“新测试场景”以“更多断言”扩展现有测试而不是编写新测试，那么贵公司最好的办法就是购买大量的 meszaros 书(和肯特·贝克以 TDD 为例，并在测试指导下发展面向对象)并聘请一些专家在它迟到之前提供培训和指导。