Today, I am starting a small series of entries focused on unit testing. I thought I’d start out with a bit of my background and why I got interested in testing.

My first office job was at Midwest branch office of a Japanese International freight forwarder. I was excited because I’d always wanted to work at at a company with International ties. Part of the work was communicating, with branches and government agencies all over the world, It was fun to practice the Japanese I knew with co-workers. I was excited to be there.Previously, I’d been working service industry and labor intensive jobs. The change meant stability for me and meant I could have a career doing the type of things I always thought I wanted to do.

The work wasn’t bad. It was a bit of customer service, a bit of data entry, a bit of sales. The pay was low but the benefits and hours were great. The company was stable, we never had layoffs even though the recession of 2008 occurred while I was there. I liked the people I worked with and felt that compared to previous jobs, I was building a resume that I could turn into a career. The only consistent complaint that I had was regarding the software we used. It barely worked.

The AS400 based program that we put shipments into was a labyrinth of options that worked, deprecated features and half baked ideas. Navigating the maze of options to successfully complete a task was not possible unless you’d been trained to do it. The magic combination of keys to press to generate a set of shipping documents was passed down from employee to employee like a secret incantation. You’d enter the same details in different fields three or four times. There were special fields to add extra information that had to be entered that was only known from tribal knowledge. A successful pushing of the right combination of keys was signaled by a dot matrix printer spitting out copies in triplicate on carbon paper in the the other room. After collecting the documents, you’d slide the paper into a large IBM electric typewriter to add information that the software had not been able to.

There were tasks that should have been handled by software that remained manual. Documents with bills of sales, commercial invoices, packing lists, government certifications had to be copied, collated and sorted. Even though we had received and created most of these documents digitally, we would put them through a scanner again to notify branches and partners they were complete and on the way. Some partners required us to fax the documents which meant standing over a fax machine for half an hour slowly feeding document. Better software and a good copier that collated and stapled could have done almost all of this and knowing that was driving me crazy.

Why couldn’t the engineers made this a little better? Why did that new feature that was released require us to go to a new page and enter the same set of addresses we’d already entered three times? Why couldn’t the features that didn’t work be removed from the menus? Why did the software seemed so disconnected from what we actually needed to do get a shipment out the door? Why did that feature that allowed customers to enter information require us to do so much cleaning up? The answer I came to made me more depressed.

It was internal business software. There was no competition. If an engineer was asked by management to develop a feature the internal user’s experience was not important. That user didn’t have a choice. The customers were upper management and upper management didn’t use the software so user experience could be overlooked without repercussions.

I’d hear co-workers curse over the software, miserably reenter a set of documents after a crash. Cover their fingers in whiteout while fixing docs in a typewriter because the software wasn’t up to the task. Sit at a fax machine for an hour faxing the set of documents that had been received electronically and printed out. Working forty plus hours a week with poor software can make you feel miserable for seemingly no reason. Poor tools made you feel less valued as an employee. It was awful to be aware that some poor engineering and management decisions was making a job that you so wanted to love miserable. Repetitive work is not terrible in itself, I’ve always enjoyed work even if it isn’t exciting but repetitive work you know to be redundant can make you feel like you’re wasting your life.

I’m not going to say this is the only reason I switched to software but it is a big part of it. I didn’t want to be the one suffering from bad software, I wanted to be the one fixing it. I wanted to be there to remind other engineers that taking shortcuts can have downstream human consequences. A lazy decision could make downstream users feel miserable for their forty hours a week.

You might be asking. What does this have to do with unit tests? I think testing is strongly tied with caring about what you do. Good tests are strongly tied to user and customer needs. Those customers may be other devs or internal users. If you’re writing valuable tests, they’re valuable to the company or valuable to well-being of users. If you want to write tests that are valuable to the company and the user, empathy and understanding how your code will be used is important.

You should also be able to know when you’re writing a tests that no one else will ever use and is for your own gratification. You should know if things are tested by other means.

This series isn’t about classical unit tests. This is about testing, quality, value, the reality of compromise and getting code out the door. I want to help people make practical decisions on testing. It’s difficult to be a testing aficionado in a culture that doesn’t support it. It can be difficult to reconcile what the academics point to as the best way to test and what your organization is actually doing. By the end of this, I’d like you to have a feeling of how to start making incremental changes to get to the academic model of good tests or be enthusiastic about leaning into what your organization is already doing. Understanding what’s already being done is key to knowing what you need to or don’t need to do.

This is to help you remain passionate about testing and recognize positive things your organization is already doing. Hopefully while maintaining an objective understanding of things that can be changed. I’ll go over some forms of testing and why they’re not all bad.