Re: [jasmine-js] Any work on extending expect() to check all/one element of an array (universal and existential quantification)?

[Doug Reeder]

To me, it seems just as clear to define custom matchers:

expect(someArray).toContain(42)

expect(someArray).toAllBe(42)

...thought a better name than "toAllBe" seems possible.

-- Sent from my HP Pre 3

---

On Mar 12, 2013 12:02 PM, Andre Asselin <ass...@gmail.com> wrote:

I was wondering if there is any interest, or any work queued up to extend expect() to check all/one element of an array.  Something like this:

expectAll(someArray).toBe(42)

where the expectation would be true if EVERY element of the array was 42.  Similarly, something like

expectOne(someArray).toBe(42)

would be true if at least 1 element of the array was 42.  In other words, these are the mathematical Universal ∀ and Existential ∃ quantification.

Frisbyjs has something like this for REST testing work, and it's quite useful there, but it occurs to me that this would be a generically useful.

I can work up some patches if there's interest.

Any thoughts on what the syntax should look like?  I can imagine a few alternatives:

expectAll(someArray).toBe(42)             expectOne(someArray).toBe(42) / expectExists(someArray).toBe(42)
expect(someArray).all.toBe(42)             expect(someArray).one.toBe(42)

- Andre Asselin

--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jasmine-js+...@googlegroups.com.
To post to this group, send email to jasmi...@googlegroups.com.
Visit this group at http://groups.google.com/group/jasmine-js?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andre Asselin]

The downside of using a custom matcher is that you wouldn't be able to specify arbitrary constraints to check against (either that, or you have to build custom matchers for every possible condition).  For example, suppose I wanted to check that all the array elements were > 42:

expectAll(someArray).toBeGreaterThan(42);

That might seem like a trivial example, but suppose a user of Jasmine creates a custom matcher (e.g. toConformToJSONSchema()).  I'd think having Jasmine have the for-all/there-exists support built into it would be nicer than making the user write up to 3 custom matchers (with the associated array iteration boilerplate).  IOW,

expect(foo).toConformToJSONSchema(fooSchema)
expectAll(fooArray).toConformToJSONSchema(fooSchema)
expectOneOf(fooArray).toConformToJSONSchema(fooSchema)

vs

expect(foo).toConformToJSONSchema(fooSchema)
expect(fooArray).toAllConformToJSONSchema(fooSchema)
expect(fooArray).toContainOneThatConformsToJSONSchema(fooSchema)

What do you think?

Ultimately, I'd like to see something get into Jasmine, so I'm willing to accept whatever the community decides...

- Andre Asselin

[Davis W. Frank]

expect() is nice and simple right now and that's a plus to the code.

Using expectAll would require all matchers to change, which I think could lead to a lot of maintenance and/or additional complexity to all matchers.

A custom matcher, only used in certain cases, is more in the spirit of Jasmine.

On Sun, Mar 17, 2013 at 9:44 AM, Liam Goodacre <goodac...@gmail.com> wrote:

As for universal quantification, you could use a for each loop:

//  Forall a in A, a matches /foo/

elemList.forEach(function (elem) {

  expect(elem).toMatch(/foo/);

});

//  Forall a in A, a matches /foo/

_.each(elemList, function (elem) {

  expect(elem).toMatch(/foo/);

});

However I do like how some of these look:

expect(elemList).all.toMatch(/foo/);
expect(elemList).each.toMatch(/foo/);

expect(elemList).some.toMatch(/foo/);

expect(elemList).none.toMatch(/foo/);
expect(elemList).all.not.toMatch(/foo/);

...

Regards,

Liam

On Tuesday, 12 March 2013 14:40:32 UTC, Andre Asselin wrote:

I was wondering if there is any interest, or any work queued up to extend expect() to check all/one element of an array.  Something like this:

expectAll(someArray).toBe(42)

where the expectation would be true if EVERY element of the array was 42.  Similarly, something like

expectOne(someArray).toBe(42)

would be true if at least 1 element of the array was 42.  In other words, these are the mathematical Universal ∀ and Existential ∃ quantification.

Frisbyjs has something like this for REST testing work, and it's quite useful there, but it occurs to me that this would be a generically useful.

I can work up some patches if there's interest.

Any thoughts on what the syntax should look like?  I can imagine a few alternatives:

expectAll(someArray).toBe(42)             expectOne(someArray).toBe(42) / expectExists(someArray).toBe(42)
expect(someArray).all.toBe(42)             expect(someArray).one.toBe(42)

- Andre Asselin

--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jasmine-js+...@googlegroups.com.
To post to this group, send email to jasmi...@googlegroups.com.
Visit this group at http://groups.google.com/group/jasmine-js?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
thx,

--dwf

[Andre Asselin]

Actually, expectAll doesn't require the matchers to change at all.  I uploaded an initial patch (against 1.3.1) to my github here: https://github.com/asselin/jasmine/commit/23e8b74e244102b416df5823dabcafbe8dc78a96

In a nutshell, the work is done in jasmine.Matchers.matcherFn_().  The jasmine.Matchers constructor is extended to take an additional parameter to indicate Precisely/All/OneOf, and then in matcherFn_ is where the looping happens (if necessary), calling the matcher function once for each array element.

So, this can delivered as new function in Jasmine without breaking the API, and eliminate the users from having to write all this looping boilerplate code over and over again.

If there's hope of picking this up, I'll continue development-- write the tests for OneOf, write the patch against 2.0, etc.  I'd also like to solicit comments on any other requirements that would have to be met before merging.

Thanks...

- Andre Asselin