问有没有像单元测试计划这样的东西？

EN

单元测试应该是自我解释的。

它们被程序员用来确保他们的代码是正确的，并且不影响现有的代码。

如果有必要，任何程序员都应该可以自由地添加新的测试，因此维护一个文档来定义单元测试的计划是一种非常奇怪的方法。

在我看来，应该使用测试计划来定义验收测试或集成测试，而不是单元测试。

注意，单元测试在编程阶段和编程阶段是有用的，不可能确切地知道将编写哪些测试。因此，可以想象，当不需要计划时，只有在工作结束时才会编写单元测试计划。

在某种程度上，你的问题听起来更像是一个讨论的邀请，但无论如何：

至少在更严格的意义上，单元测试在很大程度上是“开发人员业务”。作为开发人员，您可以创建在编译时运行的“白盒”测试，以便从运行中的代码中创建反馈。

当然，一些项目经理现在可以想出这样的想法:他/她需要你准确地“计划”你的单元测试活动。

在我看来，这违反了敏捷所代表的任何东西。您可以看到:在敏捷中，人们会想到给客户带来价值的特性。您，开发人员，您将创建实现特性的类，但是所有这些“实现细节”对您来说都很重要。您的项目经理不应该关心您的设计是什么样子，以及它包含了多少类。因此，他真的不应该要求您在单元测试中预先制定一个计划。见鬼:您在敏捷的基础上创建了类(以及它们的测试)；但是您应该知道前端您将开发什么？！

长话短说: PM应该担心规划那些“客户特性”；因此，当您的PM询问在该范围内的集成或系统测试计划时，这是公平的；但是，您最好质疑他关于 his 监督您的单元测试的想法！

最近，一位新经理问我，我们最新版本的软件有什么测试计划和测试报告。我的答覆是：

• 我们使用测试驱动开发来开发我们的程序。这就是我们的测试计划。
• 我们从不发布任何自动化测试失败的版本，所以发布它意味着它已经通过了100%的自动化测试。这就是我们的测试报告。

经理似乎很满意。