Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In this article, I share my experience of creating functional tests for a custom Gradle plugin and how to configure the plugin project to collect code coverage metrics from tests.
In the previous article, I described how to build a custom Gradle plugin. Here, we will continue to work with it. Before we start, I’d recommend recapping things in the previous article to get a better understanding of where we started.
Test metrics are essential in creating reports that accurately measure the success of your testing initiatives. With 23% or more of IT budgets being spent on testing, it is critical to know that your test suites are giving you what you think they are. Because of this, most companies have put some sort of test tracking in place, however, most companies struggle to find the right test metrics to ensure executive buy-in.
Before diving into what test metrics organizations should consider tracking to benchmark their testing efforts, it’s best to give thought to the overall test reporting strategy. Some basic questions to be answered should include:
Java code coverage tools, like these embedded in IDEs or provided as CI environments plugins, are great, but they have one limitation — the tests you run have to also be written in Java or other JVM language. What if you have suites of tests in other, non-JVM languages and would like to know what is covered and what is not?
I've faced such an issue — we had a really big suite of e2e REST API tests written in Python and executed them against big Java application running on Tomcat. We wanted to track where these tests go in the code. But how to check it?