On 2020-01-31 19:25:55 +0000 (+0000), Wensley, Barton wrote: [...]
So... my advice is to write your unit tests up front whenever possible. This saves time vs. writing them after you have already done your hardware testing (or worse - after your review has been given a -1 due to missing unit tests). If you have questions about what unit tests would be expected for a particular change or how to write them, contact one of the cores for the project you are working on - they will be happy to help.
Speaking from personal experience, making changes to untested code paths is harrowing. I have no idea whether the already existing code even works, much less whether my change will make it better or worse. I find it especially comforting to first submit tests for the code I'm planning to alter. That way when I submit the code changes I have proof that they either don't alter the tested behavior (if they aren't supposed to, for example a refactoring), or I'm forced to also include changes to the tests which reflect the tested behaviors being altered. This is a huge help to reviewers as well, since they can see immediately what behaviors are changing and confirm those are expected. So I second your advice to incorporate tests when proposing changes which add new features/behaviors, but also strongly recommend adding tests for previously untested code *in advance of* modifying it. Including new tests in the same change as your behavior modifications is too late to get full benefit from them. -- Jeremy Stanley