Skip to main content
2.3.1.5 release notes
2.3.1.5
- Implemented several improvements to the recent dependencies-/dependents-based enhancements for Apex unit test execution and code coverage analysis:
- Transitive dependencies are now collected at the member-level instead of the file-level. This effectively means that the resulting set of dependencies should be as small and focused as possible short of performing runtime data flow analysis.
- Trigger logic relationships are now properly included when collecting transitive dependencies and dependents. See below for more information about the general improvements around the relationships between DML statements (both static and dynamic) and triggers included in this build.
- Added support for dependents unit test run configurations from Apex triggers.
- Minor cosmetic improvements regarding how dependency relationships are displayed in the coverage view when filtering by VCS changes.
Note that I am also currently wrapping up another set of major improvements in this area to include many other metadata relationships that could affect Apex unit testing behavior and code coverage data, e.g., modified custom labels files (granular to usages of individual modified labels), profiles and permission sets (granular to individual modified authorization entries), custom objects/metadata types/settings and their fields, flows, static resources/bundles, Visualforce pages, DataWeave scripts, etc. With those improvements, most (all?) of the known gaps in metadata dependencies — at least those relevant for Apex unit testing and code coverage analysis — should be addressed. - Added references from DML statements and dynamic DML method invocations to the corresponding triggers that would handle that DML. References are added based on the DML operation type and SObject type(s) upon which DML is performed and the corresponding triggers' SObject types and supported DML operations. It is now possible to navigate directly from DML operators and dynamic DML method calls to the corresponding triggers, and of course to find all usages of a trigger as the corresponding DML statements and dynamic DML method invocations. Of course, such references are only added when concrete SObject types can be inferred, so DML upon generic SObjects will not yield such references. Supported dynamic DML methods include
System.Database.<dmlOperation>[Async|Immediate]()
, System.EventBus.publish()
, and Database.UnitOfWork.<dmlOperation>Record[s]()
. - Added DML/trigger relationships to the Apex call hierarchy view (Ctrl+Alt+H on Windows/Linux or Ctrl+Opt+H on Mac).
- Added code intentions to reformat Apex trigger DML events one per-line or all on the same line akin to the existing intentions for method formal parameters and invocation arguments, SOQL
SELECT
items, etc. - Updated the Apex recursive call line marker provider to add a line marker for recursive trigger behavior. My guess is that this won't actually occur very often since (hopefully) most trigger logic is properly encapsulated into trigger handler-type patterns and not immediately within trigger bodies.
- Fixed an issue where copying an Apex unit test context configuration for a specific unit test class or method would result in a read-only context configuration instead of an editable run configuration.
- Updated the Apex call hierarchy caller and callee views to detect recursion loops and short-circuit those branches as appropriate for the view. The caller view simply terminate the branch, and the callee view terminates the branch and shows details about the (potentially mutual) recursion loop.
- Added highlighting for exit points of methods/constructors/property accessors via the
return
and (unhandled) throw
keywords and loops via the break
and continue
keywords. By placing the caret on any of these keywords, all exit points in the current context are highlighted and can be navigated using next/previous occurrence (Ctrl+Shift+F7 then F3/Shift+F3 on Windows/Linux or Cmd+Shift+F7 then Ctrl+Opt+Up/Down on Mac). - Fixed an issue with incremental OST updates after a successful deployment that includes SObject metadata files when the corresponding option is enabled.