Technical debt is an inevitable side effect of legacy code. Some code can (and should) be pruned, but institutional memory fades—what if there's a reason certain lines were included that may not be immediately obvious? Done right, unit tests can serve as documentation. Later on, these tests can illuminate what the developer was thinking when they created the code.
Code reviews are a popular method of catching bugs early in development through peer-reviewing someone’s code. But perhaps more important than catching bugs, these reviews also serve as a chance to see how something is built and have a conversation about it. Because testers question software differently from developers, it’s important that we participate in this knowledge-sharing practice.
We get it: Writing good, reusable, effective test scripts is hard. It consumes a lot of time and energy, and you have to learn too much about automated testing and test implementation. Just give up and produce some complicated, messy, and ineffective scripts! But why waste time figuring out how to do that on your own? Here are the best practices to ruin your BDD test scripts completely.
How many times does something seem too obvious to check? Most of the time this normal human response is a handy shortcut. Your brain tries to save you time—but you can’t always trust it. If your code malfunctions, each of those "too obvious to check" thoughts will bias your thinking about what caused the malfunction. We have to commit up front, before our thinking crystalizes, that the code will have to prove to us that it is correct.
You may feel you don't have time to write unit tests, but you really don't have time not to. Steve Poling makes the case that writing tests first not only will yield better code, but will help you get that code working right sooner. Here's how using a test-first approach changes your thinking about coding, lets you see mistakes immediately, and helps you create more testable code.
Writing changeable code makes it easier and more cost-effective to add features to existing software. Writing changeable code doesn’t take longer, but it does require paying attention to certain things when building a system. It's important to have a good suite of unit tests that support refactoring code when needed, and test-driven development helps you create independently testable code.
The ability to verify contracts either statically or dynamically, coupled with recent advances in proof technology, has opened up a new and promising approach to verification. Critical code can be proved with formal methods, and less critical code can be verified using traditional testing, with a clear separation at the interfaces between the two.
Code can express what we want to accomplish, but it’s a little more difficult to express why we’re doing something in the first place. The people who maintain code are often not those who originally wrote it, so documenting why helps set a context and gives clues as to what the author was thinking when they came up with a particular design, making developers' jobs easier.
In the “spirit” of Halloween, here are three scarily easy testing tips that will help you find defects in your software under test. These tips will help you easily test an app's power usage, search for a particular term in a dynamically generated URL, and verify a form's checkbox has a checkmark. After all, it’s our job as testers to make sure using our software is a treat, not a trick.
Just as you should not take out a financial loan without having a plan to pay it back, you should also have a plan when incurring technical debt. The most important thing is to have transparency—adequate tracking and visibility of the debt. Armed with the knowledge of these pending tasks, the team can devise a strategy for when and how to “pay off” technical debt.