(In response to "What's your biggest challenge in proving your automated tests are truly covering everything important?" on Reddit)
As a Software Engineer, your job is not writing tests. In fact your job is not writing code. It's delivering features reliably and quickly. Tests are just one way to prove to yourself, the team, and the business, that the quality is high enough.
It's a feedback loop.
The best CICD "pipeline" I've ever used was just a shim which automatically runs the project-based tests. If you run the full suite locally, the pipeline won't do anything surprising and it's just a backstop.
Learn your test tool very well, with an eye towards narrowing the scope of tests which run after a code change. This increases the feedback speed.
If you're doing Python: pytest has options like "run this test starting with the last-failing test, then continue" which make it stupid simple to have a super fast dev loop. (Please comment on how to do this with your language/tool, I'm curious)
One tool I use on 100% of my projects is a little thing that runs a script when a file changes. Get to know it and love it, or find a replacement. https://jvns.ca/blog/2020/06/28/entr/
My core dev loop is:
1) write a little test with high-level thoughts about the feature
2) write a little code that implements some of the feature
3) execute "run tests when files change" in a terminal
Then the feedback loop is very fast: edit the high-level test, save the file to immediately see if it worked. Or, add code to the implementation, save the file to immediately see if it worked.
Very often I'm not sure about what to do so I put a "drop into debugger" command into the test or code and then rerun the test. It does some stuff then gives me an interactive prompt. I can single-step the code/test, examine variables, even make API calls. So much fun!
Top comments (0)