在这些经济时期，作为一个整体开始进行单元测试

Question

我们有一些开发人员和一些业务分析师。我们作为开发人员希望开始添加单元测试作为我们编码实践的一部分，以便我们可以提供可维护和可扩展的代码，特别是因为我们也将成为支持和增强应用程序的代码。但在经济不景气的情况下，我们正在努力开始，因为我们面临的挑战是尽快提供解决方案，质量不是首要任务。我们可以做什么或说什么来表明我们将能够更快地提供更高质量的产品，以及为未来的改进做好准备。

基本上我们只需要克服将单元测试纳入日常工作的学习曲线，但我们现在不能这样做，因为它被视为一种不必要的开销，会延迟我们现在业务所需的项目。

我们作为开发人员希望为业务提供最高价值，特别是快速，但我们知道我们还需要在6个月后完成这项工作，我们也需要为此做好计划，我们相信单元测试将帮助我们大大降低这条线。

修改 所有精彩的输入，谢谢。我个人知道如何编写单元测试，但我没有经验告诉我单元测试是否良好。我刚刚订购了Test Driven Development: By Example，并将主动在我们小组中进行单元测试。

Answer 1

无论是否经过许可，您都需要开始这样做。最终，它将提高您的工作效率并提高您的代码质量。你可以通过包含关键事物的单位来从小处着手，一旦你展示了好处，你就可以了。

Answer 2

我想推荐这本书 Pragmatic Software Testing

本书Pragmatic Unit Testing也是一本好书，虽然它更侧重于C＃和NUnit，但有些主题适用于语言独立

Answer 3

就这样做......

如果这是任何新代码的个人流程的一部分，那么至少应该涵盖这一点。您可能永远不会获得添加单元测试以覆盖所有代码的权限，但您至少可以确保未来的更改不会撤消给定时间点的工作。

从业务方面考虑一下，为什么需要编写代码来证明您已经编写的代码是正确的？为什么这是错的？

获得100％的覆盖率会很好但是要花时间去那里并且不要为现在没有错误的代码编写测试;在测试中断时编写测试，以便至少永远不会无意中撤消。

Answer 4

在创建函数或类时开始单元测试它们。从没有外部依赖关系的简单类/函数开始（DB，文件系统）。

在团队内分享您的进度。计算测试次数并显示一个大图表显示您的进度（除非管理/分析师对单元测试非常不利）。

了解TDD：“Test-Driven Development : by example”。首先编写测试会导致代码易于测试。如果您首先编写生产代码，则可能很难将其置于测试之下。

Answer 5

您甚至不需要与管理层讨论（尽管您描述的情况远非理想情况）。这就像Design by Contract - 我在之前的代码中介绍了它，就像开发过程的一部分一样。一旦它进入，并且它起作用，相信我，没有人敢于删除它。

单元测试也可以看作是开发的部分。因此，如果您有20天的时间来开发功能A，B和C，通常可以在您的开发估算中包含单元测试。

进行单元测试非常简单。与多线程问题或任何类型的复杂设计相比，任何有能力的开发人员都可以轻松掌握单元测试。

你可以在半天内阅读有关它的好文献（你有几十个在线教程），并在下午开始进行第一次测试。

真的 - 就这么做！

Answer 6

我知道这可能不是您可以随时使用的，但我相信让您的团队中测试感染的人向您展示方式是在引入测试时保持工作效率的最简单方法。您的员工显然需要了解他们通过阅读书籍或参加用户组可以做的概念。受测试感染的开发人员可以向您展示如何在日常工作中实现这一目标，同时尽可能减少生产力。如果你的速度立刻增加，我不会感到惊讶，但我不会做出那种声称。凭借测试经验，我还可以获得可测试设计的知识，我认为这是关键。