2.3.1.2 release notes
2.3.1.2
- Issue 579 - Both of the aforementioned limitations of the new Deploy before running unit tests feature have been addressed:
- Multi-module projects are now properly supported, with out-of-date (transitive) dependencies from all dependency modules for the requested unit tests being deployed in dependency order before those tests are executed. Because unit test run configurations are associated with a single connection, only dependencies for modules also configured for that connection are included.
- If conflicts are detected during the pre-test deployment and the user chooses to overwrite the org with the local files, the deployment proceeds and unit tests are executed after the successful deployment.
- Issue 822 - Implemented another new feature for Apex unit test execution, specifically the ability to execute all dependent tests for a given production (i.e., non-test) class, concrete method, constructor, or property with accessor logic. This feature is initiated via the context menu, Run gutter action, or context action (Alt/Opt+Enter) for the desired type or member declaration. Gutter Run actions are shown by default but can be disabled if desired via the new configuration options under Illuminated Cloud | Configure Application | Unit Tests and Code Coverage | Unit Tests:
- Show 'Run' action for production classes
- Show 'Run' action for production invocable members
Dependents are calculated via the IDE's standard Find Usages mechanism recursively until closure is reached. Usages of implemented or overridden methods are found from the base declaration to ensure that all (potential) polymorphic usages are included. Only the resulting dependent Apex unit test methods are included in the resulting test execution. If a@TestSetupmethod is found as a dependent, all test methods from the enclosing test class are included.
Building on this work, I am also planning to add another Apex unit test configuration type, tentatively called Changed Only, that is conceptually similar to the existing All Tests configuration type but executes only Apex unit test classes/methods and dependents of production classes/members which are changed in version control. This will allow users to execute all Apex unit tests required to verify all local changes.
The combination of these two features — updating the target org with all stale test dependencies and being able to execute the specific tests that exercise specific modified Apex classes and members — should hopefully provide an efficient and reliable mechanism for focused test-driven development in Apex.
Important qualification about how dependencies and dependents are calculated for these two features: Only static references are followed when computing the closure of dependency files for deployment and dependent tests for execution respectively. If relationships are expressed dynamically, e.g., viaSystem.Type.forName(typeName),SObjectTypeName.get(fieldName), etc., the resulting targets of those relationships will not be included, and both org updates and covering test selection will likely need to be performed explicitly. - Issue 2563 - Fixed an issue with the
-l RunSpecifiedTestsCLI-based deployment argument where the old command's-r commaDelimitedTestNamesargument was being used rather than the new command's-t testClassName(repeated for each test class) argument. - Fixed an issue with the Control Flow Analysis code inspection when checking for required explicit constructor invocations against implicit no-arg constructors.
- Removed obsolete support for Python from IC2's Salesforce Functions support.
- Other related fixes and improvements.
Regarding Salesforce Functions support
Are you using IC2's support for Salesforce Functions to help wind down your implementation of the feature and migrate to a replacement? If so, I have no problem keeping it in place until the scheduled end-of-life on January 31, 2025. If not, though, I'd prefer to eliminate the cost of maintaining a non-trivial feature that's going completely unused sooner rather than later. The Salesforce Functions tool window now includes a header warning about this impending feature end-of-life, prompting those still using it in a production-class manner to share that usage so that I can better understand when/whether support for the soon-to-be-retired feature can be removed. If I don't hear from anyone who's using it for production-class work, I will likely remove support for the feature shortly.
Volunteers kindly needed
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.