在我们刚开始使用持续集成和交付的遗留项目中使用哪种测试

Question

我们有12个遗留项目。一个是9年前编写的旧的Visual Basic应用程序，其他是C＃（.NET）应用程序，2个java项目和os on。

我们刚刚为每个项目完成清理并创建了一个存储库（其中一些只是位于不同计算机上的文件夹......）。

我们已经为Jenkins配置了许多有用的插件，买了两本书：持续集成和持续交付，尚未完全阅读。

我们为项目定义了一个部署管道。在提交到存储库并自动完成代码分析（圈复杂度等）之后，所有这些都会自动编译。

但是，我们想知道是否有可以用于我们项目的测试（易于添加）。我们知道单元测试，然而，为这些项目编写单元测试会耗费太多时间（如果可能的话）。

我们可以添加其他类型的测试或者我们可以添加到管道中的其他有用的东西吗？

对于某些程序，我们会自动生成安装程序。

此外，在管道的最后，我们有一个手动步骤，将二进制文件（安装程序）移动到我们的apache服务器上的公共文件夹，公司中的人员可以轻松获取最后一个稳定的二进制文件（这里稳定的是我们的应用程序）手动安装和测试（探究性测试我认为它被称为），如果我们没有看到任何错误，我们会将其作为稳定版本推广。）

Answer 1

我认为你最好为你添加的新代码编写单元测试，而不是为现在的所有内容编写单元测试。您可以假设在当前状态下，一切都按预期工作;然后，当您找到并修复错误，或添加新功能，或者几乎对代码库进行任何更改时 - 为该新代码编写单元测试。

关于其他类型的测试，您可能需要考虑集成测试。另一个SO问题的This answer解释了与单元测试相比，集成测试的用途和价值。

Answer 2

我通常会应用三个级别的测试：

1. 单元测试 - 低级测试，用于验证小型独立代码单元的正确行为。这些测试通常是低级的，直接调用其他代码/ api，快速运行（在构建期间），并且在进行大量重构时也可以相对快速地中断。
2. 集成测试 - 中级测试，用于验证多个代码单元的正确行为。例如，后端提供给外部系统或前端的API。这些测试通常不是太低级别，在代码级别（例如，http请求）之上运行，运行速度比单元测试（仍然在构建时间期间）快，但由于它们针对系统边界进行测试，因此破解速度较慢（例如，REST端点。
3. 端到端测试 - 测试整个系统的高级测试。对于Web应用程序，通常使用浏览器测试（例如，使用Selenium），其中浏览器由测试控制，连接到正在运行的系统实例。这些测试非常高级（它们模拟用户行为），运行缓慢而不是在构建期间（因为系统需要先部署）。

在你的情况下，我将结合这些类型的测试。首先使用集成测试和/或端到端测试制作自动回归测试套件。这些类型的测试可以在不太费力的情况下击中系统的相对较大的部分。 添加/更改功能时，首先编写一个或多个单元测试，以验证系统的当前状态。然后添加/更改验证系统所需/新状态的测试用例并相应地更改系统。

顺便说一句：请重新考虑“为这些项目编写单元测试过于耗时”的说法。是的，这可能是耗时的，但是完全没有编写测试也会非常费时，因为你可能在不知情的情况下一直打破功能，并发现自己需要修复很多问题。

Answer 3

嗯，也许一年之后可能有点晚了......但无论如何，对于路过这里的人来说。

持续交付是敏捷技术的优质联盟。使用大量遗留代码，您可能不会在相当长的一段时间内变得“连续”。了解这些想法，但如果你还没有达到它们，请不要感到沮丧。

设置存储库和管道仍然是个好主意。存储库允许您快速回滚有缺陷的更改。通过管道，您可以自动运行代码之上所需的大量测试。

您不需要任何其他工具或更多插件。您的编程语言很可能已经拥有您需要的一切。你需要的是技术诀窍，信念和耐心。这对我们的团队有用：

让Michael Feather的有效地使用旧版代码。它为您提供了开始修改遗留代码所需的技术，而不必担心破坏遗留代码。您认为为遗留代码编写单元测试是不可能的吗？你错了。 Feathers告诉你如何做到这一点。这是技术诀窍部分。

此外，了解特征测试是什么以及它们如何工作。你失去了员工，从而失去了专业知识这个代码似乎没有人知道或记住它的作用？表征测试可以帮助您探测它并使您能够重构它。

不要启动一个巨大的项目来“让代码再次变得更好”。编写代码需要一段时间，修复它需要一段时间。逐个测试您的代码。无论何时开发新功能，都要编写该功能的测试以及它立即连接的旧代码。修复错误时，首先围绕要修复的代码编写单元测试。这将增加您的代码覆盖率，同时仍然让您完成实际工作。这是耐心的一部分。

每周都会获得完全受测试的单一资源（类，方法，函数），即语句和分支覆盖率为100％。最好在100％覆盖率下拥有1个资源，而不是10％覆盖率的10个资源。

原因如下：您现在可以重构该资源。阅读Robert C. Martin的清洁代码，了解如何更好地创建代码。然后让一些团队成员在一起并进行重构会议：

做一个微小的改进（重命名变量，删除注释，提取子方法），然后证明所有测试仍然是绿色，然后将键盘传递给房间中的下一个人。在整个会话期间反复重复此操作。不要忘记在这些会议中添加糖果，薯条，可乐或啤酒 - 这是一个有趣的活动。

使用会话了解代码，代码和原因;这将使房间里的所有人都能够支持他们不会触及的代码。

它还让人们了解他们为所有单元测试编写的内容：重构代码。没有他们可能会认为那些单元测试只是一些无用的负担。毕竟，它有时是遗留的开发人员，而不是需要首先处理的遗留代码。这是信念的一部分。