Ian Dees - Cucumber Recipes: Automate Anything with BDD Tools and Techniques

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

There was a time when one could analyze all that a program needed to do and then write the program that met that need. This stopped being a winning strategy when computers got big enough and fast enough to hold a description of the problem, not just the solution.

I embraced this change that went by the name of object-oriented programming . The advice was to divide large programs into parts that captured natural diversity. Then we were to program the parts to ask other parts for results without saying exactly how these results were to be achieved. This sounded simple. We no longer had to think everything through all of the time. Then, when we discovered one more case late in development, we were thankful we kept that complexity at a distance.

It was a good plan, but it turned out to be not quite that simple. Not only was there more than one way to chop up a program into parts, there was no easy way to tell which approach was going to prove to be leveraged when unforeseen needs surfaced, as they always do.

We forged ahead. We found dozens of techniques that helped keep track of what we had done, where we were going, and, especially, how to say yes, we can when asked to do something never once mentioned until our programs were used. When we say Agile today, were distinguishing ourselves from the days when we would resist change even if it meant finishing a program that wouldnt be used.

We asked our pioneers to experiment. We asked that they try new things and share with each other how they worked out. We asked our best developers to think about these new problems: where have we been, where are we going, and how will we know when we get there?

This book carries that tradition forward. Let me explain how.

A program is a mathematical object that follows precise rules. This stops being important when we can no longer fully analyze our problems as we might a proof. Our progress toward Agile accelerated when we started cataloging solutions rather than deriving new ones from scratch each time they occurred.

A recurring pattern became an object of interest. A recurring problem in a context and a solution known to workthis is something worth sharing. When we started naming and documenting these patterns, we created a literature that had not yet existed. Practical problem solving was respected. Well-worn solutions were judged valuable...more valuable even than the most innovative ideas.

Although Cucumber offers a new and innovative way of pushing Agile forward, there is no reason for every Cucumber user to rediscover the contents of this book. The solutions come from many, for sure. But the simple existence of this catalog will raise our collective competence as we come to know of solutions whether we need them right now or not.

This book covers lots of ground. Some of it you will use immediately; other parts you will later. However, you will be served well to know the range of problems already solved.

We appreciate how computers become more powerful each year. We hardly think of them as computers anymore. But they still need to be programmed. When we say Agile means yes, we can, we make a promise that becomes more difficult as capabilities proliferate. And each capability has its own constituents that want our attention.

Cucumber makes much of artifacts that can be shared across disciplines. A developer and a business analyst will bring different skills to a project. But if they are to coordinate their work, there must be some things they share. Cucumber meets that need.

This same distance from implementation allows Cucumber to straddle todays diverse implementation technologies. As our customers come to know many platforms, they expect us to know them too. As developers we begin to feel new pressure. Each platform has its quirks. That is where this book excels. As you are pressed into delivery on new platforms, you can bring Cucumber with you. But how do you hook it up? Read how here.