Sooo...this past few weeks I've been getting down and dirty with a type of testing that is new to me, but not new testing (see how I did that? ;)). The type of testing that in my opinion, should be the start of the quality cycle during development, what say you, am I speaking of? Unit testing of course! Finally, after months of being to "tied up" and "busy", I had the opportunity to devote at least 6 hours per week, to learning how to unit test stuffs.
This opportunity was created, by the launch of a pilot class for our advanced "Top Gun" training program. Being a pilot, I thought I needed to prove out the fact that unit testing (and TDD in greater context) could be taught to people who did not come from a traditional developer background...aka yours truly.
Is Unit Testing Hard
Welp, the short answer is yes. The long answer, is yes initially, but not in the long term. So my first foray into unit testing, was focused around an area of our team's product, which focuses on ensuring a thing, can fall into a queue. So essentially, we are testing to ensure that the method which decides if something should be in a queue works.
The Hard Part
Unfortunately, the thing that we are testing, is not well suited for testing, due to lack of abstractability through traditional means such as interfaces. So, we could not new up our own real thing, and pass it into our queue checker method. What to do? No useful interfaces meant we were in a pickle.
Mocking & Shimming To The Rescue
As a small team focused on attempting to unit test something that is hard to abstract, we decided to attempt to create a shell of the real thing, and fill it out as necessary through a mocking framework. I won't get into the nitty gritty details, but essentially mocking out a complex allows you to create a scaffolding of properties and methods that belong to the object, and when called, need to be provided input down to the property level. For example, if you have an order, which requires a transaction, which requires a list of requirements, which is a list...you'd need to provide your shell with all of those elements, but nothing else. The powerful thing is, by creating the shell and providing the information necessary, you understand what the expected outcome of the method call should be, therefore are able to ensure it is or isn't working properly.
The Easy Part
So after going through figuring out which pieces needed to be filled out in our tests, we were able to abstract a few of the repeatables away, which allowed us to become faster, and created an overall repeatable and understandable process. Which to me, shattered the stigma of a hard unit test.
What This Means To Overall Quality
Think about it this way...as a quality fanatic, I want to be involved in all aspects of the application stack. From how the code is written, to how the pieces talk to each other, to how the GUI works. Unit testing provides me the technical ability to speak to provide quality at the very lowest technical level, and at the very earliest possible time, with respect to when the application is written.
Additionally, writing unit tests, forced me to understand at a very granular level, how our application logic really worked. This is a very powerful idea. I now can understand what methods drive our queues!
I believe that all quality champions should get involved in unit testing, as that is where the meat of your application logic lives. You will help your developers code faster (since they won't have to write unit tests), you will help your team achieve higher quality (since tests will be written earlier, and be more granular) and you will definitely help yourself, by becoming more technically savvy.
But most importantly, you will keep striving to the ultimate Quality Champion state...