unit-testing - 单元测试的总体思路

Question

这个问题可能有点含糊不清，但是可以解决。我刚刚开始进行单元测试，而且似乎在基本概念上苦苦挣扎。

我正在测试一个检查数据库中是否存在记录的函数。如果不是，它将添加新记录并返回其ID。因此该函数易于编写。我认为可以进行测试的唯一方法是使用模拟框架来检查正确的属性/方法是否被调用了正确的次数。

我苦苦挣扎的部分是，我读过的所有东西都在谈论先编写测试然后再编写函数。但是我觉得只有先编写函数，然后编写反射(reflect)函数内部功能的测试，它才会起作用。

真的有一个黄金法则吗？

无论如何，我应该测试多少基本的交易逻辑？

Answer 1

如果您想在此级别进行开发，则可以先编写方法的契约(Contract)，然后再根据契约(Contract)编写测试。
您的方法的行为必须像契约(Contract)中定义的一样重要，因为这是其他开发人员所期望的。
特别是边缘情况(异常(exception)等)应进行测试。

如果您要在开发方法时更改契约(Contract)，那不是很好。因为比起您还没有计划好的软件，您还可以重写测试=)

测试很重要，因为当您进行代码更改时，以后您可以通过尝试开发新的东西来将某些内容混搭起来，从而更轻松地使用保存的测试来检测错误。