Focused tests and describes

[mackwic]

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]

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]

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]

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.).