Is it realistic to start using unit testing when you're almost done?

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 usi开发者_如何学Cng 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

---

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.