An automated test suite with 100% code coverage is the goal…

… but what if you haven’t had time and let the technical debt build up?

Francis Hart
Only The Paranoid Apps Survive
5 min readJul 29, 2016

--

As a developer, there is no doubt that you’ve heard the terms Test Driven Development (TDD), Behaviour Driven Development (BDD), Technical Debt and the many others out there. You can read books, posts, watch videos and learn from tutorials about it, but there has probably been a time when you’ve entered a project with little to no automated tests.

There may be a thousand reasons why your current test suite may be lacking, it could even be that you inherited the project in this state. Whatever the reason is, I want to list the steps we took to improve our suite and where we aim to be in the future.

At MobileCaddy, we have a saying that Only the Paranoid Apps Survive. We help clients and developers achieve paranoid apps by taking some of that responsibility from them in the form of the MobileCaddy API. However, we also need to make sure that our own code meets these standards and that our tests and us as developers are just as paranoid.

It takes discipline

That might mean having to enforce the rules via CI, Notifications, pre-commit Git hooks… Photo Credit: Qusai Akoud be.net/qusaiportfolio

It’s easy to get carried away with creating feature after feature, aiming to hit the MVP and deadlines, but ignoring your tests and architecture incurs technical debt over time. And by incurring this debt, you are sure to feel it in the future.

From this point on, begin practicing writing tests for everything you commit. This stops any more technical debt from building up on your project. Let your team know you want the code coverage percentage to decrease on each commit (or at least not increase any further).

Setup CI. These days it is likely that setting up CI for your project only takes a couple of clicks. There are many great tools out there to get started. My favourites are CircleCI and Bitbucket Pipelines (in beta at time of writing). Get your tests running on each commit and reporting the results of both the results and coverage. It’s a lot easier to fix the issue when you can visualise the problem in the first place.

Follow the Boy Scout Rule and leave the codebase cleaner than how you found it. Even if it means decreasing the lines of missed code coverage by 1, it is still a step in the right direction.

Schedule a dedicated time to write tests. If you are really behind, get the team together and spend time improving your tests. That way everyone is on the same wavelength and it is much easier to help each other when working on complex test sets.

Code Reviews. This one is a lot harder to get into the habbit of doing, but the payoff could be immense. You probably work with a team that has a diverse background, maybe some from large enterprises to new graduates. A second pair of eyes means your code is getting reviewed from a different perspective. Maybe your reviewer has 20+ years of experience more than you which is great and will hopefully show you where to improve, but the opposite is just at crucial. It could be that your just-graduated new hire is reviewing your code, in which case they are learning just as much from you by reading your code. You then are beginning to upskill your team, increase code visibility and tend towards the same wavelengths.

All of these take discipline to follow but you’ll get to some great benefits…

Code confidence lets you run faster

With improved tests comes confidence in your code. And with code confidence comes the ability to iterate, fix, and experiment a lot faster. You need to have confidence that your change isn’t going to knock out the other half of the system. This does rely heavily on the quality of your tests so it’s not something you’ll achieve overnight.

Until then, everytime you find a bug that wasn’t caught by your tests, don’t just fix the bug, write tests that will capture the bahaviour of that bug. Not just tests to test the funcionality of your fix.

Give youself a headstart

It may sound daunting, but there are ways to give youself a headstart.

Our MobileCaddy template projects come configured for testing, ready to run out of the box. If you have templates that you regularly start new projects from then get your foundations solid ready for the next project.

To get the tests for these templates running in Bitbucket Pipelines is super easy too! Just install Pipelines for your team. A few configuration changes and a file specifying what Docker image to run and how to run the tests and you are done! In 5 minutes from cloning the template you can have CI with automated tests and code coverage running.

You can even add in your own hooks and configurations to post the results of the test and coverage reporting to other services such as Slack.

Keeping up motivation

Even if you implemented all of the above, there is still a danger to slip back into old ways and slowly watch that code coverage percentage drop. Especially when you have hotfixes coming in, little “tweaks” that you don’t think needs coverage, or even just time pressures of moving onto the next feature.

Slack can be a useful way to keep visibility on all of your repos each time a test is ran.

You can keep up to date on the current state of your project by creating a Slack channel dedicated to the output of your CI. Anyone subscribed can then see when it gets broken and it helps reduce any broken tests and bugs from sneaking under the radar. (Also a bit of banter when someone breaks it!)

Add status badges onto your repo page. These badges can display code coverage and the build status of the repo. Handy for getting instant visibility on the status of the repo if you haven’t touched it in a while.

Finally, you could schedule recurring reviews of your projects. This gives everyone a chance to keep on the current state of the project landscape on their radar, and the chance to see which projects may need a little more attention.

For more information about MobileCaddy and how the MobileCaddy platform can take your business mobile with Salesforce, visit mobilecaddy.net

You can find our project templates on Github, and documentation on setting up Bitbucket Pipelines here.

For more content on mobile app development, download our free eBook with 15 tips for success with mobile apps.

Francis Hart is a Software Engineer at MobileCaddy and works with the native iOS and Android layers of the MobileCaddy platform.

--

--