Don’t wait until the end of a project to write tests. It doesn’t work.
Writing tests is never urgent, but it is very important. Devotees of Stephen Covey will tell you this puts it smack in the middle of quadrant two: things that are important but not urgent.
Quadrant one, urgent and important things, prevent any other work from being done. Unfortunately, the final stages of any project are chock full of urgent and important things, like fixing bugs, building deployment packages, scheduling rollouts, and other fun. All these are important and urgent. If you haven’t written automated tests at this point, don’t start.
No manager will ever tell you, “Sure, we’ll delay the launch by a week so you can write some code that won’t ever be executed in production and has no bearing on the project making it out of QA”.
So, if automated testing lives in quadrant two (it does), and that no real quadrant two work is possible at the end of a project (it isn’t), you need to write your tests early, when quadrant two is in full effect, at the beginning of the project.
I’m not saying you need to do test driven development. That’s hard. All I’m saying is that it’s important that tests keep pace with code. Get in the habit of running coverage tools when you finish modules, and write tests before moving on.
If you do find yourself at the end of the project with no tests, don’t panic. You’re not a bad person. You’re not a bad programmer. You just didn’t write tests. Don’t try to write them all at the end. You’ll only get frustrated and stressed out.
Finish the project, fix any last-minute bugs, and deploy. After that you’ll be back into quadrant two, and you can write all the tests you missed the first time around.