如果没有看到自己的问题出现问题，可以尝试配对编程，代码审查或其他方式来看待更多的眼睛的东西。仍然我坚信，单元测试是程序员的工具，而不是其他任何人做的。
进行其他类型的测试，例如集成测试，功能测试甚至(系统)性能测试，让其他人都可以做到这一点。特别是如果你想自动化这个测试，它需要知道如何做的事情，也可能是更高水平的商业知识测试和如何。
您的问题的答案也取决于文化和组织的工作方式，但是，我相信您在所有情况下都希望进行单元测试，作为开发代码的一部分。如果这导致问题，可能还有其他的东西在组织中被破坏或需要被看待的东西。
更新
以下是我在组织中看到的一些影响单元测试实践的事情：
有些人可能不想写单元测试;
>有些人可能不知道如何编写好的单元测试，这可能会破坏这样做的好处，可能被用作单元测试不好的“证明”
>组织可能不会让人们一起工作，而是有明确的责任，如编码代码，测试人员测试等，这可能会对某人进行单元测试;
>有些人可能会被雇用来编写单元测试，所以如果这个角色没有改变，那么你编写的单元测试就会矛盾;
>可能是一个非常小的组织，这可能意味着每个人都会做一些事情;
>整个组织不承认单元测试的好处，而是承认代码尽可能快的问题 – 后来，
谁正在努力进行单元测试？是一个人吗开发者？管理？
>组织是否可以自由决定谁进行单元测试？
如果有协议进行单元测试，上述事情可能是处理问题，以使组织成为一个自然而然的工作。如果您拥有良好的单元测试实践和经验的人员，请让他们领先，让团队的其余成员看到单元测试的魔力。
就个人而言，我相信如果人们看到单元测试的好处，可以编写好的单元测试，使它们自动化，并且如果团队能够自己决定如何组织如何获取单元测试写入，那么这些测试都会自然而然的开发人员在开发代码时编写单元测试，任何人都可以随时添加更多单元测试，以查看所有代码。如果有测试人员，他们将专注于其他类型的测试，如功能测试或探索性测试。
