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

After I wrote the Pester Book I honestly didn’t do a lot with Pester for a while. It’s probably been four or five months since I had done any sort of Pester work after I had written that book and got it all updated. This was because honestly, my job role had changed. I don’t work at a full-time job anymore, and I am a business owner now; there are a lot of different responsibilities that come with that. But, recently I decided to start writing some Pester tests again for something that I had never even really considered. I wrote a Pester test to test essentially my entire business. It’s still not done yet by any means, but it’s a good example of what you can do with a framework like that.

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 sought out just starting to build these tests and because I needed to do this because there was just so many moving parts. Unfortunately, right now there are three different platforms, data sources where all these snips exist and I needed to sync between all of them, not the best situation. But, I needed to get a handle on what I had first before I started to worry about migrating to some other kind of platform.

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

Another thing that I have learned is that I’ve been sort of grappling with is my OCD tendencies to make sure everything is right. Us, as humans feel good if we can have a checkbox there and we check it off regardless of what it is. I have read a lot of productivity books that talk about people building checklists because they have already done the task, they build the checklist just to check the task off. In the long run, it’s ridiculous, it doesn’t matter, it’s a fruitless effort, and it doesn’t really matter. This is what I’ve been seeing with my most recent foray into writing these Pester tests.

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

I think originally, I just had some architectural problems because I would have these few exceptions in my test that didn’t really fit the mold. But instead of adding in an exception here and there (which I just hate one-off exceptions like that), I went back and tried to re-architect the next level, redesign the way this one test worked. Then, I would get frustrated because the design of this one test does not match the scheme or design of this other test, and it would just drive me crazy.

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

Ok, so I went a little bit off topic during this. I really didn’t have a specific theme in mind, but I did want to talk about my more recent foray into writing these Pester tests and the struggles that I have had. How much longer that it’s taken me to write these tests than I would normally expect. Kind of reflecting and looking back over what that experience has been like. I can see a lot of ways that I could have improved the process. Maybe when I start something like this again I’ll learn from it and maybe from me talking about my mistakes, my struggles will help you out as well.

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!