Nerd For Tech
Published in

Nerd For Tech

Flutter test coverage in Gitlab CI

Illustration of a clipboard of test results and the title Flutter test coverage in Gitlab CI

Showing test coverage and whether it is going up or down on a pull request can change whether or not coverage gets added by your team.

Visualizing and giving a feedback signal when test coverage changes encourage adding more tests.

In Gitlab, you can get the test coverage added like this:

Not only is the current test coverage shown, but you also get a red or green diff in percentage from the code being changed.

Add one line

Adding the test coverage to your pipeline job is only one line.

That is if you already have tests running and outputting coverage. If not, read on.

The regular expression here will be applied to each line of the output and match the coverage percentage and add it to the merge request. This regex specifically will match output from lcov which you can use to parse the flutter coverage report.

Adding test coverage to Flutter

The flutter test library comes with test coverage out of the box. Add the coverage parameter to your test run command:

You can also generate reports for the test coverage as to see where the missing coverage is. This is possible with lcov and genhtml.

I use a custom container that has lcov added to it, but you can just as easily install lcov on top of the more common containers by adding another line to your script. But very likely, your container already has lcov available.

A complete Gitlab CI job can look like this:

Why not GitHub

A few years back, GitHub had yet to add GitHub actions and Gitlab in comparison, came with a free GitHub CI tier to run your CI/CD.

Comparing it to GitHub actions now, the two are very like each other, and GitHub definitely makes for a good alternative to Gitlab.

Personally, I have begun moving some of my projects over to GitHub instead and for a full reference on how to do CI/CD for Flutter on GitHub actions, check out the TravelRates app repository.

GitHub has a similar way of displaying code coverage on pull requests:

Tests where worthwhile

Having tests can give you peace of mind that you haven’t broken anything unintentionally.

However, writing and maintaining tests can be difficult, so you should consider when it is worth it.

My flutter projects have coverage of about 65%.

I try to test most widgets in isolation to see if they can render, and then I use TDD to write out functionality for logical parts where the code transforms or calculates something. Where I can, I add integration tests to check that API parsing works fine as well.

Regardless, having that coverage percentage keeps me accountable and helps motivate me to keep that coverage from dropping too low.

Hope this helps.



NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
David Dikman

Full-stack developer and founder. Writing here and at Currently open for contract work.