Description
Many of the benchmarks in @stdlib/assert/* measure performance of an "average" test case, meaning that test values are a mixture of values resulting in true and false values.
An example package having such benchmarks is @stdlib/assert/is-string.
Preferably, we'd split benchmarks in separate positive/negative benchmark runs to have a better handle on performance depending on the input value type. While, for many assert packages, the difference is not likely to be significant, for others, the performance difference will be significant, as the assertion logic is more complex or may, in the attempt of robustness, perform various operations which are slow, such as walking the prototype chain or resolving a constructor name, etc. In these instances, having a more granular understanding of performance is useful, as downstream consumers can then make accommodations if such perf cliffs are undesired (e.g., when implementing dispatch logic and needing to resolve an input value's "type" before delegating to a specialized implementation).
An example package having benchmarks which are split into positive/negative test values is
@stdlib/assert/is-complex-like.
The request in this issue is to refactor any assertion packages which are not split into positive/negative test values to be similar to @stdlib/assert/is-complex-like.