Most universities fail to teach the importance of testing software, so when students graduate and get a job, they hardly know anything about testing.
I know because I was one of them.
In fact, from the time I started learning to code back in middle school to the start of my first full-time job, I knew absolutely nothing about testing. I'd seen it mentioned in some IDEs, but that was my only exposure.
When features randomly broke in my personal projects, I just figured it was just the nature of software. Changes cause bugs, so you've got to manually test your product and fix it.
My first job quickly taught me that you don't have a prayer's chance for the stability of a large project if you don't write tests.
If you're not testing your software it's probably because...
- You don't know how to test.
- You hate writing tests.
- You don't think your project needs tests.
- Your project has never been tested, and it's difficult to add tests retroactively.
...but whatever your reason is, you really should invest the time in testing it.
Reasons Why to Test
Testing gives you incredible peace of mind (and job security).
I spent my first year at 128 Technology on the two person Python team. We had the smallest team, but the largest number of tests of anyone in our entire codebase. Guess how often a critical bug was our fault?
If you write tests, you'll save your ass later down the line when things are bound to go wrong. It's better to take 30 minutes to unit test your code rather than full responsiblity for a regression that just lost a customer.
Testing is an investment. It may take you 10x longer to write test code than to write the code itself, but for the continual peace of mind that it brings, it's completely worth it.
You find flaws in your approach or your code immediately.
How many times have you written a module only to find that you omitted a painfully obvious chunk of code that's crucial to the task you're trying to accomplish? How many times have you written something stupid because your mind was somewhere else?
If you test something while you're writing it or immediately after writing it, you'll find flaws in your thought process right away. There are days as an engineer when you're not on your "A game", and you don't realize it. Until you start testing.
Testing grants peace of mind that your contribution is functional and makes sense, which is especially important if you're not the one using the code you're writing.
Code that is easily testable is usually well-designed.
Hard-to-test code usually indicates a design flaw or an anti-pattern in a module. For example:
- Modules with gigantic functions are difficult to test because functions are performing their sub-operations inline. Split the code into multiple functions.
- Tightly coupled modules are difficult to test. Consider a different design pattern to eliminate dependencies.
- In Model-View Controller-based UI applications, it's difficult to test model code placed within the controller. Fix the areas where the design pattern is broken.
If you're consistent about testing your code as you submit it, your project will retain its good design.
Complex projects will be aggravating at best and a failure at worst.
If you're building something with tons of moving parts, how can you ensure that a seemingly harmless change doesn't break another feature of your project?
If you have no test coverage, you have to build it, manually test as much functionality as you can, and hope that everything still works. Not a great iteration strategy. Definitely not Agile Development.
Worse, if your colossal project is full of questionable design patterns and lacks test coverage, you can never afford to make small changes, let alone overhaul anything. You may as well start over for the high costs involved with maintaining the software.
Developers are more likely to use an open-source library if it's fully tested.
If I were writing commercial software, I wouldn't even consider using an open source component that didn't have test coverage. Relying on it too would be too much of a risk.
How to Make Yourself Like Testing
My first assignment at work was to write a complete set of unit tests for five Python modules that I didn't write. It sucked.
It took a long time just to figure out what was going on, especially since I had no knowledge of testing frameworks or the product itself.
When I started adding features to 128T, I had a mentor who forced me to write unit tests for every single change I submitted to the project. If we didn't have a way to test some aspect of our code, we had the come up with a solution before submitting the actual change.
Nobody hated testing more than I did. I liked being a speed demon at everything, and writing tests killed the speed of my workflow. But I had no choice.
It took me months to wrap my head around and get good at mocks, fakes, and fixtures, but, after that, I loved testing. I got fast at it too.
It takes dedication to get to that point, but the work is never in vain. I've written an incredible amount of painfully boring unit tests, but it made me a better developer. And guess how few times people came back to me and that feature didn't work?
**Better love-life not actually guaranteed.