In o(myObject).satisfies(myValidator(someSepcification)), the satisfies bit takes too much space and hampers readability. o(myObject)._(matches(someSepcification)) would make more readable tests.
Also, the .notSatisfies() and .notDeepEquals() assertions are not very useful, and even IMO an anti-pattern, as any difference will make them pass, not necessarily the one the tester had in mind when designing the test. They should be. retired.
Here's the roadmap I propose
For v4.2.0:
Add ._() as a synonym to .satisfies().
Make o.warn = false. If the user sets o.warn = true, have .satisfies, .notSatisfies and .notDeepEquals issue warnings announcing future obsolescence (we can do that cleanly such that a single list is reported after publishing the report).
For v5.0.0
Make the warning unconditional, and state that the methods are deprecated.
In
o(myObject).satisfies(myValidator(someSepcification)), thesatisfiesbit takes too much space and hampers readability.o(myObject)._(matches(someSepcification))would make more readable tests.Also, the
.notSatisfies()and.notDeepEquals()assertions are not very useful, and even IMO an anti-pattern, as any difference will make them pass, not necessarily the one the tester had in mind when designing the test. They should be. retired.Here's the roadmap I propose
For v4.2.0:
Add
._()as a synonym to.satisfies().Make
o.warn = false. If the user setso.warn = true, have.satisfies,.notSatisfiesand.notDeepEqualsissue warnings announcing future obsolescence (we can do that cleanly such that a single list is reported after publishing the report).For v5.0.0
Make the warning unconditional, and state that the methods are deprecated.
Sometimes in the future
Remove them altogether.