# Increasing test coverage with Antigravity & Gemini AI tooling is resulting in a lot of code being written and you can also use it to write and expand test coverage. A few years ago, I wrote [MetaRefCard](http://github.com/ankurkotwal/metarefcard), an app to help me map the complex controls of flight simulators like Elite Dangerous, Star Wars Squadrons and Microsoft Flight Simulator for my HOTAS (hands on throttle and stick) setup. ![](https://cloudmate-test.s3.us-east-1.amazonaws.com/uploads/covers/698d4c787a62b51e1541edd2/b33ef70d-bad9-48a0-a40b-39ff12ea8906.jpg align="center") Over the years, I’ve maintained the codebase, mostly to update my dependencies in response to CVEs. I’ve recently been making these security changes using [Antigravity](https://antigravity.google/) and Gemini 3 Pro. I would manually test all these changes between releases. ## Antigravity with Gemini gets you started quickly MetaRefCard is written in Go which has excellent tooling for building & running tests. Antigravity and Gemini are able to utilise them very well. To start, I asked Antigravity to build out a comprehensive set of tests. The result was a decent number of unit tests but I couldn't judge how comprehensive it was. Go’s testing framework can actually provide this data. ![](https://cloudmate-test.s3.us-east-1.amazonaws.com/uploads/covers/698d4c787a62b51e1541edd2/5bf76739-284a-4ca2-b5d1-ad340047606a.png align="center") It’s easy to generate the output yourself. ```plaintext ankur@:~/devel/metarefcard$ go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out ok metarefcard 29.241s coverage: 0.0% of statements ok metarefcard/mrc 0.584s coverage: 0.0% of statements ok metarefcard/mrc/common 0.003s coverage: 1.3% of statements ok metarefcard/mrc/fs2020 0.004s coverage: 60.9% of statements ok metarefcard/mrc/sws 0.011s coverage: 77.3% of statements main.go:13: main 0.0% main.go:22: parseCliArgs 0.0% mrc/common/devices.go:4: LoadDevicesInfo 0.0% mrc/common/game.go:40: TitleCaser 0.0% mrc/common/game.go:86: GameBindsAsString 0.0% mrc/common/game.go:114: Keys 0.0% mrc/common/image.go:17: GenerateImages 0.0% mrc/common/image.go:69: prepImgGenData 0.0% mrc/common/image.go:91: populateImage 0.0% mrc/common/image.go:177: decodeJpg 0.0% mrc/common/image.go:194: measureString 0.0% mrc/common/image.go:201: calcFontSize 0.0% mrc/common/image.go:250: prepareContexts 0.0% mrc/common/image.go:261: getPixelMultiplier 0.0% mrc/common/image.go:269: drawTextWithBackgroundRec 0.0% mrc/common/image.go:289: addImageHeader 0.0% mrc/common/image.go:315: addMRCLogo 0.0% mrc/common/logger.go:12: Dbg 0.0% mrc/common/logger.go:17: Msg 0.0% mrc/common/logger.go:24: Err 0.0% mrc/common/logger.go:31: Fatal 0.0% mrc/common/logger.go:36: NewLog 0.0% mrc/common/model.go:10: LoadGameModel 0.0% mrc/common/model.go:17: FilterDevices 0.0% mrc/common/model.go:40: GenerateContextColours 0.0% mrc/common/model.go:66: PopulateImageOverlays 0.0% mrc/common/model.go:115: GenerateImageOverlays 0.0% mrc/common/util.go:18: Keys 100.0% mrc/common/util.go:27: LoadYaml 0.0% mrc/common/util.go:43: YamlObjectAsString 0.0% mrc/common/util.go:55: loadFont 0.0% mrc/common/util.go:79: loadFont 0.0% mrc/fs2020/fs2020.go:31: GetGameInfo 0.0% mrc/fs2020/fs2020.go:36: handleRequest 0.0% mrc/fs2020/fs2020.go:54: loadInputFiles 79.6% mrc/fs2020/fs2020.go:234: matchGameInputToModel 0.0% mrc/fs2020/fs2020.go:262: matchGameInputToModelByRegex 43.6% mrc/metarefcard.go:36: GetServer 0.0% mrc/metarefcard.go:94: loadLocalFiles 0.0% mrc/metarefcard.go:106: loadFormFiles 0.0% mrc/metarefcard.go:131: sendResponse 0.0% mrc/metarefcard.go:195: String 0.0% mrc/metarefcard.go:200: Set 0.0% mrc/metarefcard.go:206: GetFilesFromDir 0.0% mrc/sws/sws.go:31: GetGameInfo 0.0% mrc/sws/sws.go:36: handleRequest 0.0% mrc/sws/sws.go:52: loadInputFiles 86.5% mrc/sws/sws.go:181: addAction 100.0% mrc/sws/sws.go:207: getInputTypeAsField 85.7% mrc/sws/sws.go:227: interpretInput 66.7% mrc/sws/sws.go:302: matchGameInputToModel 0.0% total: (statements) 29% ``` The initial test coverage wasn’t great at 29% but it was clear which files and functions had less coverage. ## Guiding the model to expand coverage One of the nice things about Go’s testing coverage report is that it can tell you test coverage per function. This way, I could see where my testing gaps were. I started asking Antigravity to increase coverage overall and when that had diminishing returns, I asked to increase coverage of specific functions. ![](https://cloudmate-test.s3.us-east-1.amazonaws.com/uploads/covers/698d4c787a62b51e1541edd2/390971f5-a39e-42c2-9fa1-bc80a0811080.png align="center") I had to guide the process much more and ask questions about why it couldn’t go higher. This is a modern way of agentic engineering where my focus wasn’t on each line of code but instead it was about guiding the outcome. ## Completing test coverage Using this technique, I spent the next couple of hours having Antigravity eventually get my test coverage to **99.7%**, with the only code not covered by unit tests being the main function. Again, this required back and forth with the tool. ![](https://cloudmate-test.s3.us-east-1.amazonaws.com/uploads/covers/698d4c787a62b51e1541edd2/8e06d808-85ed-4b71-8f1c-4aa85b1a27cf.png align="center") I’m really satisfied with where I ended up. In a few hours, I had a very comprehensive test suite and felt a lot more confident to automatically make changes in the future. If you’ve got a codebase that could do with additional test coverage, it’s easy to get started with [Antigravity](http://antigravity.google).