Unit Testing is Important

February 20, 2017

This is not a revolutionary statement.
I am not the first to say it. I'm sure I learned it in a textbook, and forgot it.

It should be core to our process. It should be a necessary skill that is taught and enforced. It should be a requirement before shipping code.

But the reality is, it isn't. Testing is fungible. Testing is an 'ought to have'. Testing is the first thing to get cut.

It is easy to rationalize away. I'm guilty of it too.

Unit Testing? What's that?

In college, we had 'tests' our professors would give us as guide posts to ensure our projects met the bare minimum requirements. Mostly, these were sample inputs and outputs, rarely, these were bash scripts. Each professor had a different way of defining these tests, never using formal testing frameworks.

This lack of unit testing was compounded when I started working for "real companies". Millions of lines of code, and no unit tests. Ask one of the "architects" of the system, an engineer with a career spanning more years than my age, about unit testing, and you'd hear a cynical response. "Thats a waste of time and money. We have an entire team of Quality Assurance Engineers. They are good at finding our rare mistakes".

I was skeptical and cynical of unit testing because I never properly learned how to unit test. I never got to experience the benefits having a good unit testing suite with good coverage. Because of this, I would focus on the cons list when reading about unit testing. I was lead to believe testing was someone else's job.

Testing is difficult. Developing a testing culture requires investment. Testing will slow down development.

At first

Learning & unlearning

A few years ago, I started to re-evaluate my stance on unit testing. It helped that I had starting working heavily in Ruby, a language where tests are expected. I started reading books, listening to conference talks, and more importantly, starting writing unit tests. I wrote a lot of them, often times writing more lines of rspec tests than code. I would write unit tests that tested all the branches that existed in my code. I wrote tests to achieve near 100% code coverage.

“Fail Fast. Fail Small.
You have to go slow to go fast.”

— Unit Testing Mantra

As I continued my education, I started deleting low-value tests to speed up my unit-tests. I strived for fast-feedback. I'd configure my editor to re-run tests on each save. I'd monitor the code coverage.

I set up tests first, on a new project, so testing was not an afterthought. I would slow down my development to ensure I was testing as I went along.

I continued learning, re-evaluating my understanding of Object Oriented Design. I read POODR & 99 Bottles of OOP. I recognized that software comprised of truly decoupled units was easier to unit test. I saw the benefits of SOLID & STABLE code.

The Benefits of Unit Testing

“Unit tests are the wall at your back”

— Sandi Metz

Having unit tests that can provide fast feedback enables a new level of development. It enables developers to make a change in code, predict the outcome, and test the expectation, in a matter of seconds. It enables developers to evaluate their code and refactor it - that is, make modifications to the code without modifying the behavior. It makes development safer. It enables developers to talk concretely about their changes, "I know" vs "I think".

Looking back and comparing how my code has evolved over the years, there one significant, overarching pattern that has emerged. Code that is easy to test is likely easier to understand and modify.

I can unit test, and so can you!

The hardest part of unit testing is starting. This pain grows exponentially by the number of lines of code written without tests. Have 10,000 lines of code in a legacy application without any tests? Yes, setting up tests will be painful. You should still do it. That doesn't mean you need to write unit tests for all of the code. Fixing a bug? Write a unit test that exercises the code path where the bug exists. Writing a new feature? Write unit tests that test that feature.

Setting yourself up for success early in a new project is best way to foster and grow a unit testing culture. Develop a boilerplate that has the testing framework already set up. When the batteries are included, it lowers the barrier and hesitation to enter.

As the use of a unit testing culture develops, it will eventually reach a self-sustaining cycle. New developers added to the culture will see the emphasis of unit testing in the code base, and do their best to follow the pattern they see. Further, having developers who are proficient at unit testing means you have a set of teachers ready to coach those without a strong unit testing background.

Does writing unit tests slow down development? I can't say this with any authority, but, based on the anecdotal evidence of myself, the answer is no, not in the long run. There will be a ramping up time where a developer needs to learn how to set up the framework, and write unit tests, and how to run them. But, that is a sunk cost - it needs to be paid once. The unit testing will help catch bugs earlier. It will prevent a broken build from being merged. It will likely speed up development time in the long run.

Resources

In no particular order:

99 Bottles of OOP by Sandi Metz and Katrina Owen
Therapeutic Refactoring by Katrina Owen
Refactoring by Martin Fowler
Get a whiff of this by Sandi Metz
Is your Code too SOLID? by Sarah Mei
rspec
Exercism.io
TDD is dead. Long live testing by DHH
Have more fun coding by writing better tests by Noel Rappin

A Code.

August 1, 2015

"I have to write code!", said my wife, day 1 after starting her masters, quite excitedly.

"I have to write code....", said my wife, after getting her first assignment, dejectedly.

"I wrote code, but the code doesn't work!", said my wife, after spending a few hours on her first assignment.

"I wrote the code, and it is working, but now I want it to do more!", said my wife, after completing her first VBA assignment.

I sat there, slightly amused. There was something always fascinating of writing a bunch of code, and then hitting a button, and then seeing something happen. I still get that feeling - although the stakes are a bit higher now. It is now more along the lines of doing a big refactor, and have the integration and unit tests pass first time. Or slogging through a bunch of code, only to be left frustrated and walking away for a few minutes, and then coming back, making a small tweak, and things start working again.

"I don't understand how to do this. Why can't I just do X and have Y happen?", says my wife, as she now starts a slightly more complicated assignment.

"I dimmed this and now its not working!", said my wife, after trying to declare and define a variable (I politely explain that Dim is short for Dimension, and dimmed as a verb is not in the standard nomenclature).

"... I then do range open parenthesis quote A two colon B twenty two...", as my wife tries to recite code over the phone to me during a live debugging session.

She found her next assignment quite daunting - iterate over a list paragraphs, find words with more than N characters, count the number of occurrences in all paragraphs.

"Have they gone over loops? No? What about data structures? Yes... array thingies are data structures", as I quiz my wife about she has learned as I try to guide her to coming up with a solution for her latest assignment.

"Here is what the output of your macro should look like, once you are done.", I say showing her the output after writing about 20 lines of ruby code.

"Is this in your ruby thingy you use for work? HOW DOES THAT HELP ME?!", says my wife, somewhat annoyed at how easily I wrote the ruby script.

I admit I was showing off.

But, these few interactions have reminded me that there is more to what we (as people who push buttons to make the rectangle of lights do what we want) than write code. And further, teaching code - that is the syntax and grammar of software - without high level theory, such as data structures or algorithms, or at least how to use arrays with sorting or search algorithms (if not how to implement them), is a tremendous disservice.

It would be like teaching someone the english language, and then ask them to write a sci-fi novel, without teaching them the basics of literary elements.

So, I kept telling my wife to take a step back, and not to worry about the VB code just yet. I asked her to describe the problem she was trying to solve. Then, to break problem down into smaller problems. Soon, she realized that the entire project boiled down to a few core problems, that were repeated in a larger and larger scope.

Now, armed with her VBA for Dummies book (assigned course reading, apparently), she started working through each of the smaller problems. When she ran into something she didn't know, she would turn to google, like she did before. But to her surprise, she was able to find results now, especially on that "stack overflow thing".

Before, she would search for "find unique words in a list of paragraphs VBA". Now, her queries were more specific - "split words on space VBA", "find word in range VBA", "loop through cells in a range".

As her assignments grew more and more complex, I kept reminding her that before she can start solving a problem, she needed to understand the problem. Once you understand the problem, then you can go about asking for help.

I think that last bit of advice is important, even for me, and even for things unrelated to coding, or engineering. We are often in such a rush to solve the problem, we try to short circuit to find a solution, without stopping to understand, I mean really understand, what the problem was to begin with. Understand it so that you can confidently explain it to someone without prior knowledge of the situation, so they too can understand it.

My wife was able to handle the coding assignments with ease, and pass the class with a grade she was proud of.

I still can't get her to stop calling snippets of code "A code".

Reading with my Ears.

January 11, 2015

In 2013, I read 3 books. 3. I spent a few moments rationalizing why I had only read 3 books in 365 days. I came up with the universal excuse - not enough time.

Not enough time? Sure, I may have been working 60 hours a week. I probably was watching too much mind numbing TV. But that still did not account for 24 hours in a day, 168 hours in a week, or 730 hours in a month. Seven-Hundred-Thirty hours in a month. 260 hours could be explained by work, I only slept 6 hours a day on average - another 182 hours. 730 - (260 + 182) = 288. 288 hours in a month was what was conventionally thought as free time.

That's almost an average of 9.5 hours per day. Yet, despite that 9.5 hours, most days ended with me wishing for a few extra minutes. I did what any engineer would do - I gathered data. From the moment I woke up, till the moment I went to bed - I wrote down what I did. What I found was that the majority of free time was spent with my mind being passive. I was cooking breakfast, or getting ready for work, or folding laundry, or doing dishes. Yes, this time was not ideal to sit down with a cup of caffeinated hot liquid and spend hours reading a book - but it was time that my brain was only doing one thing.

I made the conscious decision to start filling that time with people speaking into my ears. First, I started with podcasts. RadioLab, 99 Percent Invisible, TED Radio Hour, Freakanomics - there were a lot. It may have been the advertising on those podcasts, but I started hearing a lot about Audible. I was someone who wanted to read more, and had time to listen to podcasts. So, in 2014, with the help of Audible, I read 20 books. Yes, read - the biological sense that I use to get written words into my brain doesn't change the verb used to describe the act of consuming books - I will fight you over this. Anyway, 20 books - thats more than a 500% increase.

So what did I read? Old favorites, new favorites - fiction about space, non fiction about space, books on presidents, books on history. As Maria von Trapp sang - these are a few of my favorite things: