Month: September 2020

First Real Software Testing Experience

In the spring of 2020, I participated in a graduate software engineering course focused on the software principles of modularity. We read many canonical articles and put their messages into practice by refactoring an Android mobile game. My team and I implemented very few automated tests in our test suite, mostly because we spent so much time attempting to refactor the system. But when we did make tests, they became outdated in a week’s time because of how rapidly we were making changes.

This summer, I set my sights on building a website for Toastmasters International using Python and Django. The tutorial I used to learn Django was Vitor Freitas’s. Vitor’s dedication to sharing knowledge with others is astounding and his Django tutorial is phenomenal. What surprised me most throughout the course was his emphasis on testing. Looking back, the tutorial was as much an intro to software testing as it was an intro to Django.

Once my project diverted from the tutorial material, most of my testing involved copying and pasting test classes to fit all my new views. Later, I learned that I could test whole models. And I was most proud of how I tested user permissions for some of the views.

Though there wasn’t much to my test suites, I had gotten far enough along to develop an eye for what could be improved in my system:

First, I was repeating myself a lot! I’m sure the Don’t Repeat Yourself (DRY) principle also applies to test suites. I attempted to utilize the “setup” method of the Django TestCase class as best I could, and even used some inheritance to make the concrete test classes less repetitive. Still, I couldn’t shake the feeling that there wasn’t an “authoritative and unambiguous representation” [1] for components of my test suite. The finest example was user permission tests. Instead of directly testing the mixins that I created by inheriting from UserPassesTestMixin, I repeatedly tested the views that used these permission mixins.

Second, the dependency chains created by my models made it more complex to test individual components. If every Club could have Meetings, and Meetings could have Performances, and Performances could have Evaluations, then I was creating Clubs, Meetings, and Performances simply to test the Evaluation components of my system. Surely, this problem lies in a failure of mine to properly include abstractions between my components and utilize Dependency Inversion. [2]

As my first real experience in software testing, the following are just a few of my big takeaways for why I’ll be taking testing more seriously in my projects from now on.

  1. I was much more confident to make changes when I knew I had tests backing me up. With each added test, I was less worried about making mistakes because my failed test cases were my safety harness and light in my tunnel.
  2. While learning C++, I remember relying on the compiler to be my test suite. This Django project has really taught me that you can’t rely on the compiler errors to know you’ve done something wrong. The Django template language and many components within Django rely on strings. On several occasions I had features that simply weren’t working and couldn’t believe that uninstantiated variables in these string types didn’t throw helpful errors. All the more reason for better test suites.
  3. I even got into the habit of using test cases that always failed as a reminder that I hadn’t yet implemented a certain feature. With tons of links on each webpage, it was incredibly easy to forget a hyperlink here and there. Testing then became a habit that was more congruent with the David Allen “Getting Things Done” mindset I’ve been trying to develop. I let my testing suite be my reminder of unfinished tasks so I could free up space in my head for the task at hand.

You can find more info about my Toastmasters Feedback project here.

References:

  1. Orthogonality and the DRY Principle, A Conversation with Andy Hunt and Dave Thomas, Part II by Bill Venners, March 2003.
  2. Robert C. Martin, “The Dependency Inversion Principle”, C++ Report, May 1996.

Manifesting change with pen and paper

An important reason why I started this blog was to present myself to future employers as a responsible authority. I fear part of this post could serve to cast doubt on my character and abilities. Regardless of perception, I would rather share a genuine experience of progress than portray a false identity.

A few weeks ago, I realized I was neglecting some of my responsibilities. Long term projects weren’t being chipped away at, and small tasks were slipping through the cracks. My mind was a terrible reminder system, and the weight of my failure to act loomed large in my psyche. I returned to David Allen’s book, “Getting Things Done“, and started practicing a simplified version for myself.

I dumped every responsibility, large and small, out of my head and spewed them onto a Word document. This was as cathartic as a solid six-mile run. The pressure in my head was relieved and I could breathe again.

In the process of creating my Next-Action List out of the items in my In-Basket, I found myself seriously doubting that some items were ever going to get done. These weren’t large daunting projects either. They were simple tasks that my mind grew to associate with pain and friction. The fact that I had repressed them for so long, made them all the more difficult to perform moving forward.

Less than a week of practicing this system though, writing down my tasks and dedicating time to them each day, I began completing the very tasks that had seemed unrealizable just a few days prior.

My epiphany: whatever I write down on paper, I can accomplish.  Given enough time and effort, I have the capacity to manifest any change in the world I seek to make.

This is a lesson I should have learned many years ago. It’s also an idea several thousand years in the making:

For assuredly, I say to you, whoever says to this mountain, ‘Be removed and be cast into the sea,’ and does not doubt in his heart, but believes that those things he says will be done, he will have whatever he says. Therefore, I say to you, whatever things you ask when you pray, believe that you receive them, and you will have them.

(Mark 11:23-24, New King James Version)

After more than a year of avoiding my blog, I wrote down that I would turn this experience into a shareable message. I completed it within three days.