2.3.1.3 release notes
2.3.1.3
- I've posted a demonstration video detailing all of the recent Apex unit testing and code coverage enhancements including those described below.
- Issue 822 - Implemented another round of improvements around execution of dependent Apex unit tests. Now most Apex unit test run configuration types can be optionally configured as Changed Only which will execute only the Apex unit test classes from the run configuration that are either themselves changed or are (transitive) dependents of changed production (i.e., non-test) Apex source files. To be specific, changed in this context is with regard to the project's configured version control system, so Changed Only is applicable only to VCS-enabled projects. Enabling it for a run configuration in a non-VCS-enabled project will simply result in all of that run configuration's tests being executed as if that option was disabled.
The Changed Only option can be enabled for all Apex unit test run configuration types except for the following:- Apex test class/method context configurations - The user has explicitly requested execution of the contextually-selected test class/method, and it would not make sense to execute it conditionally.
- Dependents configurations - The user has explicitly requested execution of all dependent Apex unit tests that exercise the contextually-selected production Apex type/member, and it would not make sense to execute only those that are changed. In fact, in the most common use case, the production source would likely be changed and many/most of the covering tests would not.
Two new application-level configuration options have been added to Illuminated Cloud | Configure Application | Unit Tests and Code Coverage | Unit Tests in support of Changed Only Apex unit test execution:- Default to 'Changed Only' (disabled by default) - When enabled, all newly-created Apex unit test run configurations that support Changed Only behavior are created with that option enabled.
- When no changed tests are found ... - When a Changed Only unit test run configuration is requested for execution and no changed subset of unit tests is found to execute, this configuration option determines the resulting behavior:
- Prompt the user (default) - The user is prompted as to whether or not all unit tests for the run configuration should be executed instead. The user may choose to hide further occurrences of this prompt by checking Don't ask again. When checked, a response of Yes sets the configuration option to Run all tests, and a response of No sets it to Stop test execution.
- Run all tests - The user is not prompted and all unit tests for the run configuration are automatically executed.
- Stop test execution - The user is not prompted and test execution stops.
- Implemented the Show Only Files with Uncommitted Changes filter in the Apex code coverage view which complements the Changed Only test execution filtering described above so that both test execution and coverage analysis can be performed based on only files changed relative to version control. The filter includes both changed production Apex classes and triggers and unchanged production classes and triggers that are covered by changed test Apex classes. This ensures that you see all coverage changes for changed production and test Apex source files based when this filter is applied.
With these changes, I'm considering this overarching set of Apex unit testing dependency analysis-related improvements to be complete. Of course, if issues are found with the delivered functionality — whether bugs, usability issues, or other related opportunities for improvement — please let me know via the public issue tracker and I'll be happy to take a look as appropriate. Hopefully, though, these improvements will make owning and evolving your Apex code base significantly more efficient and robust.
Volunteers (still) kindly requested
Please see issue 2565 for more extensive details, but I'm testing a set of changes to minimize (ideally eliminate) potentially slower operations on the EDT (Event Dispatch Thread) and would love to have at least a few adventurous folks help with a burn-in phase before making these changes generally available in official builds. Note that I've already been using these changes locally for a few weeks now and they seem quite solid, but my guess is that there are still a few kinks to be found and addressed. These aren't the types of changes that are easily exercised by short-lived automated/manual functional/regression testing, hence the request for some assistance with real-world usage.
If you'd like to help, please see the issue linked above and:
- Add yourself as a watcher of the issue so that I have an idea of whether these test builds are actually being used "in the wild" and so that you know when new test builds are available.
- Follow the instructions in the issue to download and install the latest test build that will effectively be the exact same as the current official build but with these changes to minimize usages of potentially slow plugin SDK calls from the EDT.
- If/when problems are found specific to these test builds, please report them via the linked issue and, if the problems are sufficiently impactful to your IC2 usage, revert to the official build until I report them as (prospectively) addressed via the linked issue.