Generic Test Data XML file Results not showing - Swift

SonarQube Cloud
, , ,
3

Hello @Mustafa_Yazgulu,

Welcome to the community, and well done for your first post. You upfront attached most of the useful information to troubleshoot your problem.

First thing I want to mention and that is unrelated to your problem: You can remove the sonar.swift.simulator property from your scan. It’s not needed nor used by the SonarQube Swift analyzer (it’s probably a left over from a 3rd party open source plugin :wink: )

About your problem now, the logs are demonstrating that your property is set correctly and found by the scanner, the file format seems OK too, but no coverage is extracted from it. See log below:

17:21:30.153 INFO: Parsing /Desktop/sonarqube-generic-coverage.xml
17:21:32.389 INFO: Imported coverage data for 0 files
17:21:32.389 INFO: Coverage data ignored for 979 unknown files, including:
/Pods/FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/AppLink/FBSDKAppLinkReturnToRefererView.m
/Sources/UI/Extensions/UIWindow+UI.swift
/Sources/UI/Scenes/Support/Conversation/ConversationShowing.swift
/Pods/FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/Internal/FBSDKInternalUtility.m
/Tests/NetworkingTests/Services/BaseServiceTests.swift
17:21:32.389 INFO: Sensor Generic Coverage Report (done) | time=2237ms

Why is that ? A common reason is that the filenames or exact file paths do not match between the files analyzed by the scanner and the files in the coverage report.

Indeed in your case there are some visible discrepancies:

  • All your scanned files have a relatively path starting by Sources/... or Tests/...
  • In your coverage file not files have this path. The path seems to start 1 directory level below (eg Shared/...). I found 1 example of a file whose path “almost” but not “exactly” matches between the 2: AresApplication.swift
    – In the scanner logs the path is: Sources/Shared/AresApplication.swift
    – In the coverage report the path is: /Shared/AresApplication.swift

To confirm that this is the root cause, you may first manually patch the coverage file to add the Sources prefix to one files (AresApplication.swift is good, it has some coverage between lines 403 and 410), and analyze again with the patched coverage file. If the coverage is now properly reported for AresApplication.swift, the root cause is found and you can fix this on a large scale by changing the way you generate the file, to make sure the generated paths are correct: I think the problem lies in the directory from which you run the command to generate the coverage.