Strategies for Achieving Code Coverage in E2E Testing of IntelliJ IDEA Plugins

Answered

Hello JetBrains Community,

I'm currently developing an IntelliJ IDEA plugin and am looking into best practices for implementing end-to-end (e2e) testing with comprehensive code coverage. My goal is to ensure that the plugin's functionality is fully tested across its interaction with the IntelliJ IDEA environment, including UI components and API integrations.

Given the unique context of IntelliJ IDEA plugin development, I'm facing challenges in applying traditional Java code coverage tools, like JaCoCo, especially for capturing interactions within the IDE itself. I'm interested in any strategies, tools, or frameworks that might be suited for this purpose. Specifically, I'm looking for insights on:

  1. How to instrument plugin code for coverage analysis during e2e testing, considering the plugin's operational environment within IntelliJ IDEA.
  2. Any recommended practices for integrating coverage measurement tools with the plugin's build and test workflow.
  3. Experiences or case studies from others who have successfully implemented code coverage for their IntelliJ IDEA plugins' e2e tests.

I would greatly appreciate any advice, resources, or examples you could share on this topic. If there are existing discussions, documentation, or tools that address this challenge, I'd be eager to explore them.

Thank you in advance for your support and insights.

0
3 comments

Sorry for delay, answer is being prepared.

0

Hi Pilipenkomhl,

Please check GBrowser project; Jacoco has been configured there. The main idea is to apply Jacoco to the `runIdeForIdea` task and collect coverage from there, while UI tests just do their checks.

I've tested this solution in my simple project, and it works for me.

1

Thanks for your reply, I got the code coverage.

Only I had to add offline Jacoco code instrumentation, besides adding the Jacoco agent to the runIdeForUiTests task, otherwise, the interaction with the plugin was not captured in the report.

Also, it is necessary to pass classes from build/instrumented/instrumentedCode rather than from build/classes to the report parameters.

Offline instrumentation should be performed on build/instrumented/instrumentedCode classes.

And the code should be instrumented between instrumentedCode and instrumentedJar tasks.

0

Please sign in to leave a comment.