Story

I’m a 7 year full stack developer, on most which jobs I’ve had, have had Angular as the front end codebase. One thing constant in my career is I’ve had a unique relationship with sort of the ‘ugly/unsexy’ side of software development, particularly the part that make front end developers groan: unit testing. ** On my first big time software job, I was on a greenfield project, the first one in our department to use angular, back in 2017, and my 3-person team was tasked with getting these things called ‘jasmine’ unit tests to cover our angular component. Who the hell is jasmine, and why did she choose me to torture on my first project?

For weeks, I was thinking, ‘what in the actual hell am I looking at?’ Testing, what does this even mean? It works, doesn’t it? Mocks? Stubs? Observables (there’s a nice learning obstacle to throw in the mix). Eventually I learned the thing, months and many work weekends later, and what started as this surprisingly unpleasant, seemingly random ‘just gotta do it thing’ in the world of software’, became almost sort of a serendipitous/routine run in with me, and needing to make big things happen with unit testing: ‘How does this Jamsine thing work? Can you take these coverage stories?’  All the while, I’m thinking, ‘so this is some fluff and paperwork to show to a manager, to show to his manager, to get brownie points, right?  “See how proper and we tune we are?” A bunch of crap, to check a box, cross a T and dot and I, something pretty and clerical: politics is how I saw it.

In the middle of my career, I encountered and interesting fellow who laid the groundwork to change all this, working on my first full time backend job on a net shop. One of my coworkers and earliest mentors, was Benjamin Bolton. If wisdom could age in reverse, he was living proof. Every time I thought I caught up, he was already thinking ten steps ahead.

 If you could imagine the perfect software communicator, with all the right inflections, the right attention to details, words carefully crafted for the most easily confused person to understand, it was this guy, and maybe I needed to cross paths with him to understand something - He swore by this thing, called snapshot testing: to practice of mimicking a real-world scenario in the form of a rest api response, and checking the inputs of a rest api against those real world expected outcomes. He said he learned it at a conference, I didn’t think much of it to be honest, one developer hardly cared about it, one developer was meh… I was the young buck in the back-end space, I just nodded my head and went along with it, I did what he asked me to ‘consider’ in all the PRs he commented on and made the snapshots.

Following my time at that company, I had a mixed bag of the tightest, cleanest code you’ve seen, the kind that makes Uncle Bob giggle in his sleep: not just small functions, small files, just the right amount of abstraction at the right time, like the author had a poster of the SOLID principles in his room.  

And, well… there was the code on the other projects, 50 line methods, repeat code Galor, unit tests:  multiple test cases without an expect statement (just a coverage grab). The coder might as well have screamed: "Let me get this working’ and just go home!".

 This stark contrast was actually the first time I recognized, or even thought about, ‘good code’ vs ‘bad code’, and I didn’t see something unpleasant like bad luck, but an opportunity, to add value.

What if I brought snapshot-like testing to angular? And we were no longer checking a box to get coverage: where we're writing tests cases that say "I pass in 'userA' into 'verifySSN number' and should expect true if match found' (essentially one piece of a login functionality on a component, but of course the describe doesn't tell me a damn thing other than 'hey, I tested it! treat please!),

but instead features on a page, that can be described as 'user will all valid credentials is logged in'. I started making my tests cases, and suddenly, I felt like I was a BA (or UX), writing all the features of the component, and I became an expert on that component. I also tested very specific scenarios of the features (not methods) like, 'the user was not logged in due to an invalid SSN', so all the use cases, in all the methods that made up a the login would get covered, but this time we weren't just cornering down a method, we were cornering down features, and this ensured every business logic scenario we tested, basically ensured every scenario of the functionality prevent a bug for that scenario: because 50 well tested individually can cause a bug, and the question is, 'where did it go wrong when we debug the bug, which method', the question becomes, which scenario did we not unit test for, not 'which function is wrong'.

I want my readers to add value, I want them to think like BAs, to test like BAs and focus on the business. What better opportunity to show you know the business than with test cases testing business problems? Business experts, regardless of job title, keep their jobs, are liked by their bosses, and are go-tos for all your dev friends asking about the product. That coder who knows just the perfect function for getting that matching element from a triple nested array, that's either your team leads work, or his little AI helper's function. Sit in a corner and code brilliant problems guy's days are numbered.