# Importing tests from unknown languages **URL:** \ **Category:** SonarQube Server / Community Build\ **Tags:** coverage\ **Created:** [January 30, 2023, 6:32pm UTC](https://community.sonarsource.com/t/importing-tests-from-unknown-languages/82727 "2023-01-30T18:32:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![drjonnicholson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/drjonnicholson/32/36642_2.png) [@drjonnicholson](https://community.sonarsource.com/u/drjonnicholson)\ **Post date:** [January 30, 2023, 6:32pm UTC](https://community.sonarsource.com/t/importing-tests-from-unknown-languages/82727/1 "2023-01-30T18:32:22Z")
SonarQube Enterprise 9.8.0.63668 I’m trying to import test results for a language that SonarQube doesn’t yet understand (GoSu). I’ve got some external issues logged using generic issue data (working), and code coverage in Jacoco format (working). However, when I try to import generic test data the debug output shows something like this: ```auto 17:44:19.853 DEBUG: Skipping file 'C:\dev\path\to\a\FileTest.gs' in the generic test execution report because it doesn't have a known language ``` This is frustrating because both external issues and coverage work fine without SonarQube having to know what a “\*.gs” file is. The root cause of the message appears to be [sonarqube/GenericTestExecutionReportParser.java at master · SonarSource/sonarqube (github.com)](https://github.com/SonarSource/sonarqube/blob/master/sonar-scanner-engine/src/main/java/org/sonar/scanner/genericcoverage/GenericTestExecutionReportParser.java#L117). As far as I can see there does not appear to be any way to override this behaviour without creating a plugin for the language (why not?). Having to create a plugin just to import generic test data involves a _lot_ of overhead ([Supporting new languages (sonarqube.org)](https://docs.sonarqube.org/latest/extension-guide/developing-a-plugin/supporting-new-languages/)) for something that would appear to be quite simple. And since the test output is visible on our build pipeline there will be strong resistance to committing company resources to building and maintaining it. If there are currently no plans to be able to relax this setting, preferably on a per project bases (I’ve seen other people ask for this, e.g. [GenericTestExecutionReport: Limited to known languages? - SonarQube - Sonar Community (sonarsource.com)](https://community.sonarsource.com/t/generictestexecutionreport-limited-to-known-languages/5785/18)), and without using a horrible hack… then what is the absolute minimum that needs to be in a plugin to tell SonarQube that \*.gs, \*.gsx, etc are GoSu files so I can get my unit tests, coverage and issues all in one place? ---
**Author:** ![ganncamp](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/ganncamp/32/1261_2.png) [@ganncamp](https://community.sonarsource.com/u/ganncamp)\ **Post date:** [January 31, 2023, 5:43pm UTC](https://community.sonarsource.com/t/importing-tests-from-unknown-languages/82727/2 "2023-01-31T17:43:25Z")
Hi, I understand your frustration. On the face of it, this seems simple, so I’ve spent some time over the years (yes, it’s been years) contemplating why we don’t just handle it. I believe this probably has to do with the larger metrics interdependency web. Consider that Coverage % [is](https://docs.sonarqube.org/latest/user-guide/metric-definitions/#tests): `(conditions-evaluated-true + conditions-evaluated-false + line-coverage) / (2*condition-count + lines-to-cover)` _Almost_ everything in that formula can be derived directly from your coverage report. _But_ (cue ominous music) you still need `lines-to-cover`. And that comes from the size-related metrics that would be provided by a plugin (or native support). So without metrics support, more than half of the coverage measures are incalculable: ![Selection_745](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/c/0/c0926efbee1c144ebe3ec9cf177508a5721b20a9.png) “But you should just use the line counts from the coverage report!” I hear you saying. We used to. It led to inaccuracies. [So we quit](https://www.sonarsource.com/blog/executable_lines/). > [@drjonnicholson](#): > > then what is the absolute minimum that needs to be in a plugin to tell SonarQube that \*.gs, \*.gsx, etc are GoSu files so I can get my unit tests, coverage and issues all in one place? You’re going to need to provide size metrics. I’m not qualified to call out the specific metrics you need and the ones you can ignore. Admission to the Marketplace [requires](https://community.sonarsource.com/t/deploying-to-the-marketplace/35236#) NCLOC & NCLOC\_DATA, although I’m not certain that’s a) relevant to your question b) the minimum to get what you want. You probably need to provide executable lines data. Potentially more. Hopefully this helps. Please do feel free to create new threads with specific development questions.   Ann ---
**Author:** ![drjonnicholson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/drjonnicholson/32/36642_2.png) [@drjonnicholson](https://community.sonarsource.com/u/drjonnicholson)\ **Post date:** [February 6, 2023, 6:44pm UTC](https://community.sonarsource.com/t/importing-tests-from-unknown-languages/82727/3 "2023-02-06T18:44:31Z")
Hi Ann, thanks for the comprehensive response, super useful. The hack I found was to force SonarQube to treat the Gosu files as the “text” type (with something like `sonar.lang.patterns.text=**/*.gs,.....`), but noticed that it heavily underestimated the coverage. From your post that makes sense, as I’d assume that language of course treats all lines as lines to cover even it they’re empty, comments, package imports, etc… Not an approach I’ll be progressing - inaccurate metrics are worse than no metrics. Looks like it’s build or buy.