I feel like this isn't that hard. 1. Write (some) tests as you develop to help you Writing down your program's test cases should not add much time (assuming y

I feel like this isn't that hard. 1. Write (some) tests as you develop to help you Writing down your program's test cases should not add much time (assuming you have test infrastructure setup like you should), since you are already having to consider these things to simply figure out what the right logic is. With a little practice, you find a good rhythm for how far to take it for yourself. In my experience, I find this actually leads to faster and more correct solutions. 2. Collect tests while in review to cover the requirements Once you've written it though, it's always important to try and get others to look over your code and try and find flaws. Ideally, they can even write tests for you to add to the feature. This is just a standard part of any good peer review. 3. REGRESSION TEST Finally, though I'm not sure it matters very much who writes it, regression tests are something I never see stressed enough. I feel like if you are serious about testing, every bug should be required to add at least one test to the suite before it can be closed. Just my 2-cents.