The pipeline: your arbiter of truth
27th of September, 2025
I recently had a mindset shift on how I have pipelines setup in team projects. Previously I'd chuck in the bog standard tests and checks. You know, the classic. Typescript, Eslint, prettier. Of course unit tests and so on too, but that was all. It wasn't until I had setup a new project, defined the patterns of how we wrote code then spent honestly too much time enforcing it during code reviews. It's not fun having to explain repeatedly that a file is in the wrong folder, or that someone had missed a unit test or even a story for our storybook.
Then it hit me - "why not just let the pipeline do that for me?"
So I wrote a node script which checked that each component had a corresponding unit test and storybook file. And immediately it cut down on me enforcing patterns during review. Devs couldn't have the pipeline pass until these conditions had been met. Not too shabby.
The added benefit here being that it encourages you to write documentation in how the patterns or structure of the project should be. Following that up with some simple tests to enforce that it is happening and you've just cut down so much time wasted in reviews being the 'enforcer'. The team I'm current leading is leaning on the less experienced side for the technologies we're using and this has been such a clear win in productivity. Not just because it's cut down the time I'm spending enforcing, but it's immediate feedback for my developers to understand how things should be.
It's made expectations clear while cutting down on the cognitive load of each review.
Now it has me wondering, what other tests could I add?