IntelliJ Platform Plugin SDK Help

Testing Highlighting

When writing plugin tests, a common task is testing various kinds of highlighting (inspections, annotators, parser error highlighting, etc.). The IntelliJ Platform provides a dedicated utility and markup format for this task.

To test the highlighting for the file currently loaded into the in-memory editor, invoke CodeInsightTestFixture.checkHighlighting(). The parameters to the method specify which severities should be taken into account when comparing the results with the expected results: errors are always taken into account, whereas warnings, weak warnings, and infos are optional. To ignore verifying additional highlighting, set parameter ignoreExtraHighlighting to true.

Alternatively, you can use CodeInsightTestFixture.testHighlighting(), which loads a testdata file into the in-memory editor and highlights it as a single operation.

Example: Custom Language Support Tutorial: Testing Annotator


If you need to test inspections, they must be enabled explicitly. This is done by calling CodeInsightTestFixture.enableInspections() in the setup method of your test or directly in a test method, before the call to CodeInsightTestFixture.checkHighlighting().

Syntax Highlighting

To test syntax highlighting provided by Lexer, use EditorTestUtil.testFileSyntaxHighlighting().

This method takes the tested file and the answer file describing expected highlighting information for each token. The answer file format is as follows:


It starts with token value, which is the actual token value from the tested file (space characters in token value are replaced with ). It is followed by indented list of text attribute keys, starting with the key defined for the given token, followed by fallback keys separated by =>.

Creating an answer file from scratch would be cumbersome process, so it is recommended to provide only the tested file and executing the test. Test will fail and the expected answer file will be generated. Review the generated file carefully, and provide fixes to the syntax highlighter and the answer file if needed.

Expected Highlighting Results

The expected results of the highlighting are specified directly in the source file. The platform supports an extensive XML-like markup language for this. In its simplest form, the markup looks like this:

<warning descr="expected warning message">code to be highlighted</warning>

A more realistic example, embedded in Java test data to be highlighted:

public int <warning descr="The compareTo() method does not reference 'foo' which is referenced from equals(); inconsistency may result">compareTo</warning>(Simple other) { return 0; }


The tag name specifies the severity of the expected highlighting. The following severities are supported:

  • <error>

  • <warning>

  • <weak_warning>

  • <info>

  • <inject> for an injected fragment

  • <symbolName> for a marker that highlights an identifier according to its type

  • any custom severity can be referenced by its name

Optional Attributes

The tag can also have the following optional attributes.


  • descr expected message associated with the highlighter (if not specified, any text will match). If the message contains a quotation mark, it can be escaped by putting two backslash characters before it.

  • tooltip expected tooltip message


  • textAttributesKey expected TextAttributesKey referenced by its externalName

  • foregroundColor, backgroundColor, effectColor expected colors for the highlighting

  • effectType expected effect type for the highlighting (see EffectType)

  • fontType expected font style for the highlighting (0 - normal, 1 - bold, 2 - italic, 3 - bold italic)

Special Cases

Nested tags are supported:


Overlapping tags (annotations) are currently not supported in the test framework (but displayed correctly in the editor, albeit this is not an officially supported scenario):

Last modified: 14 May 2024