PHP 中测试驱动开发简介

发布于 2024-07-19 07:13:15 字数 279 浏览 7 评论 0原文

我的工作场所由很多牛仔程序员组成。 他们中的许多人都是初级学生。 这恰好导致了许多代码质量问题。

我正在寻找有关如何最好地让我的团队使用 TDD 的建议(我们可以从单元测试开始,然后进行回归测试,然后进行更多自动化测试)。

最终,我希望我们能够更快地从错误中吸取教训,编写更好的代码并培养更好的开发人员。

我希望有一些关于如何向团队引入 TDD 的实用建议。 具体来说,在 LAMP (php) 堆栈中最好选择哪些工具。

抱歉,如果这个问题过于开放式。

My workplace consists of a lot of cowboy coders. Many of them are junior. Which coincidentally contributes to a lot of code quality issues.

I'm looking for suggestions on how to best wane my team into using TDD (we can start with Unit tests, and move into regression tests, and later more automated testing).

Ultimately, I want us to learn more quickly from our mistakes, and produce better code and breed better developers.

I'm hoping there are some practical suggestions for how to introduce TDD to a team. Specifically, what tools are best to choose in the LAMP (php) stack.

Sorry if this question is too open-ended.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

青朷 2024-07-26 07:13:15

经过四次这个过程后,我发现如果没有一定程度的执行,任何 TDD 的引入都会失败。 程序员不想转换风格,也不会编写他们的第一个单元测试并突然看到曙光。

您可以在管理层上强制执行,但这对于所有相关人员来说都是耗时的。 无论如何,在开始时一定程度的这种操作是必要的,但最终您将需要自动执行。 答案是引入持续集成。

我发现 CI 服务器是任何 TDD 环境的终极基石。 除非开发人员知道如果不编写测试就会发生不好的事情,否则总会有一些牛仔觉得自己低人一等。

After going through this process four times now, I've found that any introduction of TDD will fail without some level of enforcement. Programmers do not want to switch style and will not write their first unit test and suddenly see the light.

You can enforce on a management level, but this is time-consuming for all involved. Some level of this is necessary at the beginning anyway, but ultimately you will need automatic enforcement. The answer to this is to introduce Continuous Integration.

I've found that a CI Server is the ultimate keystone to any TDD environment. Unless developers know that something bad will happen if they don't write the tests, you'll always have cowboys who feel it's beneath them.

看轻我的陪伴 2024-07-26 07:13:15

让编写测试变得简单并且结果可见

  • 使用具有良好文档的 TestFramework。 就像 SimpleTest
  • 如果测试依赖于数据库内容,则创建一个参考数据库,该数据库将在测试开始时删除并创建脚本。
  • 制作一个运行所有测试并在独立监视器或使测试可见/易于访问的东西上显示结果的脚本。 (运行命令提示符不是一个选项)

我个人不会为应用程序中的每个代码块编写测试。
关注应用程序中的域对象。 在我的例子中,这些是“价格计算”和“库存更改”

提醒他们他们可能已经在编写测试,但他们在创建后立即删除了他们的工作。
示例:在开发函数期间,您将拥有一个带有 echovar_dump() 结果的页面/测试脚本。 手动验证结果后,您将修改函数的参数并再次检查。

通过一些额外的努力,这些测试可以在单元测试中自动化。 哪个程序员不喜欢自动化东西呢?

Make writing tests easy and the results visible.

  • Use a TestFramework with good documentation. like SimpleTest
  • If test depend on database contents, create a reference database that will be dropped and created at the beginning of a script.
  • Make a script that runs all test and shows the results on a standalone monitor or something that will make the test visible / easily accessable. (Running a command prompt is not an option)

I personally don't write test for every chunk of code in the application.
Focus on the domain objects in the application. In my case these are "price-calculation" and "inventory-changes"

Remind them that they are probably already writing tests, but that they delete their work just after creation.
Example: During the development of a function you'll have a page/testscript in with an echo or var_dump() the result. After a manual validation of the result you'll modify the parameters of the function and check again.

With some extra effort these tests could be automated in a UnitTest. And which programmer doesn't like to automate stuff?

多情出卖 2024-07-26 07:13:15

至于团队问题以及有关软件开发和测试的普遍想法,我建议 Joel Spolski 的网站和书籍: http:// joelonsoftware.com/ 我从他那里得到了很多见解。

As for the team question as well as universal ideas about software development and testing, I would suggest Joel Spolski's website and books: http://joelonsoftware.com/ I got many insights from him.

夏末的微笑 2024-07-26 07:13:15

SimpleTest - 优秀的 php 测试文档和解释

SimpleTest - excellent documentation and explanations of testing for php

离不开的别离 2024-07-26 07:13:15

启动 TDD 的另一种方法是尝试使用 PHP 框架。 没有框架,就很难有效地实施单元测试。

Another way to start TDD is try to use PHP framework. Without framework, it's hard to implement unit test effectively.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文