【发布时间】:2017-01-31 22:14:19
【问题描述】:
我有一个喜欢编写代码的业余项目,我会尽可能地花时间在它上面,因为我还在完成我的大学学业。当我开始它时,我几乎不知道良好的编程实践和 TDD 等等,我只是为了好玩而编码。
之后的几次迭代、重构、改进和积累的知识让我能够在实现新功能之前编写单元测试和集成测试。 但是,我仍然没有足够的时间来真正进行所有测试以获得可接受的代码覆盖率......尽管软件运行良好良好。
所以当我有时间花在这个项目上时,我想实现新功能(这次是的,并行进行单元测试)而不是进行 很多 不得不说的测试很无聊,而且很多都因为嘲讽之类的东西很难做到……
我应该继续添加功能还是应该先完成所有测试?
我由此确定该软件应该是beta 版本,直到达到合理 代码覆盖率。目前版本为0.9-beta。
如果我添加新功能,我是否应该遵循保留 beta 的语义版本?例如,作为下一次迭代 0.10-beta、0.11-beta 等等,直到测试完成,最终它会转向 非 beta 版本。
如果你想查看我的项目,这里是链接:octaviospain.github.io/Musicott
【问题讨论】:
-
忘记代码覆盖率。高代码覆盖率通常会变成一个目标(而不仅仅是一个低价值指标),当这种情况发生时,测试的质量就会受到影响。程序员开始编写不自然的、复杂的测试用例来运行未发现的代码。相反,专注于编写描述功能的测试。不时运行具有代码覆盖率的测试套件。如果测试清晰并涵盖了预期的功能,那么代码覆盖率会告诉您实际上不需要未覆盖的代码。删除它而不是编写测试来覆盖它。
-
嗯,8% 确实是低代码覆盖率。编写更多测试,但不要使用逐行代码覆盖率作为测试内容的指南。即使在您编写了测试代码之后编写测试也将帮助您更好地理解应用程序流程。
-
@axiac 谢谢你的回答,我希望有更高的代码覆盖率来让项目看起来更好,就像 github 上的很多开源项目一样,使用CI通过绿化、高绿化覆盖率等。我知道转入目标不是测试我的代码的正确方法。
-
别误会,我不反对代码覆盖。只是不要瞄准100%。当您需要实施更改或重构代码时,更高的代码覆盖率也会增加您的信心。理想的情况是在编写代码之前编写测试。但是,这需要很好地理解外部预期的代码行为。无论如何,在实现新功能之前,为现有代码编写更多测试。为现有代码编写测试可帮助您发现小错误以及改进或重组代码的方法。它一直发生在我身上。
标签: unit-testing testing semantic-versioning