摘要：开发员有着太多的任务导致单元测试往往半途而废。一种解决办法是训练测试人员来处理它们。测试人员应在开发周期中尽早的介入，既可以提高他们的编程技巧，bug也能够尽早的被发现并修复，缩短功能测试阶段时间。所以（测试员）应考虑在单元测试中起积极作用。
在软件开发项目，在编码阶段尽可能早地启动测试过程是有利的，因为bug能快速的被发现并修复，代价很小。根据公司和项目，当然，测试人员应审查和验收功能文档，文档验收后，测试人员将继续设计测试并准备功能测试阶段的用例或脚本，直到软件“准备好了”。
然而，在我的经历中常常是，单元测试被认为是开发团队的责任，令人遗憾的是，由于许多原因，单元测试往往没能落地。主要的原因是开发员认为没有足够的时间去设计和执行单元测试。
我明白，开发团队在巨大的时间限制下编码并快速转到下个功能，因此，在文档中约定的功能往往不能完全实现。很少的文档或者甚至没有文档变更就流转给测试团队。基于此，测试人员在时间压力下去更改和执行他们的测试以便检查系统现在的运行情况。
作为一个测试管理者，我曾寻问是否有办法解决在开发后期阶段出现的这些问题。
对于我的团队来说，一个很好的解决方案是，测试人员在后期的编码阶段扮演积极的角色，如果可能的话甚至更早，负责单元测试。整个单元测试工作是否被测试团队或测试人员接管，仅取决于项目的开发阶段。而当测试人员负责设计和执行单元测试时，我看到了积极的结果。
测试人员参与单元测试的另一个优点是，通过观察代码和创建单元测试断言和验证，测试人员了解了代码的流程和功能，在后面的测试设计中能使用到这些知识。测试团队可能并且应该参与到代码审查中，而且创建和执行单元和集成测试能使测试人员在开发过程中尽早的与代码交互。通过这样做，额外测试可以找到编写代码的开发人员无法预期的问题。
创建和执行单元测试的测试员这样做不存在开发员的心态，那就是，希望表明代码是工作的，测试能通过。而设计多个测试并发现错误才应为主要目的。此外，通过分派给测试团队做单元和集成测试，开发人员将释放以继续开发其它功能，缩短开发阶段的时间。
单元测试过程流线化
当我看到测试的未来，我认为由于DevOps、敏捷崛起，以及持续集成，测试人员具备很好的编码或测试脚本能力（具体编程语言取决于测试员）是必要的。
软件测试员的角色变得更具综合型。我们不能只读需求，创建和执行用例，编写bug报告。为了在日益迅速的软件测试世界中茁壮成长，我们需要能够理解和编写代码。一个伟大的开始就是学习设计单元测试用例。
我曾经做过一个测试大型电信公司网站的项目。我们的进度落后，但幸运的是，我们有一个开明的开发经理，毫无保留的授予代码访问权给一小组技术头脑，Java人员，以及当时工作的测试人员。
与其让项目外的开发人员不知道任何项目代码去创建单元测试，我认为测试人员负责单元测试会更好一些。在我看来，同样的原因，代码审查应由编码以外的其他人完成，开发人员需要让一个独立的伙伴来测试他们的软件，无论是功能或单元测试。我们实验性的测试驱动单元测试项目最终被允许进行。
我们的开发团队使用单元测试框架JUnit，利用java来帮助测试驱动开发。我们想通过开发人员的一些指导，能创建自己的测试驱动的单元测试实践。
除了让测试人员审查代码和新功能的技术说明书，开发员和测试员应坐在一起详细的浏览代码，说明哪些地方需要用到JUnit做单元测试。后面这些单元将隔离测试直到稳定，然后创建和执行更大的集成测试，以看如何将独立的功能单元整合为一个整体。
由于JUnit测试的工作仍在继续，我们开始看到一个不同的风格的测试驱动单元测试的出现。与开发人员创建的单元测试相反，设定一系列的断言以确认预期的结果，我们的测试员尽可能用JUnit做包括边界值分析和等价类划分测试。集成测试阶段提供了更多的机会来运行这些类型的测试，这样导致bug能轻松和快速的被发现并修复。
加强合作
测试驱动的单元测试也有其他好处。测试人员几乎是在代码被写入就知道发生了什么。开发团队可以释放到其他功能的编码上，通过直接看测试人员的代码他们也能很容易地说明新的功能，而不必修订文件，以及需要需要额外的阅读和验收。功能测试阶段也将缩短，因为大量的bug在更早时就被发现并修复了。
参与单元和集成测试给测试人员很大的动力，以进一步提高他们的开发技能。开发人员和测试人员之间的互动比以往版本时更多，这种合作导致更多的知识增益于测试人员的功能代码。从这个项目中，我看到了测试驱动单元和集成测试如何帮助打破开发人员和测试人员之间的障碍，使测试人员作为开发过程中更多的部分，并增强了团队之间的协作。
本文由51ste软件部落 ruink 译自Anastasios Daskalopoulos的《Tester-Driven Unit Testing: Taking an Active Role》一文。