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

Focused tests and describes #17

Open
mackwic opened this issue Jul 23, 2016 · 3 comments
Open

Focused tests and describes #17

mackwic opened this issue Jul 23, 2016 · 3 comments

Comments

@mackwic
Copy link
Member

mackwic commented Jul 23, 2016

The famous fit, and fdescribe !

Role: when used, only the focused tests are run. This needs a change in design to report to the runner that we are in focus mode. Not big, though.

Note: if #6 or #5 are implemented, the aliases also needs their focused counterpart.

@regexident
Copy link
Collaborator

We already have 3 × 3 functions for creating suites/contexts/examples.

Any further addition of focussing variants (9 more functions each!) would be a bad idea, imho.

Instead we should consider adding support for tagging one's suites/contexts/examples, with which in place one could realize skipping by simply negatively filtering for a given tag.

The same applies to Skipped tests and describes.

@mackwic
Copy link
Member Author

mackwic commented Oct 28, 2017

I don't agree. It works very well on other test suites so I don't see any reason to diverge on that.

Yes, tagging would do it. Or it could not, and just bring creep to our lib when we have a very specific and narrow need. Or tagging could be used in intern with an another method on the frontend.

@regexident
Copy link
Collaborator

Do we want a public of 27+ ((suite + describe + given) * 3 * (normal + focus + ignore) = 27) methods mapping onto 9 actual semantic distinct functionalities?

We would need to store an enum FilterState { none, focus, ignore) in each suite/context/example, at which point we might just go ahead and add a tag instead, which would allow for (future) expansion.
With dedicated focus/ignore we would end up with non-orthogonal duplication as soon as we one day decide to add tags or any other kind of filter functionality (“smoke test” e.g.).

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

No branches or pull requests

2 participants