首先，我们的明确目标是发现错误并提高软件质量。因此，测试不仅限于unit test。
我曾经在美国航空航天公司进行软件测试。一种测试是单元测试。它的一些规则是：
所有测试均应遵循要求文件和设计文件，而不是代码。
SUT（被测软件）仅限于基本单元，例如一个或多个功能/程序。当然，SUT可能会调用其他函数/程序，但后者并不专注于此测试 - 它们有自己的测试，所以它们可以被删除。
仅调用SUT。该测试不需要设置整个系统。
根据要求/指定文件的要求验证并验证SUT的结果。例如，计算一些数据，一些程序被称为......
现在，我是一名不同公司的程序员。我们没有要求/指定文件。该软件仅通过测试部门的功能测试（黑匣子）进行测试。程序员以前从不进行单元测试。执行单元测试的任务分配给我。这是我做的：
分析代码并尝试理解它;
为要测试的单元（功能）写一份简要文件;
如上所述测试SUT;
因此，对于将消息发送到另一个进程的函数。我将其描述为：
为消息分配一些内存
填充邮件标题;
致电基础设施以传递信息。
我验证和验证的内容（正如我所写的简短描述）：
它调用了一些内存分配API，例如malloc（），并分配了所需的内存量;
邮件标题在发送之前已正确填充;
它调用了确切的底层API来传递消息。
在我看来，如果软件完全按照指定文件进行，那么测试应该通过。 如果事实证明行为不正确，则应归咎于设计，而不是测试方法本身。
单元测试可确保每个unit软件都能正常运行。这些单元是否能够正确地协同工作，是一些更高级别测试的工作，例如集成测试或系统测试。
然而有些人认为我必须启动另一个进程，创建一个接收器，接收此消息，并检查其内容。只有这样我才能确保发送消息的过程行为正确
我认为这超出了UNIT testing的范围。它可以被称为integration testing？
我不擅长辩论。我不能说服他们。我不想争辩。
任何人都可以帮助找出执行单元测试的正确方法/原则 - 或者正如我在开始时所说的任何其他类型的测试，我们的明确目标是提高软件质量。