What We Just Learned

With these few examples, you should know enough to start automating tests for your own command-line applications. Let’s review what we have learned:

• Command-line applications all look the same from the outside, whatever language they’re written in.

• We can verify that a command-line application prints what we expect it to print.

• We know how to check that a command-line application exits with a specific exit status.

• You can create temporary files that the command-line application you are testing can use.

• Aruba uses an empty, temporary directory for each scenario.

• Aruba recognizes special tags that let us see more informative output.

• We can use Aruba to interact with simple command-line applications that ask for user input.

We haven’t been through every step definition of Aruba in this chapter, but we have shown you the most important ones. If you want to learn more about the step definitions we haven’t covered, the best place to look is Aruba’s own Cucumber features on GitHub.^[71] They provide examples of how to use Aruba.

Aruba’s built-in step definitions provide a useful starting point for testing your own command applications, but you shouldn’t let them have too much influence on how you write your scenarios. Make sure that your scenarios are written in your project’s domain language so that they make the most sense to you and your team.

Try This

Create your own simple command-line application: a script that takes all its command-line arguments, changes them to uppercase, and prints them to a file called result.txt.

Verify that the file result.txt contains the arguments you passed on the command line, all in uppercase. You should be able to do that using only Aruba step definitions, without writing a single step definition yourself.