Skip to content

Property assertions

Chris Dibbern edited this page May 7, 2018 · 12 revisions

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.

has

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 })

Options

See MatchMode and LocationMode on the Options page.

hasAll

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.

Options

You can change how the API interprets property (and element) assertions. See MatchMode on the Options page.

hasAllAsserts

As with hasAll, this is a wrapper for hasAsserts that requires (at compile time) all properties to be specified, not only a subset.

hasAsserts

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.

Options

See LocationMode in the Appendix.

hasProperties

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"
    }
  });

Options

You can change how the API interprets property (and element) assertions. See MatchMode on the Options page.

hasKeys

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"]);
Clone this wiki locally