0

我们有 12 个遗留项目。一个是 9 年前编程的旧 Visual Basic 应用程序，另一个是 C# (.NET) 应用程序、2 个 java 项目和 os on。

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

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

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

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

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

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

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

4

3 回答 3

1

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

关于其他类型的测试，您可能需要考虑集成测试。This answer to another SO question解释了集成测试的用途及其与单元测试相比的价值。

于 2016-03-16T22:07:50.260 回答
1

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

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

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

顺便说一句：请重新考虑“为这些项目编写单元测试太耗时”的说法。是的，这可能很耗时，但根本不编写测试也会很耗时，因为您可能会一直在不知不觉中破坏功能，并发现自己需要解决很多问题。

于 2016-04-03T20:04:11.717 回答
0

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

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

设置存储库和管道仍然是一个好主意。存储库允许您快速回滚有缺陷的更改。管道使您能够自动化运行大量测试，您需要在代码之上进行测试。

您不需要任何其他工具或更多插件。您的编程语言很可能已经拥有您需要的一切。你需要的是专业知识、信念和耐心。以下是对我们团队有效的方法：

获取 Michael Feather 的《使用遗留代码有效工作》。它为您提供了开始修改遗留代码所需的技术，而不必担心破坏它。您认为不可能为您的遗留代码编写单元测试吗？你错了。羽毛告诉你怎么做。这是诀窍部分。

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

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

每周，获得一个完全处于测试状态的资源（类、方法、函数），即语句和分支覆盖率为 100%。100% 覆盖率的 1 个资源比 10% 覆盖率的 10 个资源更好。

原因如下：您现在可以重构该资源。阅读 Robert C. Martin 的Clean Code，了解如何让代码变得更好。然后召集一些团队成员一起进行重构会议：

做一个微小的改进（重命名一个变量，删除一个注释，提取一个子方法），然后证明所有的测试仍然是绿色的，然后把键盘传给房间里的下一个人。在整个会话中一遍又一遍地重复此操作。不要忘记在这些课程中添加糖果、薯条、可乐或啤酒——让它成为一个有趣的活动。

使用会话来了解代码、它的作用以及原因；这将使房间里的所有人都能够支持他们本来不会触及的代码。

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

于 2017-05-18T21:29:04.583 回答