Retain file filter when specs are additionally filtered by grep param.

[nruth]

When I click a particular spec I expect only it to run.

Currently, the link has grep but not file, and results in other specs running as well (as seen by their console.log output). Our project has some units with quite similar tests, so grep hits more than one.

Instead, I'd like the url file param to be kept, and the grep param added to it.

It looks like this should be fairly easy to do so I'll try to make a PR.

[jejacks0n]

it can't determine the file that a spec exists within.. if you can figure that crucial aspect out it might be doable -- from the command line however, you can specify a specific spec file to run, and as long as you've setup your dependencies correctly (eg. requiring only the files that are needed for a given spec file) you get the best speed and load times.

[nruth]

is there some way to add/remove the spec filters in place?

[nruth]

@link = "?grep=#{encodeURIComponent("#{@spec.module}: #{@spec.name}")}"
@link = "#{@link}&file=#{encodeURIComponent(fileFilter)}" if fileFilter?

the missing part is getting the fileFilter string from the params or teaspoon somehow?

My point is that it doesn't need to figure out which file the spec is inside of, only keep using the file it's already been told to use by the user.

[jejacks0n]

you can't determine that from the spec "title" -- the file is unknown at that time, and javascript has no way to reference the file that a given function is defined within -- as far as I'm aware in the browser.

[nruth]

That's a shame, but if the user has clicked a specific file from the "default" page, and the file is in the url query params, is that available? That'd be enough.

[jejacks0n]

I see what you're getting at.. if you're focused to a specific file, it should retain that file and add the grep param. That's a valid point, and would not be too difficult. Would accept a PR with that for sure.

[jejacks0n]

so the answer is yes, you can give that a shot manually and it should work as you'd expect. I am unsure why that wasn't something that was added initially, but the concept of the suite page was a bit of an afterthought and so may not have been fully baked at the time.

[nruth]

Could you advise the right way to read the params from inside the Teaspoon.Spec class? I've not done any browser & terminal js dev before.

[nruth]

I've copy-pasted together the urls myself a couple of times so pretty sure teaspoon can handle it :)

[jejacks0n]

To be honest, I thought I added this concept -- which is why I provide an interface to remove one.

[jejacks0n]

interestingly you can do this from the CLI by providing a filter (-g or --filter), and specify a file/files to limit that to.

teaspoon -g "bar" spec/javascripts/foo_spec.js

[nruth]

I think Teaspoon.params is what I was looking for.

I'll experiment a bit on my fork and when it's working and has tests (was thinking add to the ruby integration tests) I'll send a pr?

[nruth]

I'll come back to this and do a pr with tests when my computer's back from repairs (struggling with windows now). Probably a couple of weeks.

Will see if I can do something more general than this params hack for qunit too.