Companies often know they should be writing automated tests but “don’t have the time”. As a result, they may pay an outside agency to write their automated tests for them or assign it to a QA team. This situation is far from ideal: Developers should be writing the automated tests for their code. An outside agency or QA team can be used to write more functional, higher level tests as a safety net to that. I really believe this is the only correct way to do it. But, if you insist on having an outside agency or QA do it, here are some important dos and don’ts:
It is my firm belief that you can be risk averse while constantly improving. I worked with someone a long time ago who said that they were “risk averse”. What this meant is they didn’t like the way that I would refactor code I had to maintain (after I put it under automated tests). They pushed back on my suggestions to improve deploy times because it would require changing things that “already worked”. These deploy times were taking up to thirty minutes and sometimes occurred multiple times a day. That got me thinking, “are you risk averse, or are you improvement averse?” Continue reading
I’ve consulted for a company in the past that had a continuous integration server set up correctly and building their project, but they made the mistake of having their developers decide when to start the build process. This misses the whole point. It’s called “continuous” integration, not “developer-decides-when” integration. Your continuous integration server should build your project and run its tests whenever a change has been made and as soon as possible. The benefit to this is faster feedback.
If a code base is well tested and very stable, it’s pretty easy to write more tests for it. But, how do you get started writing automated tests if your legacy application has none? It’s very difficult to get started because the code wasn’t written with tests in mind. Normally, the endeavor will have you pulling your hair out. This is unfortunate because a lot of untested code desperately needs tests, yet it takes an inordinate amount of effort to write them. In this article, I’m going to tell you about a tool that you probably haven’t heard of that can help you get that legacy code base tested. It’s called Approval Tests, and here’s how it works: Continue reading
I was working on some legacy code (“legacy” meaning it has no automated test coverage) and I really wanted to write some automated acceptance tests for it. The problem is, I could not think of a way to do that without refactoring the code first. I did not want to do this because “it was already working” and the refactoring could have introduced new bugs. I had a chicken and egg problem: I didn’t want to modify code until I had automated tests but I had to modify code to write the automated tests. Which comes first?
I ended up using a trick that minimally changes the production code, actually improves the production code base, and allows me to write automated tests. It’s these two simple steps: