Conti/all tooling changes - #7023
Conversation
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This comment has been minimized.
This comment has been minimized.
BenchmarksBenchmark execution time: 2026-01-06 16:12:54 Comparing candidate commit bcdd9ba in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 290 metrics, 30 unstable metrics. |
| for (const [name, PluginClass] of Object.entries(this.constructor.plugins)) { | ||
| this[name] = new PluginClass(...args) | ||
| // Handle case where value is an array of plugin classes | ||
| if (Array.isArray(PluginClass)) { |
There was a problem hiding this comment.
Do we already have cases where this would be used?
There was a problem hiding this comment.
No, but the idea would be for us to still be able to use .assertSomeTrace({span object}), mainly for tags that we don't know the exact value, such as error stack traces.
There was a problem hiding this comment.
| const ANY_STRING = Symbol.for('test.ANY_STRING') | ||
| const ANY_NUMBER = Symbol.for('test.ANY_NUMBER') | ||
| const ANY_VALUE = Symbol.for('test.ANY_VALUE') |
There was a problem hiding this comment.
Could we already use these somewhere in our code where it would make the assertion more readable?
I think it is best to not only add a tool but to use it right away to justify its addition.
Should we just export these instead of using Symbol.for? That way we guarantee that there is no typo while using them.
There was a problem hiding this comment.
There was a problem hiding this comment.
I added it to exports 👍
|
|
||
| const assertObjectContains = function assertObjectContains (actual, expected, msg) { | ||
| // If expected contains asymmetric matchers, use our custom implementation | ||
| if (containsAsymmetricMatchers(expected)) { |
There was a problem hiding this comment.
Are we expecting to use the asymmetric matchers in most situations? Depending on that, I would use a different implementation: Instead of having to iterate through the object as a whole each time, we could just use a try / catch. If an error is thrown, we rerun the assertion using the asymmetric matchers. If that throws as well, we throw the original caught error. That way the average case stays fast and there is no need to check anything in addition (because we expect no asymmetric matchers being used).
There was a problem hiding this comment.
Really they are mainly for targeting scenarios, especially error tests since we can't know stacktrace reliably but should test for it. Or any other tags where the value may change between tests. Okay, I made that change 👍
3 participants
What does this PR do?
Summary of Changes:
Motivation
Plugin Checklist
Additional Notes