-
Notifications
You must be signed in to change notification settings - Fork 0
Property assertions
The following assertions deal with the components of an entity. As with simple and array assertions, property assertions can be negated with not
and maybe
(see operators).
A special note on negations: when using the not
or maybe
operators to negate any of the property assertion methods listed, here, be mindful of the behavior when the contextual value is undefined
or null
instead of an object.
Assert(undefined)
.not.hasProperties({ myProp: 1 })
.maybe(false).hasProperty(p => p.another);
Assert(null)
.not.hasKeys("one", "two");
The above assertions will pass, because its true that undefined and null don't have those properties. If you want such assertions to fail, use isDefined in addition to the properties assertions. This behavior was implemented intentionally to keep tests simple.
A shorthand alias for hasProperties, hasProperty, hasElements, and hasKeys. See those methods for details and any caveats.
Assert(["a","b","c"]).has(2); // same as .hasKeys([2])
Assert(["a","b","c"]).has(["b","c"]); // same as .hasElements(["b","c"])
Assert({ myProp: 3 }).has("myProp"); // same as .hasProperty(o => o.myProp)
Assert({ myProp: 3 }).has(o => o.myProp); // same as .hasProperty(o => o.myProp)
Assert({ myProp: 3 }).has({ myProp: 3 }); // same as .hasProperties({ myProp: 3 })
See MatchMode and LocationMode on the Options page.
Alternative hasProperties that requires (at compile time) all properties to be specified, not only a subset. Failure to do so will result in compile-time errors. This helps ensure that your tests stay up-to-date with any model changes. Use when the situation permits.
You can change how the API interprets property (and element) assertions. See MatchMode on the Options page.
As with hasAll, this is a wrapper for hasAsserts that requires (at compile time) all properties to be specified, not only a subset.
Alias for either hasElements or has/hasProperties
called with MatchMode.asserts
. When calling user-provided lambdas, this ensures the contextual
value is already wrapped in an Assert()
.
Assert(myArray).hasAsserts([v => v.matches(/something/)]);
Assert(obj).hasAsserts({ myProp: v => v.equals(2) });
Assert(myArray).hasElements([v => v.matches(/something/)], MatchMode.asserts);
Assert(obj).hasProperties({ myProp: v => v.equals(2) }, MatchMode.asserts);
As with the aliased methods, this only impacts lambda assertion behavior. All other behavior, like non-lambda-valued property/element comparisons, remains the same.
See LocationMode in the Appendix.
Recursively asserts over the contextual value's properties.
Scope: Preserves/unchanged.
The following example demonstrates several ways of making these assertions.
Assert(viewModel).hasProperties({
username: /exampleuser\d+/,
email: e => Assert(e).matches(/\w+\@example.com/),
academicInfo: {
gpa: g => g > 3.5,
type: "Graduate Student"
}
});
You can change how the API interprets property (and element) assertions. See MatchMode on the Options page.
Verifies that the contextual value contains the given keys, with no assumptions made about the corresponding values.
Scope: Preserves/unchanged.
Assert(viewModel).hasKeys(["one", "two", "three"]);