Getting testdouble.js to play nicely with Jasmine expectations?

[BrianGenisio]

I realize that this library is platform agnostic, but I wonder if anyone has any experience getting this library to play nicely with Jasmine's expectation engine? Sorry in advance if this is a bit off-topic. Im not sure where else to ask it.

If I have a simple spec which validates that something was called:

describe('The thing', () => {
  beforeEach(() => test.dependency = td.create(Dependency));
  beforeEach(() => test.subject = new DoesThing(test.dependency));

  it('fiddles the dependency', () => {
    test.subject.doThing('jake', 'stuff', 99);

    td.verify(test.dependency.fiddle({a: 'jake', b: 'stuff', c: 99}));
  });
});

Then Jasmine reports: "SPEC HAS NO EXPECTATIONS" and dumps an error to the console. It is very distracting.

I'd like to get Jasmine to see this verify call as an expectation.

Any thoughts on how to accomplish this?

[BrianGenisio]

My first instinct was to say that I didn't want a custom matcher... but that actually works out pretty well:

jasmine.addMatchers({
  toVerify: function() {
    return {
      compare: function(doubleCall) {
        try {
          td.verify(doubleCall);
          return { pass: true };
        } catch(e) {
          return {
            pass: false,
            message: e.message
          }
        }
      }
    };
  }
});

Then instead of

td.verify(test.dependency.fiddle({a: 'jake', b: 'stuff', c: 99}));

It becomes

expect().toVerify(test.dependency.fiddle({a: 'jake', b: 'stuff', c: 99}));

[searls]

seems legit. How would you want to incorporate this is an adaptable way to
the repo?

For instance, jasmine1, jasmine2, chai, all have separate custom matcher
APIs, and we don't want to add a dependency to any of them.

Maybe testdouble.addMatcherTo(jasmine, 'jasmine2')? Can't think of
something clean and tidy that isn't too presumptive

On Mon, Oct 26, 2015 at 8:30 AM Brian Genisio notifications@github.com
wrote:

My first instinct was to say that I didn't want a custom matcher... but
that actually works out pretty well:

jasmine.addMatchers({
toVerify: function() {
return {
compare: function(doubleCall) {
try {
td.verify(doubleCall);
return { pass: true };
} catch(e) {
return {
pass: false,
message: e.message
}
}
}
};
}
});

Then instead of

td.verify(test.dependency.fiddle({a: 'jake', b: 'stuff', c: 99}));

It becomes

expect().toVerify(test.dependency.fiddle({a: 'jake', b: 'stuff', c: 99}));

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[jasonkarns]

A similar idea was brought up by Casey Brant in his blog post responding to testdouble.js. I responded here: https://github.com/BaseCase/trying_out_test_double/issues/1 (the suggestion being to create a separate library that acts as a bridge between testdouble.js and the assertion lib)

Given a few common such bridges, they might be useful in a contrib/ section or something.

However, in this particular case I'm curious how jasmine-given gets around this. jasmine-given doesn't define any expectations (that I know of). Rather, it's raise-exception or pass. Is something other than Jasmine core doing this?

[BrianGenisio]

I don't know... seems like keeping testdouble.js agnostic is fine. I wasn't really opening an issue to suggest a change to the lib. (I wish GitHub had a "questions" mechanism).

A Wiki page that includes some integration notes might be all that you need.

[searls]

@jasonkarns jasmine-given uses my jasmine-matchers-wrapper to add matchers regardless of jasmine1 or jasmine2 (i would recommend using the same in this case). Link to usage: https://github.com/searls/jasmine-given/blob/master/app/js/jasmine-given.coffee#L207-L210

[jasonkarns]

All this time and I never knew that every then was silently being wrapped in a matcher!

[BaseCase]

Hi @BrianGenisio, I've done something pretty similar to what you posted above (edit to add: for chai, not for Jasmine, but same idea), but as a separate little library in https://github.com/BaseCase/testdouble-chai. I was able to get it plugged in nicely with normal test runner output, sans distracting console printing. Not sure if that's useful to you or not, but feel free to copy/paste if it's helpful for your Jasmine matcher! :)

[searls]

& I recommend we do something exactly like testdouble-chai. A testdouble-jasmine module that receives both jasmine & test double as injected dependencies, and which sets up a toHaveBeenCalled-like matcher that is in line with to verify's signature (method, args, options) on either jasmine 1 or jasmine 2. Seems like the smart way to go.

[searls]

Hey @BrianGenisio, do you plan on running with this?

[BrianGenisio]

Sure. I can do that! Will look at it Monday.

On Thu, Nov 26, 2015 at 9:02 AM Justin Searls notifications@github.com
wrote:

Hey @BrianGenisio https://github.com/BrianGenisio, do you plan on
running with this?

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[BrianGenisio]

Still needs some work, and I need to handle the whole Jasmine 1.x vs 2.x difference... but here is my first pass: https://www.npmjs.com/package/testdouble-jasmine

I'm trying to figure out if I should register the matchers for the user (like the jasmine-chai pattern) or just publish the matcher and let the user decide where/when to register them. I chose the auto register for the first pass, but I'm not confident it is idiomatic for Jasmine.

Thoughts?

[searls]

I like the way that testdouble-chai does it. But it's probably not a big deal since I don't anticipate having a slew of plugins. (Why not expose both? )

All I really care about is that you don't have a hard dependency on td.js

As for smoothing over the API between 1 & 2, I wrote this a long time ago: https://www.npmjs.com/package/jasmine-matcher-wrapper

On Feb 18, 2016, at 5:13 PM, Brian Genisio notifications@github.com wrote:

Still needs some work, and I need to handle the whole Jasmine 1.x vs 2.x difference... but here is my first pass: https://www.npmjs.com/package/testdouble-jasmine

I'm trying to figure out if I should register the matchers for the user (like the jasmine-chai pattern) or just publish the matcher and let the user decide where/when to register them. I chose the auto register for the first pass, but I'm not confident it is idiomatic for Jasmine.

Thoughts?

—
Reply to this email directly or view it on GitHub.

[BrianGenisio]

Good points. I've changed the API and now you can get() the matcher and use them however you want, or you can use() the matcher, which registers them globally.

Internally, it figures out if it is using the Jasmine 1.x or 2.x style, and wraps it (if necessary, using your jasmine-matcher-wrapper) and registers it using the mechanism in the library.

The tests validate against Jasmine 1.x or 2.x as well as the get() or use() method.

Feeling pretty good about it now:
https://www.npmjs.com/package/testdouble-jasmine

[searls]

That's great! Send a PR to update our docs/ about it!

On Feb 18, 2016, at 9:37 PM, Brian Genisio notifications@github.com wrote:

Good points. I've changed the API and now you can get() the matcher and use them however you want, or you can use() the matcher, which registers them globally.

Internally, it figures out if it is using the Jasmine 1.x or 2.x style, and wraps it (if necessary, using your jasmine-matcher-wrapper) and registers it using the mechanism in the library.

The tests validate against Jasmine 1.x or 2.x as well as the get() or use() method.

Feeling pretty good about it now:
https://www.npmjs.com/package/testdouble-jasmine

—
Reply to this email directly or view it on GitHub.