Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a global `only` flag to improve TDD experience #524

Closed
rluba opened this issue Feb 19, 2016 · 13 comments
Closed

Add a global `only` flag to improve TDD experience #524

rluba opened this issue Feb 19, 2016 · 13 comments

Comments

@rluba
Copy link
Contributor

@rluba rluba commented Feb 19, 2016

The current only flag only disables other experiments / tests within the same test file. From the documentation:

This doesn't mark all other experiments and tests in a suite of scripts as skipped, instead it works within a single test script.

But during TDD in a codebase with many, many test files, I want solely run all tests in a particular experiment very frequently while implementing a new feature — because always running all test files slows down each iteration unnecessarily. With mocha, I can simply mark the corresponding test suite with .only(…) during TDD development.

Lab has no such feature and the existing only flag is useless because I rarely have more than one experiment per test file.

If there’s interest in a global only flag similar to mocha’s describe.only, I’ll try to submit a PR to implement it. Any name suggestions? How about {exclusive: true}?

@antony

This comment has been minimized.

Copy link

@antony antony commented Feb 19, 2016

I for one would give a million upvotes for this. I've stopped using and removed Lab from all of our projects , and this is one of the core reasons. If it were fixed, I'd happily go back to it.

I would also vote for .only .exclusive etc as an alternative to using {only: true} et al. I like the fact I can use an options object in the test signature, but I also find it inconvenient. I find using it.only, describe.only much more preferable.

In fact I might suggest we change the purpose of 'only' (this isn't breaking, because people only use it temporarily, right?) to reflect the behaviour of every other test runner out there, and add a new flag, like 'here' or something which applies only within a single JS file.

@Marsup

This comment has been minimized.

Copy link
Member

@Marsup Marsup commented Feb 19, 2016

The .only/.skip is supported since a very long time.

@rluba

This comment has been minimized.

Copy link
Contributor Author

@rluba rluba commented Feb 19, 2016

@antony Sounds great. I’d prefer to change the meaning of {only: true} / .only( to match that of other frameworks, if that’s possible without alienating existing users.

@Marsup Really? I did not know that. Then we should probably add it to the "usage" documentation.

@geek geek added the documentation label Feb 19, 2016
@geek

This comment has been minimized.

Copy link
Member

@geek geek commented Feb 19, 2016

@rluba @antony another option is to use the index argument... this is how I accomplish what you are describing. I think its a bit better than only because it requires no code changes.

Usually, I will do lab -dv to get a list of tests... then If I want to run a subset run lab -i 4-7, that will run tests numbered 4 through 7. This also accepts a comma if you want to do a varying range. lab -i 4-7,9 also, if you want to only run test 4 you can run lab -i 4

@rluba

This comment has been minimized.

Copy link
Contributor Author

@rluba rluba commented Feb 19, 2016

@geek That’s quite a crutch and does not support my workflow: I usually start a gulp watch task that re-runs the tests upon every file change. Then I set a .only on the current experiment, develop a feature, switch the .only to the next experiment, develop the next feature, and so on. While doing this, I add tests all the time.

So the required index range would change frequently (error prone!) and I’d have to re-run lab manually for every iteration.

@geek geek added the request label Feb 19, 2016
@geek

This comment has been minimized.

Copy link
Member

@geek geek commented Feb 19, 2016

@rluba I am open to the change... not sure on naming. We can rework only to work on a suite wide level instead of just a single file/describe level. I am open to a PR :)

@Marsup

This comment has been minimized.

Copy link
Member

@Marsup Marsup commented Feb 19, 2016

I'd encourage you to look at #116 and adapt to new lab code base, since that was exactly how I designed it originally.

@rluba

This comment has been minimized.

Copy link
Contributor Author

@rluba rluba commented Feb 19, 2016

@Marsup The comments on #116 are a great read – classic Eran ;-)

@geek

This comment has been minimized.

Copy link
Member

@geek geek commented Feb 19, 2016

@Marsup :) really prefer the global .only style over how we are doing it now. I will have to go back and see what you did originally.

@rluba

This comment has been minimized.

Copy link
Contributor Author

@rluba rluba commented Feb 20, 2016

@geek Are you working on it? I read the lab codebase yesterday and it’s really well named and structured – I could give it a try. Seems like a simple task.

Shall we keep the old "local .only" behavior around? I don’t know a use case where it’s superior to a global .only but we could rename it to skipOthers, fileOnly or something similar — if anyone needs it.

@antony

This comment has been minimized.

Copy link

@antony antony commented Feb 20, 2016

I feel like local only is pretty pointless because in most cases you have
to use it with something else. I personally wouldn't miss it.

I also think if we did keep it, it would be hard to name well.

Index is interesting, but for similar reasons to Raphael it doesn't work
for my default case.

On Sat, 20 Feb 2016 00:20 Raphael Luba notifications@github.com wrote:

@geek https://github.com/geek Are you working on it? I read the lab
codebase yesterday and it’s really well named and structured – I could give
it a try.

Shall we keep the old "local .only" behavior around? I don’t know a use
case where it’s superior to a global .only but we could rename it to {skipOthers:
true} or something similar if anyone needs it.


Reply to this email directly or view it on GitHub
#524 (comment).

@gergoerdosi

This comment has been minimized.

Copy link
Contributor

@gergoerdosi gergoerdosi commented Feb 20, 2016

I agree, only should be global. We have a new developer and had the exact same problem - how to run only one test. I don't think there is a need to keep the current behavior.

@geek

This comment has been minimized.

Copy link
Member

@geek geek commented Feb 22, 2016

@rluba @antony @gergoerdosi agreed... @rluba feel free to correct the existing only behavior to apply globally and I will release it as 10.0.0. Thanks!

geek added a commit that referenced this issue Feb 24, 2016
Global "only" (#524)
@geek geek added this to the 10.0.0 milestone Feb 24, 2016
@geek geek self-assigned this Feb 24, 2016
@geek geek added feature breaking changes and removed request labels Feb 24, 2016
@geek geek closed this Feb 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.