Focused tests and describes
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.
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.
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.
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.).