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

Core: Connected to #1434: run all only tests #1436

Merged
merged 3 commits into from
Apr 30, 2020

Conversation

ventuno
Copy link
Member

@ventuno ventuno commented Apr 19, 2020

WIP alternate implementation of #1434: modifying the way only behaves instead of adding a new method.

TODO:

  • docs;

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for implementing this approach as well! @qunitjs/core any of you have thoughts on this approach over #1435?

@ventuno
Copy link
Member Author

ventuno commented Apr 23, 2020

Thanks @trentmwillis, let me know which approach is preferred and I'll complete this by adding docs :-).

@ventuno ventuno changed the title Core: Connected to #1434: run all only tests. [WIP] Core: Connected to #1434: run all only tests. Apr 23, 2020
@smcclure15
Copy link
Member

I'm in favor of this "running all only's" behavior. The new logic is clear ("run only these!"), where the current algorithm was a little fuzzy on which on won. The "run some" approach with a different API has a lot of behavioral overlap (two ways of doing the same thing). It helps close this gap, but introduces more fuzziness with it.

I don't think this change should be cause for a major semver bump, just a minor.

@Krinkle
Copy link
Member

Krinkle commented Apr 24, 2020

Thanks for implementing this approach as well! @qunitjs/core any of you have thoughts on this approach over #1435?

I'm +1 on improving module.only over introducing another method. To me this is a "Do what I mean" kind of thing where I see no harm from letting multiple run, if the flag is applied to module test suites.

As I understand it, its design was limited to one as a way to to avoid mistakes, not per se because it would be undesirable to support multiple.

I do note that if we change this behaviour, the docs should be updated as well. In particular, at https://api.qunitjs.com/QUnit/only it currently says:

Note that if more than one QUnit.only call is present, only the first instance will run.

@ventuno
Copy link
Member Author

ventuno commented Apr 24, 2020

Thanks @Krinkle, as we seem to be leaning towards changing only's approach I just pushed related doc changes. Please let me know if that looks good :-).

@ventuno ventuno changed the title [WIP] Core: Connected to #1434: run all only tests. Core: Connected to #1434: run all only tests Apr 25, 2020
Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this looks great! A few small suggestions for the documentation and one question about the actual implementation: does this handle nested modules properly? For example, if you had:

module.only('One', () => {});
module.only('Two', () => {
  module('A', () => {});
});

Would module A run?

I'm pretty sure the following would work:

module.only('One', () => {
  module('A', () => {});
});

But I think if a module.only is followed by another module.only with the second one having nested modules, then the nested modules won't run (even though I think a user would expect them to).

docs/QUnit/module.md Outdated Show resolved Hide resolved
docs/QUnit/only.md Outdated Show resolved Hide resolved
docs/QUnit/only.md Outdated Show resolved Hide resolved
@ventuno
Copy link
Member Author

ventuno commented Apr 26, 2020

But I think if a module.only is followed by another module.only with the second one having nested modules, then the nested modules won't run (even though I think a user would expect them to).

Thanks @trentmwillis, I agree that modules nested inside a module.only should run as well. Thanks for catching this. I addressed (and tested) this, let me know if my solution looks good: I'm looking at the list of parent modules and if any is in the queue then I assume this module should run as well.

Copy link
Member

@trentmwillis trentmwillis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Thank you! I'll probably release a new version this weekend.

@trentmwillis trentmwillis merged commit 73ea896 into qunitjs:master Apr 30, 2020
@ventuno
Copy link
Member Author

ventuno commented Apr 30, 2020

Thanks @trentmwillis. Looking forward to it :-).

@ventuno ventuno deleted the ftr-1434-only branch April 30, 2020 19:38
@trentmwillis
Copy link
Member

Released in v2.10.0!

@ventuno
Copy link
Member Author

ventuno commented May 4, 2020

Thanks!

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

Successfully merging this pull request may close these issues.

None yet

4 participants