当你快完成时开始使用单元测试是否现实？
我花了两个半月的时间做一个项目，现在已经基本完成了。然而，我不断看到我过去修复的一些错误，这些错误又让我烦恼。然后我再次修复它们，另一个问题困扰着我。
我知道，我知道，我一开始没有使用 phpunit 和 selenium 犯了一个错误，但是现在开始使用它是否可行或现实（即使项目在 1 周内结束，我还有一些部分需要完成）？
提前致谢
I've been working for 2 months and a half in a project and it is practically finished. However I keep seeing some errors I fixed in the past that come back to annoy me. I then fix them again and another one bugs me.
I know, I know, I did a mistake not using phpunit and selenium at first, but is it viable or realistic to start using it at this moment (even if the project ends in 1 week and I still have some parts to finish)?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
编写一些单元测试永远不会太晚。
当您有错误需要修复时，您有绝佳的机会添加单元测试并展示其价值。因此，编写显示错误发生的测试，修复错误，然后重新运行测试。如果问题再次出现，您将获得绿灯并有信心立即发现。
您不会完全覆盖您的应用程序，但如果您在发现和修复错误时不断添加测试，然后为新开发添加测试，那么覆盖范围将会增加。
It's never too late to write some unit tests.
You have the perfect opportunity to add unit testing - and show it's value - as you have bugs to fix. So write the test that shows the bug occurring, fix the bug and then re-run the test. You have a green light and the confidence that you'll immediately spot if the problem recurs.
You won't have complete coverage of your application, but if you keep adding tests as you find and fix bugs and then add tests for new developments the coverage will increase.
测试总是会增加你的开发时间，除非你有一个团队。根据我的经验，项目永远不会真正完成。即使你已经把它交给了。用户总能找到有趣的方式来使用你的产品。
我建议对项目进行单元测试总是一件好事。它为任何需要在几个月内启动并运行该项目的新开发人员（包括您自己）提供了一个良好的开端。
如果可以的话，我强烈建议您添加测试。从长远来看，这将使生活变得更加轻松，但是，如果您计划交付该项目并且不再接触它，或者您在不久的将来不会再处理它，那么您可以将其保留。取决于您正在寻找的好处。单元测试对于长期项目和支持合同几乎总是有利的。
Testing always adds time to your development time, unless you have a team for it. In my experience, a project is never really done. Even once you have handed it off. The user always finds interesting ways to use your product.
I would suggest that it is always a good thing to have unit testing on a project. It gives a nice start to any new developers that need to get up and running with the project in a few months time, including yourself.
I would highly recommend that you add the testing if you can. It will make life much easier in the long-run, however, if you are planning on delivering the project and not touching it again or that you will not be working on it in the near future, you can leave it out. Depends on the benefit you are looking for. Unit testing is almost always nice for long term projects and support contracts.
迟到总比不到好。也就是说，我已经看到相当一部分项目上线，无论是否有可靠的单元（或集成）测试覆盖率，我不能说经过良好测试的项目在野外表现出较低的缺陷率。它们只是倾向于以更意想不到的方式打破。
但是，如果您遇到反复出现的错误，那么为它们添加快速测试可以节省您相当多的时间，因为您会立即知道问题何时再次出现，而不必记住手动查找每个错误（或者更糟糕的是，失去了它们的踪迹并让一个人从裂缝中溜走）。当测试覆盖率完全缺失时，您可以通过为最长期的问题添加一些简单的测试来获得巨大的收益，无论是花费的时间还是获得的理智。
Better late than never. That said, I've seen a fair share of projects go live, both with and without solid unit (or integration) test coverage, and I can't say that the well-tested ones showed a lower defect rate in the wild. They just tend to break in slightly more unexpected ways.
But if you have recurring bugs that keep cropping up, adding a quick test for them can save you quite a bit of time, as you'll instantly know when a problem has resurfaced instead of having to remember to manually go looking for each one (or even worse, losing track of them and letting one slip through the cracks). When test coverage is completely absent, you can win big by adding some simple tests for the most chronic issues, in terms of time spent vs. sanity gained.