单元测试建议

时间:2014-09-30 02:56:52

标签: unit-testing tdd

我有一个中等到高度复杂的应用程序,由大约50-60个表的大型数据库支持。我试图在代码上获得尽可能多的单元测试覆盖率,但我真的在嘲笑数据集和一些关键概念。我实际上对尝试实施完整的单元测试覆盖率感到焦虑,因为我不确定如何执行以下操作:

1)测试每个功能的每个可能的场景和数据组合。 I.E.我们的一个函数返回一个基于大约20个输入的值,每个输入有3个不同的可能值。怎么可能测试这样的所有值?如果我可以测试所有这些组合,我将不得不在测试中编写完全相同的逻辑代码以确定它是否应该通过(这不是多余的吗?)。

2)数据和结果随时间而变化!例如,如果我对上周租用汽车的员工数量进行查询,那么随着时间的推移,我将始终返回不同的结果。我怎样才能编写一个单元测试,知道如果结果从一天到下一天变化会有多少结果?

人们说如果你正在努力进行单元测试,那你就错了,那么请告诉我如何最好地处理这些情况。

1 个答案:

答案 0 :(得分:1)

尽管如此,我的评论仍有一些想法:

  • 在单元测试中,您测试"单位"。单元测试中的很大一部分技巧是确定一个"单位"是。那么你的单位是什么?提示:他们几乎从不涉及数据库。
  • 确定正确的单位可以防止结果和数据变化的问题。如果核心位功能发生变化,那么单元测试需要修改甚至删除,否则应该进行最小程度的维护。
  • 组合和排列 - 测试您实际需要测试的内容。你可以为此编写一些帮助代码。但是,你并不总是需要来测试绝对的一切,测试到有用的点而不是更进一步。
  • 我发现高水平的测试很有用,但你可能没有。您在单元测试中的经验和能力会影响测试的有效性。