我参与了一个C项目，该项目在开发过程中没有进行单元测试。我的上司问我的是修复错误并为涉及修改的部分创建单元测试。这也是我第一次创建测试，因为我也是一个新手，所以他给了我一个描述程序的文件。
他说要检查我修改过的函数中的流控制（比如func（））并给出了一个示例测试用例，如下所示：
func(int a)
{
if(a == 5)
ifblock();
else
elseblock();
}
1。）输入：5，检查流量是否转到ifblock（）
2.）输入：6，检查流量是否会转到elseblock（）
现在，与样本相比，真实函数涉及更复杂的条件检查，但这仅供讨论。
我的问题是我没有看到做这种特殊测试案例的好处（我不反对单元测试澄清。只是这个特定的例子）所以我告诉他我的理由：
1.）这种检查不能证明功能的正确性
2.）如果代码改变了，即使函数的输入和输出仍然相同，我还要创建另一个测试用例
3.）浪费时间，特别是当我有一百个类似的测试用例时
4.）从我读到的，似乎一个函数是所谓的单位所以没有点逐行（我可以看到汇编语言中的点）但
我打算做的是有一组输入，这些输入将以修改/规范为目标，并检查更简单和可重用的输出。
他并没有按照他的指示行事，但无法向我解释这一点的重要性。 因此，如果有人能用这个来启发我，因为我还是一个新手，也许在这一刻也看不到它的价值。
答案 0 :(得分：3)
单元测试是进一步修改代码的安全网。有些代码更容易测试，有些代码更复杂。在你的情况下if / else可以被解释为你手上的系统的behavior的定义，这是它的规范。
您可以编写单元测试（规范），也许它可以帮助您理解这种测试的价值。您似乎只是在重复您尝试测试的代码，但如果您努力实现测试的简单性和完整性，那么以后您可能会抛出实现，并创建一个更新的代码，清洁一个。
正如您打算修改代码一样，这正是您的单元测试所针对的 - 定义之前的内容，并指定新内容和更改内容，以及更改内容。已经存在了。
不可能对你的话语进行概括和一句话的回答，而这一切都取决于太多的事情 - 关于所讨论的软件的期望命运，你愿意变得更善于做什么，关于你正在处理的软件的实际状态等。
有些书可能对你有帮助，你的老板有充分的理由来编写测试：
关于要点：
P.S。
我打算做的是拥有一组针对目标的输入 修改/规范和检查输出哪个更简单 可重复使用的。
这是数据驱动的测试
逐行检查代码的原因可能有一个非常实用的原因。您可能会将该功能视为带输入和输出的简单黑盒子。然后，您可以为数据驱动的测试创建一个表，并运行测试，测量代码覆盖率。你甚至可能会感到惊讶，很多代码根本没有被击中。假设所有代码行最初都有某些原因可能是明智的，否则它们就不会出现在该函数中。试图发现每行代码背后的原因（探索性单元测试）可以为进一步的重构和扩展创建一个更加可靠的安全网，同时增加您对代码的理解。
P.P.S。 尝试编写测试的另一个后果可能是您发现代码模糊，过时且写得不好。在这种情况下，您可能希望将实现全部放在一起，仅依靠规范测试进行完全重写。
答案 1 :(得分：0)
开发后非常需要进行单元测试。开发人员最了解他的代码的预期结果。 您必须根据功能（肯定结果）和代码验证来准备测试用例。
因此，测试用例类别将为：
即使您更改了代码，在这种情况下测试用例也将保持不变。