Most of the tests in the IntelliJ Platform codebase are model level functional tests. What this means is the following:
The tests run in a headless environment that uses real production implementations for most components, except for many UI components.
The tests usually test a feature as a whole, rather than individual functions that comprise its implementation.
The tests do not test the Swing UI and work directly with the underlying model instead.
Most of the tests take a source file or a set of source files as input data, execute a feature, and then compare the output with expected results. Results can be specified as another set of source files, special markup in the input file, or directly in the test code.
The most significant benefit of this test approach is that tests are very stable and require very little maintenance once written, no matter how much the underlying implementation is refactored or rewritten.
In a product with 15+ years of a lifetime that has gone through a large number of internal refactorings, we find that this benefit dramatically outweighs the downsides of slower test execution and more difficult debugging of failures being compared to more isolated unit tests.
Another consequence of our testing approach is what our test framework does not provide:
We do not provide a recommended approach to mocking. We have a few tests in our codebase that use JMock. Still, in general, we find it difficult to mock all of the interactions with IntelliJ Platform components that your plugin class will need to have. We recommend working with real components instead.
We do not provide a general-purpose framework for Swing UI testing. You can try using tools such as FEST or Sikuli for plugin UI testing, but we don't use either of them and cannot provide any guidelines for their use. Internally, we use manual testing for testing our Swing UIs. Please do not use platform/testGuiFramework; it is reserved for internal use.