单元测试的一般思路

Question

这个问题可能有点模糊，但是这里有。我刚开始进行单元测试，似乎正在为基本概念挣扎。

我正在测试一个函数，检查数据库中是否存在记录。如果不是，则添加新记录并返回其ID。所以这个函数写起来很简单。我认为测试它的唯一方法是通过使用模拟框架来检查正确的属性/方法被称为正确的次数。

我正在努力的部分是我所读过的所有内容都是关于先编写测试然后再编写函数的。但是我觉得如果我先写函数，然后编写反映函数内部运作的测试，它才会起作用。

这真的有一个金科玉律吗？

无论如何我应该测试基本事务逻辑多少？

Answer 1

也许如果你想在这个水平上发展，你可以先写方法合同，然后再根据合同写测试。 您的方法的行为与合同中定义的行为很重要，因为这是其他开发人员所期望的。 尤其应该测试边缘情况（例外等）。

如果您打算在开发该方法的同时更改合同，那么这并不好。因为你没有计划好你的软件，所以你可以重写你的测试=）

测试很重要，因为当你做代码修改时，你以后可以用保存的测试更容易地检测错误，当你通过尝试开发新的东西来捣碎某些东西。

Answer 2

据我所知，我会说你应该时刻记住你将如何测试函数，但是首先要编写函数本身。这将允许您找到可能发生的关键部分和最终的错误。 您还可以测试您的功能的输出/输入，并确保它们符合所需的结果 - 黑盒测试适用于此预编码单元测试。

在编写实际的方法之前，我也一直在努力写这个单元测试的想法。请记住，我只是一名学生，这只是我的看法。

希望它能帮助，希望我是对的:)

Answer 3

我与挣扎的部分是，无论我曾经读到，然后再编写测试函数会谈。但是我觉得只有我先写函数然后编写反映函数内部工作的测试才能工作。

听起来好像你患了test-driven development（TDD）常见的鸡/蛋问题。除非您在编写代码之前编写测试，否则在知道代码之前您不知道要测试什么，并且您认为不能执行TDD。

这真的是一个设计师的块（tm）的情况。就像作者的封锁一样，通过编码完成这项工作通常是很好的 - 即使你把所有的代码都扔掉了。

破解原型，然后假装它不存在。（不要运送:)这个原型应该探索你不熟悉的概念，或者没有足够的信息来开始设计。它应该让你熟悉这个问题，以便你可以开始设计。

当你有了一个概念验证，代码审查了它。在你的评论中，确定你想让公共接口看起来像什么，哪些架构模式最适合该程序，哪些依赖应该彼此隔离（并在测试中被嘲笑）。做笔记，或在项目计划软件/项目跟踪软件中的工作项目中提交需求。

如果您在评论中发现了这些问题，您应该尝试招聘其他程序员（以及可能设计人员/识别您业务需求的人员）来帮助您完成此项任务。代码导师可能是个好主意。

从该评论，你应该能够开始编码你的测试。或者你可以开始写技术规范 - 这个建议同样适用于两者。

（如果你工作在一个团队中，收集需求和获取用户反馈/执行UATs还要求，但可能是别人的工作）

编辑

请记住，这只是解决这个问题的一种方法。另一种方法是简单地放松任何TDD应该如何工作的清教徒般的理想，并简单地开发与代码并行的测试。同时检查它们。

在没有TDD的情况下进行单元测试也很好。单元测试赋予更多的好处，而不仅仅是编码你的设计和需求。当您添加新功能或修复错误（回归测试）或移植代码时，它们也是巨大的帮助。

Answer 4

不管怎样，我应该测试基本事务逻辑多少？

这是我的经验，你写的测试越多，你就会越开心。

测试基本的事务逻辑将为您提供关于您的类以及它们如何互操作的经验，并让您了解它们的速度以及基本事务逻辑的真实工作方式。

这会帮助你在编写测试用例方面变得更好，因为练习是完美的。

稍后，谁知道，它将帮助您在升级数据库或完全更改数据库时检测到错误。

Answer 5

有对先写测试很好的理由：

1. 你确保你的实际测试失败。如果你先写实现，然后再测试，测试会通过，但是你不知道它是否真的有效。测试中可能有错误！如果你先写测试，你可以运行它，并确保它失败。
2. 如果您只编写通过测试所需的代码，您将获得非常高的代码覆盖率。
3. 如果您首先编写测试，包括所有需要的嘲笑和假冒，您可以更好地理解需求。当嘲笑某个API时，您可能会发现有一些额外的信息需要您进行API调用或类似的事情。
4. 动机。如果你的代码已经写好了，那就太简单了，只需要去Naaah，我不需要测试全部吧。错误。如果你反过来，这仍然是可能的，但它的抑制阈值更高。

总的来说，它可以感觉很难，但奖励是值得的。

Answer 6

我会特别试着回答你关于测试基本事务逻辑的问题。大多数情况下，我为层次结构中的较高单位编写单元测试。例如，在基本模型 - 视图 - 控制器设置中，我的单元测试正在测试控制器，而不是基础DAL。为什么？因为我假定，当一个控制器通过测试时，控制器下面的层也可以正常工作。

虽然对共享库有一个例外。许多项目共享的库将获得他们自己的单元测试，例如，以确保API的稳定性。

另外，看看你的单元测试作为项目中的另一个应用程序。确保你在测试中不使用c/p代码，不要把一堆测试装置放在一起，而是花时间设计一个可扩展的好结构。它会为您节省很多时间。