【问题标题】:Best practive for finding unit-tests? (if not developing test-first) [closed]查找单元测试的最佳实践? (如果不是先开发测试)[关闭]
【发布时间】:2013-09-19 11:27:26
【问题描述】:

在某些时候,您必须决定要使用单元测试覆盖程序的哪些部分。

如果您正在开发测试优先,那么您就可以摆脱困境,因为您已经有了测试用例。恭喜。如果您不那么幸运(我们的项目就是这种情况),您必须决定要为程序的哪些部分编写单元测试。

是否有一个好的和有条不紊的方法来决定单元测试涵盖的内容?尤其是比问自己what should I test here? 更具体的问题?

【问题讨论】:

  • 你把一切都搞砸了。单元测试是单独测试值得测试的最小位。并测试所有执行路径/不同的行为/重要的极端情况。
  • 我并不是指所有这些都需要一个单元测试。对于每一个值得测试的部分,绝对是一个单独的单元测试。
  • 我明白你不想要一个测试,但仍然:你的问题听起来更像integration testing而不是unit testing...集成测试是当你测试大于代码的“最小可测试单元”部分。
  • 不,我不是这个意思。我想测试构成应用程序的小部分。例如如果其中一个类中的公共方法正常工作。关于如何改写问题以使其清楚的任何想法?
  • 我认为这是质量保证的主题,sqa.stackexchange.com

标签: java unit-testing junit testing-strategies


【解决方案1】:

恕我直言:

  1. 原始规范中的所有内容。
  2. 一切都依赖于永远工作。
  3. 您发现所有问题都已损坏且必须修复。

我敢肯定不是很有帮助 - 但很现实。

单元测试应该涵盖您有时间的所有内容,然后涵盖您上次处理它们时没有时间测试的所有内容。

可以使用什么方法来找到值得测试的工作块?

有很多:

  • 每当您发现错误时,请修复它并创建一个测试,以确保它永远不会返回。

【讨论】:

  • 第 3 点对于扩展现有的单元测试来说无疑是件好事。获得一组初始单元测试点 1 听起来不错。谢谢 :-)。 (第 2 点肯定不错,但可能很难解决)
  • @kdzia - 第 2 点旨在包括共享库/实用程序类等内容。
  • 好的,这样更容易识别 ;-)
猜你喜欢
  • 1970-01-01
  • 2015-03-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-02-20
相关资源
最近更新 更多