Remove redundant edge-case scenarios

[mvz]

Summary

Let's improve Aruba's cucumber features as a source for documentation by reducing the number of edge case scenarios.

Expected Behavior

Aruba's documentation summarizes clearly the use of its methods and cucumber steps

Current Behavior

Several feature files list endless edge cases, for example, running an external script with ruby, python, bash, zsh, with alternative step wording.

Possible Solution

Some combination of the following:

• Change the wording of introductions of the feature files to more clearly serve as documentation.
• Remove superfluous scenarios
• Move testing of technical edge cases to the spec suite.

Context & Motivation

I want to make Aruba's documentation better and clearer, and reduce the time our tests take to run at the same time.

[maxmeyer]

@mvz That's a great idea, I think I can add some context to why I added some of the tests.

1. Other programming languages

   Some time ago I had discussions for what kind of projects aruba is suitable. Is it Ruby only or can it be used for other programming languages as well. To make this explicit I added those tests.

2. Test Step wording

   I consider all of aruba's steps as part of our public API. For that reason I added tests for them. @mvz What do you think? I see the problems this causes. But what caused a lot of trouble on refactoring Aruba in the past, are the missing tests for our public API. Besides that, it was totally unclear what can be considered part of the public API - e.g. Please consider restoring #regexp (removed in 0.6.2) and/or clarify what your public APIs are #227.

3. Test install procedures and other setup stuff

   As we use Cucumber Pro - and its predecessor - for our documentation I thought it might be a good idea, but write that as a feature describing it. I'm aware that this doesn't really is a good use case for feature tests. So I'm open for suggestions about how we can improve this. The problem with "simple" documentation is its lifecycle. As you improve/modify the library documentation gets outdated. If the documentation is "implemented" as a tests, it breaks and we as developers get a notification about that. I recently start using Go more and more. What I like there are the examples you can write down, along with your code.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

[mvz]

The RSpec repos have a similar policy, where edge cases must be checked in the specs, and the cukes are used for documentations.

[mvz]

Related to #685.