You too can Enjoy Writing Tests for Your Apps!

Spend any amount of time with software developers online or offline, and at some point someone is likely going to start talking about how important it is to write tests. You will hear people talk about how it is important to reach metrics like a 100% test coverage and you might even start to feel a bit inadequate for how you write code; Did you just write a function without first writing a bunch of failing unit tests for it? A cardinal sin if you listen to Test-Driven-Development missionaries.

Strategies like enforcing test coverage or Test-Driven-Development can work well for larger teams with sufficient time and financial budgets, but they fall apart in the fast-moving environment of smaller, more dynamic projects. When it comes to the teams that I have worked with in my career so far, I have seen very few people actually write tests for their code and even fewer seemed to have a real strategy for when to write them. I can only speculate about how many single developers write tests for their apps, but I suspect the number is shockingly low.

I learned how to write tests way too late in my life, but when I did, I felt how they gave me a sense of security and made me sleep better, how they made me think about my software's architecture in a new way and how they helped me write more maintainable code. All this, however, still didn't get me to test regularly.

That is because, to write tests reliably and reap all their benefits, developers don't just need to know how to test, but also when to test.

You hear that you should reach a certain test coverage, or write tests before every bit of code that you write, but when you realise that this approach is not feasible for your project, you are suddenly back in the wild west, where you don't have any rules or structure for what to test and when to do it. And in the absence of clear guidelines, people often revert to the easiest solution, which is writing no tests at all. Luckily, I found a simple shift in perspective could help me make sense of it all. Not only are you going to find yourself writing more tests, through small, cumulative change you are going to end up with a more robust codebase. I am even going to go out there and say that you are going to have some fun while doing it.

Use Tests to Try Out Your Code.

Don't be fooled by how obvious this sounds. During the same years I resisted writing tests because it felt too cumbersome, I still put dummy buttons in my UI to call functions with dummy parameters, just to see if they do what they should all. the. time.

Let's think about this for a second, because I bet most of you have had this experience. You just wrote some nice business logic, maybe an API call or two somewhere, and of course you want to try out if it works. But you don't have any way to interact with this code yet, so to verify that it does its thing, you would need to wait until everything is hooked up to UI. Lots of times, this is what I did, and by that time I had forgotten half of the cases I wanted to test, and if something went wrong it there were already ten different places it could've happened in.

To mitigate that, I often did what many developers do. I just hooked up my code to some random button, to call it with some made up dummy arguments. A couple prints here, a breakpoint there, just to verify the output was what I wanted, and I was satisfied. Time to undo everything again, and hope that I don't forget to clean up behind me.

What I described just now is basically writing a test, but I'm the manual test runner! Writing a unit test would've accomplished the same, but repeatable, automatic, and future-proof. This gives rise to a simple strategy.

This also includes times when you receive a bug report and you're trying to reproduce the error. If you manage to write a failing test, you'll make your life so much easier And believe me, if you're scared that writing the test would've been more effort, a little bit of learning will take you a huge way

I've seen people try out their business logic by hand so much, that I believe it is a deeply engrained habit for many, if not most developers like it was for me. And who can blame us? By the time I finished my Bachelor's, I had written multiple apps for uni. Someone had to test all of this code? Nobody told me I could let the computer do it for me, much less how to do it. But once this framework clicked for me, I started enjoying the satisfaction so much, that some of my side project even sport the mythical 100% coverage now. And I have to admit, that does feel pretty great, so maybe they weren't all wrong after all.

Of course, the tests you wrote are only going to unfold their full potential once you have a set-up that runs them against your codebase regularly. In other words, you will want at least a simple DevOps setup. If you don't have that yet, and you're curious about how to set it up for GitHub, consider checking out our Flutter CI Tour.