You can clone with
Is there a way to mark a step as skipped?
We try to represent all important requirements in our feature files.
A side effect of that is that it won't be possible to run automatic tests of everything (Flash, UI look and feel, etc).
The simple way of handling this is just adding step definitions for those steps, but not actually doing anything in those steps (just letting them pass). That's what we've been doing so far. However, that way it is hard to measure how many, and which, steps are not being run.
Does Behat have support for this? If not, would it be a good idea to add?
Behat could supports this. But the problem with skipped approach is that you blow up your context dictionary with useless definitions. I'll think about ways to solve your problem in cleaner way.
I would add support for throwing Behat exceptions in pre- hooks. This way, you'll be able to throw PendingException in tagged BeforeScenario hook to mark this scenario steps as skipped.
After little bit thinking, i wouldn't do anything with it. Problem with adding exceptions handling support into hooks is that we'll make things more complicated even for your own team. Just imagine you've added some named or tagged hook to skip specific scenarios altogether. 1 month later someone starts adding normal scenario, but which will be evaluated by your hook as applicable. What user will see is that scenario will start skipping without meaningful (for him) reason and he'll not be able to understand why, without looking at the context code and searching for this specific hook. So no, it's bad way to extend Behat.
What i propose for you instead is to use tags and tag filtering. You can mark scenarios, that shouldn't be interpreted by Behat with specific tag like @ui-specs. And in behat.yml you can just do that:
After that, behat will simply ignore this scenarios. With this way, you can even ignore whole features by adding tag above feature keyword.
Hmm... I see what you mean.
The idea with marking scenarios or features with separate tags is maybe not the best option for us, since we (currently at least) mix "steps that do/test something" and "steps that are empty" (since we can't do anything with them).
Examples of these steps might be CSS styling, positioning, color – things that we've decided not to test with Mink (yet), but we still want to have in our features since they are a part of the customer requirements.
@MPV i would suggest using Gherkin parser directly and rendering customer features report by hands. This way you'll be able to generate whatever you want. And it's really easy. It would require something like 50 lines of simple code.