Allow chainable matchers (in one line) #195

wants to merge 2 commits into


None yet
3 participants

By simply changing the return value of the function returned from jasmine.Matchers.matcherFn_ from undefined to this, we can allow third-party libraries building on Jasmine (e.g. jasmine-jquery) to create custom chained matchers.

I have also run rake to ensure that the generated files are up to date with the source files.

Nick Morgan added some commits Mar 3, 2012

Nick Morgan
Change return value of Matchers.matcherFn_ from undefined to this.
This simple change allows third party libraries (such as
jasmine-jquery) to create chainable matchers.

maxbrunsfeld commented Mar 3, 2012

This was my first thought when writing this pull request. Unfortunately, this change isn't sufficient to make chainable matchers work correctly.

  1. With this setup, each matcher in a chain will produce its own result, with separate (and fragmented) messages.
    So a line like this expect("my.event").toHaveBeenTriggeredOn(myLink).withArgs("foo") would produce two failures, with messages like

      - Expected 'my.event' to have been triggered on '<a/>'
      - Expected 'my.event' with args 'foo'

    I want a message like this:

      - Expected 'my.event' to have been triggered on '<a/>` with args 'foo'.

    It matters especially when a not is used. Suppose the "foo" event was triggered on myDiv, with the argument "bar". The assertion expect("foo").not.toHaveBeenTriggeredOn(myDiv).withArgs("something_else") should pass, because the arguments were different. With this setup however, we'd still get a failure from the first matcher (Expected 'foo' not to have been trigggered on '<div/>')

  2. All of the matcher functions you add need to share a single namespace. Suppose, as in the example above, I wanted to add a withArgs matcher, chainable from toHaveBeenTriggeredOn. I wouldn't be able to add a different withArgs matcher chainable from toHaveBeenCalled. Also, the method is now exposed as a top-level matcher of own, (expect(spy).withArgs(2)), which is okay, but not ideal.


ragaskar commented Oct 6, 2012

Closed as dupe of pivotal#194 ...

@ragaskar ragaskar closed this Oct 6, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment