Code quality: automated testing helped uncover broken software
(Dev Talk: Python and Code Quality comes from an interview Royce Hall with Level 12 developer Matthias Hager . You can hear the full interview below.)
Most of our projects here are green-field projects, meaning that we develop them from scratch ourselves; but, these last couple of opportunities that I've had were to go in and work in existing code bases. It has been very interesting or fun for me to see the different styles of code that other people are writing, and to come in and adapt our own style to them.One of the projects that I worked on was an existing code base built in-house by a development team. We came into it, it was a small project, to add a new feature to it, but their existing code base had very few tests written for it.
So our first step actually was to write tests for their existing code. And the reason we did that was so that when we build new features, we'll know if we're breaking existing things because it'll have automated tests. Building the tests helped us test and improve the code quality. Now these are tests that are code-based tests that are testing the functionality of specific sections of code. We call them unit tests. And they help you guarantee that, when you give a input to a section of code, you'll get the same output that you expect every time that it runs with that input.What I was discovering as I was getting into their code base was that, because they lacked these test suites that automatically tested, there were actually things in there that were completely broken that they had never noticed.
There were bugs in there and sections of the code that weren't working as they expected them to, simply because they didn't have tests.It was a really good experience for me writing the test beforehand because, if I hadn't gone through and tested what they had in there, and seeing that those bugs existed, I would have come across them later when we were adding our own new features and it would have been a more difficult process to track them down. And to figure out if it was something that we were writing on top of it that was causing problems, or if it was the existing code that was causing problems.
So writing tests really helped us find those problems early and fix them before we went on to new development. This is part of what it means to have good code quality.Finding a broken test
There was one section of code in particular that stood out that was a function that's supposed to find a profile for a user if it exists or create it if it doesn't exist.
Our client is using a database layer there, a third party tool, to interface with the database. And they had not properly read the documentation for that database layer and the function they were using out of it returned a list of users whenever they searched for it, but when they were checking to see if it returned "empty", they weren't checking to find an empty list, they were checking to find a null value, which would never happen. It would always return an empty list if no users existed.
So their code to create a new user, if one doesn't exist, was just never ever going to run. For whatever reason, they never noticed this problem, or their existing use of the product didn't ever come across this but, with what we were adding on to it, we needed that to create a profile for users, and it would have caused a bug for us later if we hadn't caught it right then.
Tests to automate QA
Another client that we recently worked with is actually a development agency themselves, but they don't do a lot of testing in their work and, in lieu of testing, they have a rigid QA process. They have a dedicated person who goes in and runs through every issue and tests the spec manually against what should be happening there.
I really think this is a good process, and I think it's a good thing that they do it, but I don't think it's a one-to-one replacement for the automated testing that we do. Part of the reason for that is we're writing tests in the code to test the functionality of what's there. And so when we write that test once it's going to be able to run anytime we make a change, whereas with a QA person, anytime we make a change, they have to spend time to go run through their checklist of items for that.
They're spending more time on QA, where our tests are automatically running and are there permanently. They have to do it every time when they make a change.
Code Quality means tested, extensible, understandable
Automated tests are a big part of code quality, but there is more to quality than that. Quality code also means that it's easily extensible, meaning you can come in later and build on top of it if you need to, or change it without causing additional problems.
It can mean that it's easy to understand. So somebody coming in and looking at an existing codebase can get in there and figure out what's happening with minimal effort. It can also mean that there's not a lot of wasted space there.
The project that the agency was working on used a template system that they bought from a third party place to power their front-end. And instead of just picking out the pieces that they wanted to use from that enormous template system, they just plopped the whole thing in there. So now they've got this enormous codebase of stuff that they're not even using that is just making the whole thing sort of a sloppy mess, and it made it really difficult to get in there and figure out what's actually useful, what is actually being used, and what's just boilerplate that they popped in there.
Python Code Quality
In our shop, we choose Python because Python's easy to understand, easy to read. It's fairly straightforward to work with, test, and develop with.
I don't think that means that you cannot have bad code base or poor quality code with Python, but I think it definitely sets a good baseline there for quality code.
If you need help designing and building custom software, please contact us.
If you want to learn more about custom software projects we have undertaken, take a look at our projects page.