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.
- 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.
- 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.
- 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:
- Orthogonality and the DRY Principle, A Conversation with Andy Hunt and Dave Thomas, Part II by Bill Venners, March 2003.
- Robert C. Martin, “The Dependency Inversion Principle”, C++ Report, May 1996.