Commit Graph

16 Commits

Author SHA1 Message Date
Steve Gravrock
434575f49d Use one declaration per statement
The old style of merging all of a function's variable declarations into
a single statement made some sense back in the days of var, but there's
no reason to keep doing it now that we use const and let.
2026-03-11 06:30:46 -07:00
Steve Gravrock
168ff0a751 Move private APIs to private namespace
Fixes #2078
2025-09-27 13:21:09 -07:00
Steve Gravrock
1166d10e43 Use const/let in specs, not var 2022-04-16 13:41:44 -07:00
Steve Gravrock
d27bb8fa96 Run Prettier on all files 2020-09-29 18:05:38 -07:00
Pivotal
ea3dd9dffc Refer to MatchersUtil instances as matchersUtil, not util 2020-02-10 17:26:05 -08:00
Steve Gravrock
25816a6e77 Added support for custom object formatters
Custom object formatters allow users to customize how an object is
stringified in matcher failure messages. This can already be done by
adding a `jasmineToString` method to the objects in question. But
it's not always desirable or possible to do that, particularly when
objects of a given "type" do not inherit from a specific prototype.
For instance, suppose a web service returns a list of foos that are
deserialized from JSON, e.g.:

   { fooId: 42, /* more properties */ }

The only way to define `jasmineToString` on those is by writing code to
add it to each instance at runtime. But a custom object formatter can
recognize that the object it's looking at is a foo and format it
accordingly:

   jasmine.addCustomObjectFormatter(function(obj) {
      if (typeof obj.fooId !== 'number') {
            return undefined;
        }

        return '[Foo with ID ' + obj.fooId + ']';
    });

Unlike `jasmineToString`, custom object formatters are scoped to a
particular spec or suite and don't require any changes to the code
under test.
2020-02-10 17:26:00 -08:00
Steve Gravrock
1f23f1e4d2 Inject a per-runable pretty printer into MatchersUtil
This will allow us to add support for custom object formatters, which
will be a per-runable resource like custom matchers, by injecting them
into the pretty-printer.
2020-02-10 17:26:00 -08:00
Steve Gravrock
dec67bd535 Don't require matchers and asymmetric equality testers to pass custom object formatters back to Jasmine
This makes it easier to write high quality matchers and asymmetric equality
testers, and is also a step toward supporting custom object formatters.

Previously, Jasmine passed custom object formatters as the second argument
to matcher factories and as and the second argument to asymmetric equality
testers' `asymmetricMatch` method. Matchers and asymmetric equality testers
were responsible for passing the custom object formatters to methods like
`matchersUtil#equals`:

  function toEqual(util, customEqualityTesters) {
    return {
      compare: function(actual, expected) {
        // ...
        result.pass = util.equals(actual, expected, customEqualityTesters, diffBuilder);

And:

  ArrayContaining.prototype.asymmetricMatch = function(other, customTesters) {
    // ...
    for (var i = 0; i < this.sample.length; i++) {
      var item = this.sample[i];
      if (!j$.matchersUtil.contains(other, item, customTesters)) {
        return false;
      }
    }

With this change, that is no longer necessary. Matchers and asymmetric
equality testers can ignore the existence of custom equality testers and
still fully support them:

  function toEqual(util) {
    return {
      compare: function(actual, expected) {
        // ...
        result.pass = util.equals(actual, expected, diffBuilder);

And:

  ArrayContaining.prototype.asymmetricMatch = function(other, matchersUtil) {
    // ...
    for (var i = 0; i < this.sample.length; i++) {
      var item = this.sample[i];
      if (!matchersUtil.contains(other, item)) {
        return false;
      }
    }

The old interfaces are still supported, for now, but will be deprecated
in a future commit and removed in the next major release after that.

In addition to making matchers and custom equality testers simpler,
this change sets the stage for adding support for custom object
formatters. Those will be architecturally similar to custom equality
testers, and by injecting a `MatchersUtil` instance everywhere we can
add them without requiring user code to pass them around as used to be
the case with custom object formatters.
2020-02-10 17:25:50 -08:00
Gregg Van Hove
3c47e71619 Also show tip for .not cases 2018-10-22 10:57:16 -07:00
Teagan Durtschi
7cbedcdda7 Add custom message for toBe() matcher when object equality check fails 2018-10-21 12:46:49 -04:00
Gregg Van Hove
79206ccff5 Rename j$ to jasmineUnderTest for specs
- Clarifies what it is for when writing tests
- No longer named the same as the `jasmine` that is injected into live
  code
2015-12-03 17:23:32 -08:00
Kyriacos Souroullas and Sheel Choksi
e346e7dcc1 Revert removal of compare nesting
Since we want the user to be able to pass a negative comparison function, the extra layer of wrapping is now needed
2013-10-28 17:13:09 -07:00
Sheel Choksi
39d7ebf28e Remove an extra layer of wrapping for matchers/custom matchers
Helps reduce how nested custom matchers have to be for users as well as
Jasmine internal matchers

[#59161378]
2013-10-20 22:21:56 -07:00
Gregg Van Hove and Tim Jarratt
1c19b8e38a Move spec files back out of spec/javascripts
- Jasmine gem allows us to specify a path to jasmine.yml via ENV

[finish #58126010]
2013-10-02 16:32:35 -07:00
Gregg Van Hove and Rajan Agaskar
5017d1a4f1 Make rake jasmine:ci run specs correctly.
- Will replace rake core_specs.
- Remove obsolete dependencies & files -- most of these were for build tasks we
  are no longer using. Notably, rspec and spec_helper were deleted.
2013-09-25 10:11:02 -07:00
Davis W. Frank
d53002c63a Matchers & Matchers specs now broken up into individual files. There is now a requireMatchers jasmineRequire function to attach matchers properly. 2013-06-02 22:22:25 -07:00