Thursday, March 3, 2016

Influencing Unit Testing As A Quality Champion: How To Get Started

So recently I started working on a project which required me to write unit tests as my developer is working on the project. At first, I was a little intimidated as previous attempts at unit testing the application, did not turn out very well. Our team either created unit tests, but due to the way we've implemented some frameworks, they were not run...or they were too difficult to create and the team decided it was not worth the effort. Recently, I've decided that I need to take up the charge in creating fast easy to run unit tests, and that's what I've been trying to do.

Working with an application which was not unit test friendly, I decided that I needed small wins, one at a time and needed to get all of our devs on board. So to accomplish that, I decided I needed examples, that I created myself.

Creating Examples...Challenges Encountered

I quickly realized that I really needed to accomplish two things. First I needed to create tests that are easy to be used as examples. Second I needed them to be run.

Our unit tests need to use the MS Fakes framework. This is due to the nature of our application (or specifically our current implementation). I know this is very yesterday, and not recommended. But the way I see it, any unit test is better than no unit test, and once unit tests are written, we can start pulling pieces of our application apart without the fear of huge failure, due to our unit test net. But the problem with our business layer is that it is really woven together, and we could not pull fakes of individual projects out. So when we first tried to put our unit tests together, there was a lot of push back with respect to the additional build time, and the initiative failed.

About a month ago, one of our devs sent an email to the team which talked about how to isolate fakes to only the needed assemblies. This was very promising and I decided to try it. The approach basically calls for limiting fakes generation to a selected namespace. To do this, you will need to modify the generated fake file as below. By providing this limitation, you do not get access to all the possible namespaces in the project, but you basically get what you specify. This approach, has cut down on the build time which usually hinders our effort to implement unit tests, that are easy to run. So this is how I was able to accomplish tests that are easy (and quick) to run. So far, my tests have not taken more than a couple minutes to compile. Now you may think that is a long time, but really, it is not significantly longer than without unit tests...which is most important.



 Thanks to my developer buddy for pointing this out!

Now how effective are unit tests that don't run? Not effective at all, that's how effective! I decided I needed help from our dev ops team, and another developer buddy to help me attach them to a continuous integration build, or to create a build gate. I figured, meh, at least if someone checks something in, my tests will ensure that our stuff is not broken! So I attempted to attach the tests to a build, and realized that it was a lot harder than I thought. But, with the help of the guys mentioned above I am almost there. As of today, we have a test build setup with TFS 2015 Update 1, and it's "Vnext" build agents, which is utilizing build gates based on unit tests. Now these aren't my tests, and the build agent isn't hooked up to our production TFS servers, but I am confident that these steps are the beginning of a long fruitful relationship with unit tests, which will definitely improve our quality.

My future plan is to create a build definition in our production TFS , which will utilize the ability to use unit tests as a gate, and be the first team to do this, as an example for all of our devs.

My next challenge...to figure out how to measure our impact...Spoiler Alert: SonarQube :)

No comments:

Post a Comment