Going Down the Rabbit Hole of Testing

If you’re not familiar with Pester, it is a PowerShell testing framework. It is one that I wrote a book on and I’m very familiar with. I love, and I use every day. But, what I’m going to be talking about is not necessarily going to be directly related to Pester. It’s more about software testing and testing in general, software development and DevOps, that sort of thing.

Pester Testing for Entire Business

The sweep that I’m building now is basically testing every piece, the whole back end infrastructure that makes TechSnips work. Not only the platform that you see on TechSnips.io., but also coordinating sponsors with client’s different content needs, subscriber requests, contributors, the courses that we are going to be doing fairly soon. There is just a lot of logistics in the background that has to be done, so I decided to start writing some Pester tests for it.

Work Smarter Not Harder

I thought it was just going to be a day or two, it’s been a week in and all I’ve been doing is writing Pester tests. Now granted, that entire week has not just been writing the test. I could have probably tested everything that I wanted to test within a few days, two or three days. But, it’s been taking this long because how I approach coding and problem-solving in general. It’s a problem that I have, that I know that I need to work on. But, I started out writing the test and I just start coding immediately, I hardly do very much planning whatsoever, I just want to get started immediately. I get started and halfway through, I realize, okay the way I have been structuring these tests is definitely not the way I can do this to make this a more efficient test suite.

So, I started again. I have rewritten them three times now and I think I finally got the right methodology to where I can structure these tests. But, I would have completely eliminated those first two times if I would have just planned out all of the attributes. So, that is one thing about testing in general. Start out with a plan first; define everything down to the most granular detail that you possibly can because you could mix and match text if you are just going to write an outline of what you want to test. You could just copy and paste and move around the text as easy as you can. But, once you get into the code, you get all those dependencies related to everything else, it gets a little bit more difficult obviously. So, that is one thing that I have learned.

To Check, or Not to Check

Because I want all of the tests to come back green, I want to make everything standardized and everything exactly the same, I want all of the test to come back green. But, if a thousand tests come back green and a few come back red I look at them. When I take a look at the failed test, I discover that honestly, they don’t matter at all. The state that they are in, it does not matter if the test failed at all in the long run with what I am trying to accomplish.

But, since it is red, I spend an inordinate amount of time structuring the test and building the test and fixing all of those little pieces that are red just to see the green. Just so I don’t have to go down through and add in a bunch of exceptions. There are some good things about this, some positive things about making sure you have a standardized methodology and making sure you treat everything the same, eliminating the exceptions. These are just good general coding practices, but in this case, it just didn’t work out.

Making all Tests the Same

This was another thing that took me so long because I wanted to make all test standardized, pretty much the same. I was able to add or remove test as I wanted, instead of putting in a bunch of static blocks in there like that.

So, these are a few struggles that I have had. I think right now I can finally feel me being okay with the architecture that I have chosen to build these tests out. If you are like me, my personality I couldn’t just let it go. Whenever I start on a project that I care about and I want to succeed, I just can’t let it go. It’s more than an OCD thing, whenever I do let it go before it is done; it is that completion compulsion that I have heard it called. If I am not satisfied with an outcome of a project, I will do whatever it takes, however much time it takes to complete it to my satisfaction. “My Satisfaction” is a pretty relative term, it is at some point you just feel good about it, okay I feel internally satisfied. Okay, these tests are built the way I want, they can be easily managed over time, they are not frail or fragile. Same thing with coding.

Learning from My Mistakes/Struggles

This post was brought to you by yet another #CarTalks YouTube video. Be sure to check out all of the other #CarTalks videos and other video content on the Adam the Automator YouTube channel!

A 20-year veteran of IT, crypto geek, content creator, consultant and overall problem solver.