"describe"s match name greedily #564

Closed
montlebalm opened this Issue Mar 26, 2014 · 8 comments

Projects

None yet

5 participants

@montlebalm

Given this set of tests:

describe("on", function() {
    // Several "it" tests
});

describe("once", function() {
    // Several "it" tests
});

In the HTML test runner, if I click the "on" category to narrow my scope it will also run "once" tests. This is reproducible with any "foo" and "foo*" combination.

I'm running Jasmine 2.0 with Jasmine-html loaded via RequireJS.

Contributor
infews commented Mar 27, 2014

Can you provide a pull request that models the behavior and the fix you expect? Is this a real world case that you've run into?

I'll see what I can do about a pull request. I ran into this on one of my projects where I was testing a pub/sub system. The specific case is:

describe('events', function() {
    describe('on', function() {
        // ...
    });
    describe('once', function() {
        // ...
    });
});

When I'm debugging failed calls I'll often click on the category to narrow which tests are being run. I noticed that both "on" and "once" were being executed when the "on" category was in focus. This specific case was the only time it came up for me, but I was able to easily reproduce it with other combinations.

harriha commented Mar 31, 2014

I've ran into this too, and find it fairly awkward. My current project has a quite massive set of specs for components divided into "namespaces", so if I try to run specs for only component foo, also specs for (possibly unrelated) component bar.foo gets run.

Contributor
ragaskar commented Apr 1, 2014

IIRC this was intentional such that you could run 'focused suites' (since the describe string would be contained in all specs). I'm not sure if we've changed suite running so that this is no longer necessary. That said, it should probably only match from start of line.

Looking at the code, it looks like there might be a workaround in which you could drop a "^" into your spec filter string and have it match from start.

harriha commented Apr 1, 2014

I personally see the use case for this current not-so-strict matching, but in some projects I would prefer the matching to be strict.

Based on quick smoke-testing, seems that I can override the jasmine.HtmlSpecFilter (or modify env.specFilter) in boot.js and customize the behavior there. This seems to be a valid workaround at least in my case, not sure if you would consider finding some kind of official solution for adjusting this (env variable for strict/non-strict matching or something).

Contributor
infews commented Aug 27, 2014

@montlebalm - is this closable, per the comments of @harriha ?

@infews infews added the waiting label Aug 27, 2014

@infews this can be closed if the behavior is intentional. I can find a workaround for my projects or use different names with describe.

Owner

This is the desired behavior for right now, due to how the rest of filtering works.

Closing, but if someone wants to take a crack at a pull request that would keep the current functionality, but allow some way to specify more exact matches, we'll definitely take a look at a pull request.

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