Never automate anything bigger than your head: The cheaters way to get to 100% code coverage.

Never automate anything bigger than your head.

:Cheat your way to 100% code coverage.  

I have been thinking about code coverage lately. It’s a great idea to have 100% code coverage. But too many teams worry too much about it. There is an easy approach to getting good coverage. It’s not a good idea to push one part of the code to 100% coverage if other parts languish at zero. You don’t need fancy metrics to know if you have giant holes in your testing. So don’t get too caught up in code coverage unless you know your product will have solid coverage all around.

Make a pledge to have 100% code coverage on all your new code. Make a plan to clean up coverage on all the old code.

You might panic when you hear me say to figure out how to get to 100% code coverage. You want good coverage with as little coding time as possible. There is an easy “trick” to get high coverage scores. Simply drive coverage with unit tests.

Code coverage is one metric among many.

You should measure code coverage and strive for 100%. Just understand covering the code is just one slice of testing you need to do. API and scenario testing are just as important. You will have an easier time with those if you get your code coverage done first. Code coverage isn’t a magic bullet. Make sure you cover your other bases too. Measuring code coverage involves some overhead. I have seen teams get really hardcore about code coverage and then miss their goals or ignore other important testing.

Code with 100% coverage can still be terribly buggy.

The vast majority of bugs won’t be found just be hitting high code coverage. You might question if you should even bother with code coverage. In a good test approach, code coverage is a cornerstone to build your test effort on. In truncated test approach, it’s should be on the chopping block.

Getting good coverage with scenarios focuses on the wrong idea.

Testing approaches that start with automating scenarios are not ideal. Scenario focused tests suck at driving code coverage. Factor in trying to exercise the exception paths in your code. You can’t easily do that from the top level unless you glue in some test hooks that allow you to crash your own program. This approach is complicated and getting into the last 20% of the code will require a ton of effort. Measuring the code coverage of scenario tests misses the point. Focus on code coverage separately from scenario testing. Your scenario tests will be smoother if you nail the code coverage first and then focus the scenarios on what your customers really do.

Free yourself up to do interesting testing fast.

Using unit tests you can drive your code coverage up very fast. Once it’s in your target zone move on. Don’t bother with trying to get the code coverage for your scenario tests up very high. In fact don’t measuring it.

Unit tests are easy to get good code coverage.

Unit tests are close to the code.

You are also close enough to the code to understand it better and create cases to catch missing code easier. You are also in a great position to pick the methods that will cover the most code.

You can write negative cases that are impossible at other layers.

Remember that exception case you couldn’t drive from the UI? From the unit test level it’s really easy to invoke that exception path and make sure it’s handled.

They are among the fastest tests to author.

Using VSTS latest version or something other tools you can generate a lot unit test very quickly. They are very fast to run and validate. Use test driven development and start with the functional positive cases. Adding the rest of the cases to fill out code coverage is something you can complete quickly. Each test is short to write and validate and you can work on them whenever you have a slice of time.

Unit tests belong to the product.

No kind of testing I am aware has a bigger return on investment than unit tests. You can deliver them earlier than any other kind of test. Improve your product today with just less than an hour’s work. If you have a single method coded for your product, you can start writing unit tests right now.

Your customers don’t care who wrote it.

Don’t worry about who should write the unit tests. Many developers are addicted to test driven design and they always have unit tests. Other developers aren’t believers (yet) and they don’t get around writing any. Either way there are a lot of good tests for testers to write. Write them and deliver them back to the developers as soon as you can. Your customers will thank you.

Unit tests run fast and pay dividends for the lifetime of the product.

Since the tests are so close to the code they will last the lifetime of the product. No complex harness is needed. Build the code and run the unit tests.

Having 100% code coverage lets you fix more bugs.

One of the many benefits of a complete set of unit tests is the ability to repave the road. In every product you reach a point where bugs are too risky to fix. If you lack good unit tests this threshold comes all too soon. You can’t repave the road or make major performance improvements because of the risk to the rest of the product. If you have a healthy library of unit tests you can take these kinds of fixes later in your lifecycle. Not only that, but the developer can have a really good idea of how much work is left before they change is ready to be tested. This saves you entire test passes when there are changes. You can prove that new codes impact is isolated, or find out it touches everything.

Code coverage is a great tool and unit tests are the way to get high coverage.

Nothing will improve your product with less effort than driving unit tests to 100% code coverage. Don’t suffer an exploding test matrix but trying to drive code coverage from the scenario perspective.

Take an hour and bust out some unit tests. It's not really cheating, it's just so easy it feels like it.