"I'll add tests in a separate PR"
"I'll add tests in a separate PR".
Ouch.
5 reasons to add tests before merge:
1. Clear memory: Before merge, everything is fresh in my mind. I know what the code is supposed to do, because I wrote it. So I also know what tests I should write to assure it works. Every minute that passes after merge, I will understand the feature less, and thus, be less equipped to add proper test coverage.
2. More effective reviews: If I write the tests before merge, then anyone reviewing my code can use my tests to help them understand the code, and to watch the feature run.
3. Faster development: If I write tests during development, I can use the tests to accelerate my development. I can automate the browser. I can "lean" on my tests as I refactor. Faster feedback loops = faster development.
4. Better design: Writing tests during dev encourages me to write code that is testable. It makes me consider accessibility too since that tends to make automated testing easier by providing well-labeled targets.
5. Changing priorities: After merge, there's no guarantee that I'll have time to write the tests at all. I may get pulled away for other more "urgent" tasks.
Bottom line: The proper time to add tests is *before* merge.