Testing FAQ

See Introduction to Integration Tests for UI integration tests.

• ProjectViewTestUtil

• TestLookupElementPresentation

• IconTestUtil

• TreeTestUtil

• EdtTestUtil

tip

Configuring Test Frameworks (2024.2+)

All required test-framework dependencies must be declared explicitly.

Please see notes.

Always call super.tearDown() inside finally {..} block of your test class to avoid leaks and side effects from previously run (failed) tests:

protected void tearDown() throws Exception {
  try {
    // test specific tear down calls
  } catch (Exception e) {
    addSuppressedException(e);
  } finally {
    super.tearDown();
  }
}

override fun tearDown() {
  try {
    // test specific tear down calls
  } catch (e: Throwable) {
    addSuppressedException(e)
  } finally {
    super.tearDown()
  }
}

Avoid OS-specific assumptions (e.g., filesystem case-sensitivity, hardcoded separator instead of java.io.File.separator, default encoding, line endings).

Use ordered collections or UsefulTestCase.assertUnorderedCollection().

Code deferring execution (e.g., via Application.invokeLater()) might not run during test execution (and possibly fails in production, too). Use Application.invokeLater(runnable, myProject.getDisposed()).

When targeting 2024.2 or later, see also How to handle ProjectActivity? .

In some situations, added or changed files (e.g. XML DTDs provided by a plugin) are not refreshed in Virtual File System. In such cases, simply delete test-system/caches in your sandbox directory and try again.

Provide JVM system properties idea.log.debug.categories or idea.log.trace.categories to specify logger category name, respectively. Multiple categories can be set using a comma separated value list.

Sample Set DEBUG level for categories com.my.plugin.ui and com.my.plugin.backend:

tasks {
  test {
    systemProperty("idea.log.debug.categories", "com.my.plugin.ui,com.my.plugin.backend")
  }
}

test {
  systemProperty("idea.log.debug.categories", "com.my.plugin.ui,com.my.plugin.backend")
}

Set system property idea.split.test.logs to true to generate separate test log files in splitTestLogs subdirectory for failing tests (WARN/ERROR level messages).

Annotate with @TestOnly, usages will be highlighted via inspection JVM languages | Test-only usage in production code.

To mark members whose visibility is higher than necessary to be used from tests, use @VisibleForTesting

Use FileBasedTestCaseHelper, please see its Javadoc for instructions.

Use UsefulTestCase.getTestName() or create your own annotation(s) which can be checked via UsefulTestCase.annotatedWith().

Use PlatformTestUtil.startPerformanceTest() to assert machine-adjusted metrics.

Use PlatformTestUtil.dispatchAllInvocationEventsInIdeEventQueue().

Use DefaultLogger.disableStderrDumping() passing getTestRootDisposable().

Use ExternalResourceManagerExImpl.registerResourceTemporarily() passing getTestRootDisposable().

Provide dedicated test implementation via testServiceImplementation in service declaration, or use ServiceContainerUtil.

Use ExtensionTestUtil.

If possible, use How to wait for condition with timeout? approach. Otherwise, call com.intellij.util.TimeoutUtil.sleep().

Use WaitFor.

Plugins supporting a JVM language may require JDK and language standard library to be set up in a test project, so that classes like java.lang.String can be correctly resolved during tests. Tests extending LightJavaCodeInsightFixtureTestCase use one of the mock JDKs distributed with the IntelliJ Community project sources (notice java/mockJDK-$JAVA_VERSION$ directories). These JAR files are not available in plugin project dependencies, so the IntelliJ Community sources must be checked out to the machine running the tests, and sources' location must be provided to the test framework. It's done by setting the idea.home.path system property to the absolute path of the checked-out sources in the test task configuration:

test {
  systemProperty("idea.home.path", "/path/to/intellij-community-sources")
}

test {
  systemProperty "idea.home.path", "/path/to/intellij-community-sources"
}

The default JDK version used by the test framework depends on the target platform version and is the latest supported version. The easiest way to change the JDK version to a custom one is by overriding LightJavaCodeInsightFixtureTestCase.getProjectDescriptor() and using one of the predefined project descriptors in LightJavaCodeInsightFixtureTestCase. If a project descriptor requires more customizations, its getSdk() method can use one of the IdeaTestUtil.getMockJdk*() methods.

Sometimes, testing a JVM language requires adding standard or other libraries to a test project. If a required library is available in the Maven repository, use MavenDependencyUtil, e.g.:

MavenDependencyUtil.addFromMaven(model,
    "org.jetbrains.kotlin:kotlin-stdlib:1.6.10");

For light tests, use convenience method DefaultLightProjectDescriptor.withRepositoryLibrary() and JavaModuleFixtureBuilder.addMavenLibrary() for heavy tests.

If a required library is an unpublished JAR file, use PsiTestUtil.addLibrary() or addProjectLibrary() method and the JAR file path, e.g.:

PsiTestUtil.addLibrary(model,
    "internal-library", getTestDataPath(), "internal-library-2.0.jar");

ProjectActivity are no longer awaited on project open in tests. If tests depend on some job done in ProjectActivity (e.g., automatic project re-import), implement a dedicated event/listener and wait for it explicitly. As a workaround, use StartupActivityTestUtil.waitForProjectActivitiesToComplete().

Indexing is now run asynchronously in a background thread. Use IndexingTestUtil.waitUntilIndexesAreReady()/suspendUntilIndexesAreReady() to wait for fully populated indexes.

note

Something missing?

If a topic you are interested in is not covered in the above sections, let us know via the Was this page helpful? feedback form below or other channels.

Please be specific about the topics and reasons for adding them, and leave your email in case we need more details. Thanks for your feedback!