Inlay hints, multi-project and other unit testing



I have a couple of questions regarding unit testing in different areas.

1. I'm implementing a custom InlayHintsProvider, and I want to write some tests as well for it. Now, I found examples in intellij-community:


and I see that it is similar to how inspection testing works.

If I'm not mistaken <# [hint text] #> is supposed to validate inline hints while <# block [hint text] #> validates block type ones.

In case of e.g.

<# block [   2 usages   2 inheritors  ] #>
  • are whitespaces around hint texts meant to represent the inset and padding around hints,
  • and is there anything else that would be useful to know about inlay hint testing, and is there any documentation about it?


2. I'm testing a Configurable object for a Settings panel, which incorporates manipulating an application and a project service. I'm using BasePlatformTestCase as the base class and I have multiple test methods.

The problem I have is that the services are not reset after each test method, and due to this test methods interfere with each other. Is there a way to reset the state of services or even remove service instances between test methods?

I tried running them as JUnit run configuration and via Gradle as well.

I could reset each field in the services manually, but I have some logic to load default data, so that would not entirely solve my problem.


3. In the plugin I'm implementing, I have a project service which I would like to validate with simulating having multiple projects open. Is there a recommended or nice way to have more than one projects open in unit testing or open them programmatically?


Thank you!


Sorry for delay.

1. pinged my colleague

2. That is expected, see last sentence here The alternative in resetting state(s) is to use Heavy Tests instead.

3. What do you need to validate exactly here? Technically you can instantiate as many Projects/Fixtures as you like in your custom test implementation.


No worries.

1. Thank you.

2. I will give heavy tests a try. I missed that detail about the difference between light and heavy tests.

3. I added some components to the plugin's Settings panel that users could configure for each project separately, so the panel would display those settings specific to a given project. I will check additional Project/Fixture instantiation.

Also, now that I think about it, checking this logic might just validate whether project services themselves work, rather than that my settings implementation is project specific, in which case this test would be unnecessary.


re (3), agree. though of course there _might_ be a chance your services mix up state(s) in some weird way internally.


Meanwhile I tried the new project descriptor creation to reset states which seems to work nicely. Thanks again for the tip.

However I realized that this solution is feasible to reset at most project services. Is there a way to reset application services too either via light or heavy tests? I have not managed to dig deeper into this topic to see how this works of if it is possible.


No, it's your responsibility to reset/clear caches/etc. in your test class.


This week I've been trying to find a solution to reset, clear, unregister/re-register application services after test methods but with no luck.

Do you have an example I could use?


I'm not aware of a generic solution. There's community/platform/testFramework/src/com/intellij/testFramework/ServiceContainerUtil.kt that allows replacing services (or registering mocks) for tests, might be helpful.


Thank you, I will take a look at ServiceContainerUtil, it at least might be a good place to start.


Please sign in to leave a comment.