karma-jasmine: Changes in 3.1.0 break custom karma-jasmine-html-reporter spec filtering

As the latest version does a strict equality comparison, the filtering with suite name does not work anymore.

I am try to filter a suite from browser using the url http://localhost:9876/debug.html?spec=MySuite or by clicking the generated suite link (same url). It results in following error.

adapter.js:344 Uncaught Error: No spec found with name: "MySuite"
    at getSpecsByName (adapter.js:344)
    at getDebugSpecToRun (adapter.js:354)
    at getSpecsToRun (adapter.js:429)
    at new KarmaSpecFilter (adapter.js:435)
    at createSpecFilter (adapter.js:452)
    at ContextKarma.start (adapter.js:479)
    at ContextKarma.window.__karma__.loaded (debug.js:27)
    at debug.html?spec=MySuite:53

Ideally, the generated links should work.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 3
Comments: 20 (8 by maintainers)

Commits related to this issue

fix(filter): match any portion of a spec name (#270) jasmine tests are named suite-name + spec-name. The links printed by karma-jasmine-html-reporter include links for suite-name (only). To support ... — committed to karma-runner/karma-jasmine by johnjbarton 4 years ago
chore(release): 3.3.1 [skip ci] ## [3.3.1](https://github.com/karma-runner/karma-jasmine/compare/v3.3.0...v3.3.1) (2020-05-28) ### Bug Fixes * **filter:** match any portion of a spec name ([#270](h... — committed to karma-runner/karma-jasmine by semantic-release-bot 4 years ago
fix(filter): match ONLY START portion of a spec name jasmine tests are named suite-name + spec-name. The links printed by karma-jasmine-html-reporter include links for suite-name (only). To support r... — committed to parloti/karma-jasmine by parloti 4 years ago
Client: Degraded `karma-jasmine` to version `3.0.3` Allows filtering in Web based debugger again, see https://github.com/karma-runner/karma-jasmine/issues/256#issuecomment-609949165 — committed to MarcusRiemer/esqulino by MarcusRiemer 4 years ago

Most upvoted comments

What’s the reason for setting the specFilter at that stage in the process?

Well to be sure the reason is simple: no test fails when I made that change.

@johnjbarton that’s fair. Would you be willing to accept a PR that places the code back in adapter.js and adds a test for a spec filter override?

Thanks for the awesome work maintaining Karma. It’s a very important development tool. ❤

nicojs on Apr 23, 2020

I reverted back to “karma-jasmine”: “~3.0.3” and all works fine in WebStorm Please fix the newest version as well.

tscislo on Feb 2, 2020

I think this also broke running individual specs in IntelliJ IDEA / Webstorm, which specifies suite names in the form of regex patterns, ie. ^reservation-form component customer autocomplete .

mpaluchowski on Jan 13, 2020

I can confirm that karma-jasmine: 3.0.3 together with karma: 4.4.1 works as expected: If I click a section created by describe() in the HTML-runner I get a URL with a partial path and all specs that are a subset of that path are executed:

screenrecord-filter-works

With karma-jasmine: 3.1.1 I only get the Error: No spec found with name: "OverviewBlockLanguageComponent" output in the dev console:

screenrecord-filter-borked

MarcusRiemer on Apr 6, 2020

@johnjbarton The specFilter is now set in createStartFn so it’s set at window.__karma__.start instead of when adapter.js as a file is loaded (previous behavior). This causes all other use cases of specFilter to be overruled by karma-jasmine.

What’s the reason for setting the specFilter at that stage in the process? Would it be possible to either set the specFilter at the previous stage in the process or to not override the specFilter if a custom one has been set?

simondel on Mar 13, 2020

🎉 This issue has been resolved in version 3.3.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

karmarunnerbot on May 28, 2020

What I meant is that if there are following suites, then http://localhost:9876/debug.html?spec=MySuite fails to run all the specs from the suite MySuite.

describe('MySuite', function(){
 it("works1", function(){...});
 it("works2", function(){...});
});

describe('FooBar', function(){
 it("works1", function(){...});
 it("works2", function(){...});
});

AFAIK, previously the match was resolved by using a regex. With the new update the match is done by strictly comparing 2 strings. This does not work as the items in specs list has name in following format: ${suiteName} ${specName}. Thus, naturally the comparison fails when the spec name (from the querystring of the generated URL) contains the suite name.

Sayan751 on Jan 13, 2020