How many times have we started the day with a smile, big mug of coffee and enthusiasm for what is ahead of us...An exciting new project of creative writing, also known as programming! Where every day is a new, exciting adventure; filled to the brim with easy to solve bugs, fun algorithms, and awesome new technologies, we’ve been experimenting with! A blissful day indeed!
Until the coffee washes the sleep out of our eyes and we realize that yesterday we stayed up late, implementing all the fun bits and the only thing left to do today is to write tests. Similar to the effect of hearing yourself speak during a call, you have to persevere and dive deep into your code’s logic. The code you’ve written in a sleepless, caffeine-induced mania. Where variables start off as CamelBack and slowly devolve into meaningless words… The deeper you go, the less characters you see. Like the light of a torch fades, so do our comments.
Not that bad, we say to ourselves – I’ll just test this (obvious) input, catch that (obvious) corner case and make sure it’s handled… maybe add a few extra safety steps... Oh, this one will never be hit? No problem, test coverage is important. It makes my commit message look great. And I can brag about it during the sprint planning this afternoon? Sign me up!
So, we carry on being responsible developers, write up a few more (obvious) test cases and make the coverage report look amazing, brag about it and move on with our day.
A few weeks go by. We resolve some more tickets, implement some more fun features, write some more (obviously) diligent tests. Life is great. Until we get a bug report related to the fun algorithm we did. The one we wrote loads of tests for and made sure we are good developers for? “Oh, sweet!” We think to ourselves, as we chair-dance to our favourite song.
We fix the easy to solve bug, run the debugger and mark the ticket as done. Wait... what are these errors? The tests failed? No… It can’t be. We were such good developers, what happened...?
It’s a common scenario for many developers. And as technology moves at a higher cadence year by year… so does our Jira backlog. Learning new languages, catching up to all the new features of old languages (C++17 anyone?), getting used to the latest Microsoft office product… It’s all too much, too fast.
But we do catch up to the latest, trendiest open source project changing the world over. We are forming a continuous integration team (of one person). We’ve heard of Kubernetes. Maybe some use it constantly since they got hired as full stack developers. Others are turning into full stack developers, but without the fancy title (or paycheck). They’re just staying ahead of the curve and being paid peanuts for it.
The reality of today is that we have to stay on top of things. Including tests. Test driven development is a phrase we all like using and love ignoring the fundamental meaning of. Some of us, rightfully so, turn to automated testing tools driven by AI in order to start the project right, tackling the scariest part during the design phase, rather than at the end.
Going back to the fun algorithm anecdote, which we’ve obviously resolved.
We find ourselves in the sprint planning meeting. Our manager gives everyone the chance to shine, which we’ve eagerly been waiting for. The one thing we’ve been eagerly awaiting for during the past two weeks (or more, if your managers are meanies).
Everyone lists their list of incredible achievements, quickly glances over the tickets they didn’t get around to and… It’s our turn. Oh, the fun algorithm ticket? Of course, we fixed it. Tests? Of course, we wrapped it up, we’re good developers after all! Oh, it’s time to push it to deploy to the clients? Oh… right.
We do our best to look eager, as we take on the task, which we know can be over in an afternoon… or take the rest of the sprint. No matter, we get on with it and head to DevOps(also called DevTestOps or QAOps).
Or, we would’ve, if the team was formed, as was promised, several months ago. No matter, we volunteer our time, as a good developer does, and deploy ourselves.
So we open up our trusty text editor, create the extensionless Jenkinsfile and get on to work. We write the classic “Hello world” send it to the nether and after a few minutes get an email telling us the build failed. No biggie, surely there’s a boilerplate floating around, which we could use.
So we start digging through the proverbial drawer, also known as our Gerrit server and find some commits related to Jenkins. Those look pretty good, let’s make use of them. After stripping out all the capitalised variable and delete all the “NB:”, “TODO:” and function instruction manuals, we are finally ready to implement the fun algorithm.
After a few hard hours, we get beautiful 100% test coverage, beautiful, green PASS-es are seen everywhere. It could only mean one thing. It’s time to deploy. Fearlessly, we hit the deploy button and contemplate going for lunch. It will probably take a while, surely, so we get up, put on our coats and… Bing! A new email from our service ops account? What could it be…?
Oh, look! It’s from Jenkins!... Hm, that’s strange, the word success appears nowhere in the Outlook notification. So we open it up and are greeted in big, bold, red letters – “Build failed.” Fantastic. And we were just about to go for lunch too.
Turns out our manually written, locally grown, organically produced tests don’t fare so well out in the cloud.
We, developers, are creative people. Similar to writers, we turn an empty sheet of paper into a work of art. We wait for the muse to strike, and when it does, we grab it by the horns and fly off into the night, only to wake up the next day with an incredible spawn of love and care. Sure, it might not be the most beautiful kid in the class, but it’s ours, you know? We made this. And it’s (obviously) perfect. Why on earth would we want to change that?
In conclusion, the best way to describe testing is -- complexity. It’s a challenging, grueling task, closely followed by writing documentation. It’s a mechanical process, which we, as artists, tend to avoid. There’s nothing creative about going through your own painting and adding the glass and the frame around it. Of course there’s value to it -- we protect the baby we’ve nurtured over that one exciting night of passion.
But at the end, it’s difficult changing who we are. Add to that the need to stay on top of the latest and greatest frames, the trendy new polyglass that’s all the rage nowadays and the incredible new manuals on paint framing… and it all just turns into an impossible task!
Top comments (0)