在过去的某个时候，经过一年的团队实践干净的代码和TDD，我们能够用自动化的单元测试覆盖大约三分之一的代码库。但是在某个时候，我开始徘徊在测试没有覆盖的地方，开始注意到我们经常会破坏一些测试而没有注意到它。尽管我可以看到一系列工具来帮助编写、执行和监控其他技术中的测试，但我并不完全满意我们在ABAP中拥有的东西。

自从ABAPGit问世以来，ABAP中的许多开源解决方案开始在Github中萌芽。现在，欧洲云服务器，在从开源社区获得了这么多东西之后，我决定回馈一些东西，并希望激励更多的团队踏上他们自己的旅程，朝着卓越的现代软件开发需求迈进。

遵循持续交付和DevOps的一些原则，我们会不时提供一些应用程序和界面的监视器，以帮助我们的支持团队积极主动，在问题被报告之前解决问题。

然而，我们自己缺少一些东西，一些东西可以帮助我们更好地培养我们的代码库，找到未经测试的角落，并让我们能够确保我们能够总是绿色的（就像所有通过的测试一样）。而且，我知道每天都有视觉效果的东西会让我们更专注于保持东西的清洁和绿色。

因此，我决定开始在显示器上工作就是为了这个。于是，我们的ABAP单元仪表板，新手建站教程，或ADASH，诞生了：

从ADASH的截图上剪下来的。所有的数据都是假的

有了它，我们就可以浏览我们的代码库，了解哪些更改破坏了什么，以及我们在覆盖率方面的表现。我们也可以根据需要在特定的包（或类）上重新执行测试。通过Cli（见下文），我们可以设置一组包，以便让不同的团队监视不同的域。最后，我们可以看看哪个测试失败了以及失败的原因：

查看类测试

启动监视器所需的一切当然是一个

前提是您已经设置了您的开发系统；）。

可能有一些技术因素仍然阻碍ABAP实现完全的持续集成。但对于连续交付，过去几年中出现了很多问题。ABAPGit和ABAPLint就是这方面的一些例子。但我们缺少的一件事是，将测试集成到内部Gitlab管道中。这个想法来自我们的前端开发，我们有前端测试，低价云服务器，如果通过了，我们会将应用程序部署到后端，但是不管后端测试失败与否，我们都会这样做，因此我们的CLI（命令行界面）应运而生。

测试包！

由于CLI是使用Node Js构建的，因此创建使用它的管道应该相当容易。同样，设置好后，大数据与人工智能，只需

远程执行测试并获得快速反馈，

所有ADT和VS代码插件背后的功劳，您就把我们从SE24中解放出来了。没有它，就不可能有正确的面向对象、干净的代码和测试驱动的开发。在使用Javascript时，有一个特性我非常喜欢。很多测试框架都有能力"观察"我的代码，并在运行时看到我的测试停止或修复。意识到我可以模仿一些与我已经建立的类似的东西，我想…为什么不呢？

在我编写代码的同时观看测试

所有这些都可以通过ADASH Cli免费使用，请记住，这绝不是一个商业工具，也不是一个（在我看来）达到V1.0成熟度的工具。有一些bug需要修复，测试需要实现（讽刺的是），还有一些功能需要添加。我知道显示测试历史和覆盖率的摘要图和vizchart图表正在制作中，除此之外，我还希望让社区参与合作。

这只是一个工具，帮助我们拥有代码的集体所有权，它运行我们编写的测试。无论如何，它不会像ATC那样"自动"或静态地测试事物。

在这十年里，我会看到并羡慕其他语言的生态系统和社区，他们的合作是多么的广泛，花费其他人数千小时的工作来大大提高我们自己的生产力是多么的容易。但是，在过去的5年里，我能够看到我们自己的ABAP社区发展得有多快，以及这一点是如何开始对我们产生影响的。UI5拯救了前端部分，最终所有语言都有优点和缺点。

ABAP正在自我更新，我们使用它的人也是如此。XP编程、测试驱动开发、持续交付、持续集成和DevOps只是描述现代软件开发（及其生命周期）的一些词汇。尽管ABAP在技术上限制了它的全面采用，但我们现在能实现的和20年前能实现的有着巨大的区别，多亏了这条被称为开源的双向道路，很多东西走到了一起。的确，智慧农业物联网系统，使用ABAP的项目和产品通常受到严格的流程和工具的限制……

但是，根据我的经验，TDD的障碍（例如）更多的是个人因素，而不是技术或管理因素。找借口继续做同样的事情是很容易的。放弃多年的功能模块经验，潜心于面向对象、可测试设计和测试驱动开发是需要勇气的。ABAP肯定已经为我们的进步做好了准备。现在我们甚至有ABAP在云端！我希望像这样的项目能激励你做得更好，就像我使用的开源项目激励我做得更好一样？请在下面留言！