[Starlingx-discuss] Unit tests first!!!
Hey everyone. Following on the success of our recent StarlingX test hack-a-thon, I'd like to remind everyone about our goal to submit unit tests along with new (or changed) code. As a core reviewer for many of our projects, I often see new code being put up for review with no unit tests. At that point, you have working code and it feels like going back to write unit tests is a lot of effort (and it can be). To avoid this, I would highly recommend that you write (and execute) your unit tests BEFORE doing any testing on hardware (or virtual) labs. This has big advantages: * The unit tests catch many errors in the code and the test cycle (running tox) is extremely short. This saves time when you do get to the point of testing on hardware because you will be dealing with far fewer bugs. * Many error conditions are very easy to catch with unit tests and either very time consuming (or impossible) to test on hardware. In this case, the unit tests are a big time saver and result in better quality code. 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. Bart
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
participants (2)
-
Jeremy Stanley
-
Wensley, Barton