put it all in the harness. same run every time, modulo races, and a lot less tripping over magic you can't always remember or show to someone else.
If you want some concrete examples, here you go:
Here's my "Spinner" widget:
https://github.com/RiftValleySoftware/RVS_Spinner
This is the four test harness apps:
https://github.com/RiftValleySoftware/RVS_Spinner/tree/main/...
This is my checkbox widget:
https://github.com/RiftValleySoftware/RVS_Checkbox
Here's the test harness app:
https://github.com/RiftValleySoftware/RVS_Checkbox/tree/main...
There's more, but these should be enough to illustrate the point.
My understanding is, test harnesses are standalone wrapper apps dedicated to testing, vs more granular unit tests which are traditionally colocated with (eg, files alongside) app src code in a given project. Care to elucidate?
^ from https://littlegreenviper.com/testing-harness-vs-unit/
I’m big on this.
I find it efficacious to have an integrated product going as soon as possible, even if it’s a field of stubs.
It’s my experience that I almost never know what the end product will look like, no matter how much upfront planning time I devote, so being able to test and iterate the whole system, as soon as possible, is pretty vital.
It’s also one reason that I like to use test harnesses a lot[0].
[0] https://littlegreenviper.com/testing-harness-vs-unit/