开发驱动的测试
#重构 #php #laravel #测试

自全日制遥控器以来,我一直在扮演的第一个角色是单位测试仪的角色。我以前不习惯成为质量检查人员,尽管这对我来说是新的,但我已经掌握了它。但是,作为我角色的一部分,我也必须编写测试(Phpunit)。我团队中的其他开发人员最初并不舒适地写作测试,或者他们只是更专注于发布内容。

事实后的测试很普遍

我确定这不仅仅是我发生。我敢肯定,还有无数其他项目遵循同一过程。开发人员执行该功能,有人执行一些质量检查,然后将任务卡移至单元测试列。对于任何欣赏TDD工作流程的人来说,这都是直截了当的。

这种开发驱动的测试是什么怪异的?这很奇怪,因为您失去了与功能一起编写测试的许多好处。

事实后的测试通常是无效的

对于初学者,假设您发现要测试的功能由于...截止日期而被构建非常严重。如此糟糕的是,为其编写测试是太困难和非生产性,或者唯一的方法是重构整个过程。但是另一个开发人员已经交付了重构代码,您应该再做一次吗?或只是跳过整个测试并释放它,因为截止日期?

假设要测试的代码写得很好,可以使用。通过什么指标?我看到的大多数未经测试的代码都是具有数百行代码和非常高复杂性的控制器,服务和方法。当然,它可能看起来很简单,写得很好,但是PHPmetrics必须说些什么?即使我(测试人员)写了一个没有测试的大型功能,我仍然会制作与其他程序员称为mehhð的相同次优码。

根本不进行测试是通往黑暗面的道路

使用未经测试的代码(过度工程)的另一种方式也是一个问题。很容易从您正在构建的功能中分散注意力,并开始考虑不需要的细节和子功能,并且可能永远不会使用。有时很难只保持专注并仅构建您需要构建的东西。很难知道何时停止重构,但再次发生。

曾经从事过旧版项目吗?为什么所有传统项目都有相同的问题?他们是怎么这样的?我最大的赌注是,他们随着时间的流逝而增长,开始赚钱,每个人都害怕四处乱逛,“做正确的事情”。如果工作正常,为什么要升级和修饰项目?如果只有一种方法可以安全地改进项目...

嘿,但是TDD不花很多时间吗?

与功能一起编写测试时,这是另一个重大的误解。我已经编写了测试的代码,并且已经编写了未经测试的代码,我可以完全充满信心地说,测试的时间没有我预期的时间。在许多情况下,测试环境可以帮助我更快地编写功能。例如,在实现具有各种输入的表单时。我正在一一逐一编写输入,我必须不断地与浏览器进行检查,以确保一切都起作用。否则,我什至不必离开编辑。

哦,这是使用测试时的另一个关键胜利。他们改变了思考问题的方式,或者更确切地说,它们可以帮助您发现与问题打交道的理想道路。这样做的原因是,您被迫考虑用例并按顺序实施它们,这与机器处理指令的方式非常相似。最终,您编写了遵循此顺序思考过程的代码,并稳步地构建了构成整个功能的作品,并猜测什么是非常可以读取和易于掌握的外部观察者或将来的您。

TDD是您做出的决定

我仍然认为在此事实留在这里之后编写测试。做出决定的人不容易被某些软件“理论”说服,对吗?他们想要艰难的事实和结果。但是,对此的决定是您手中的,开发人员。您不会通过征求许可来更改任何内容。

很有趣,即使对自己证明这一点,我也被介绍给一个没有测试的现代Laravel项目,我坚持认为,只有在被允许写测试的情况下,我才会接受这项工作。在几个月的时间里,我们需要进行重大重构并升级到PHP 8.2。我们做到了,测试都是绿色的,我们很高兴去。我们所有人都感到安全,受到保护,并决定每个开发人员编写自己的测试,这是显而易见的。

因此,请尝试一下您的项目。 Yolo,不要告诉任何人。只需为您自己的任务编写一些测试,让它们挂在那里,并在大小上种植几个月,您就会看到及时的好处。您的整个团队都会看到。

TDD在Copilot和Chatgpt时代

随着Chatgpt和Github Copilot的最近兴起,写作测试的经验已达到另一个层次。一旦您手工写东西有点舒服,AI助手就会让您大吃一惊。这些天,Copilot已经在我的许多测试中都产生了很多测试,写复杂的逻辑和断言几分钟。我觉得这些工具是为TDD制作的。

我感谢您的阅读,希望您有一定的时间。我不时写有关重构和测试的文章。在下一篇文章中见。