Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Cucumber and Ruby

Acceptance testing
by

Philip Cox

on 12 July 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Cucumber and Ruby

Ruby Recap (What you're going to need) Methods require vs include/extend require works similarly to 'using' in C# (usage) No explict return
Can use ? in ! method names
Can redefine later Blocks Can sometimes be used like methods, really a special way to call a kind of method or... include & extend is kind of like inlining code Modules Classes Can be used like C# abstract classes, also as a type of namespace Ruby modules are often 'mixed-in' to classes. But first we'll need to understand classes... Cucumber who knows why it's called this??? What's the point? Communication Thinking/Reasoning Automation Specification It is a bridge between non-technical domain experts (or at least those who are responsible for driving the project) "Eh? What do you mean after you press the 'next' button, I thought that would happen before anything else..." "No, no, let's change this to say..." "yes, that's fine but what if..." Provides a basis for discussion Plain English (or rather natural language) If your domain experts can't read it it is wrong! Top down approach (test driven) Features should keep you focused on what the point is Scenarios show the specifics QA, or even domain experts, may add new scenarios or suggest new features. (Normally it will be collaborative with QA and Dev doing the majority of work. However it does happen that interested domain experts are able to contribute autonomously.) Everyone can be more confident of specifications (This will be even more the case when we can give the business a general and easy-to-use method of viewing the features and scenarios. There are some interesting web-apps for just this. Also Jira may be an option.) Also doubles as documentation Regression Early warning We can get to the point where parts of the site are fully automated we will have higher confidence that our changes haven't screwed up something. May pave the way for continuous deployment Better to know on Day 2 that there's a problem caused by your changes you did this morning. ... rather than after dev complete Anatomy of a feature features Scenarios Steps Gherkin (the technical name for the feature file grammar) Tags, useful for organising/running (Although a bit scary for non-technical users.) Description (optional) Has 3 parts:

WHY (In order/So that)
WHO (As a ...)
WHAT (I need/I want) (Note, first person) Describes at the level of a story (this is a general rule of thumb.) Should not attempt to explain all the details, try to keep it short and sweet. If you can't reduce it to a couple of lines consider whether you're looking at more than one feature/story. Can be structured English Or unstructured Unstructured. Less common for us, but can be a simple paragraph or two of text. This can be good for describing more complex elements e.g., an algorthim. Keep in mind though this is a feature: a conceptually related unit 'thing'. Beware of using unstructured text instead of splitting into two or more features. You can reasonably have "In order I can book a table at my preferred time" in another feature file. Perhaps as part of the search. Similarly "I need to pick one of the offered time slots" could form the action of another feature, e.g. selecting an order.

A structured english style feature has an identity according to it's mix of why/who/what.

A feature file should be short. Don't try and cram everything in But what about the details? A scenario is a concrete list of steps which demonstrate the functionality desired. Typically there will be a 'Happy Path' scenario and a number of 'Alternate Paths'. All features have at minimum have a line that starts 'feature:' and continues with a title The feature name should be short and snappy. Due to the way we structure directories the context should be obvious (but don't treat it as such) If features are the why/who/what, scenarios are the where/how. Nobody wants to fill in forms no one normal anyway Ruby, annoying in some ways not to be using something like spec flow but... It has the advantage of being completely agnostic as to the technology implmeneting it. Tempting short-cuts don't exist, which is good because often these end up being a factor in our thinking (oh but then it would be hard to do such and such testing... no, because x relies on this 'hack' thing.. etc.) Also, less convincingly, some say you should always test in a more 'powerful' language. Finally Cucumber was built in Ruby to start with it has good support from Capybara and friends, and it's more friendly, we hope, to our tech literate QA team. And so, of course, I must go in search of this useless factoid, luckly the RSpec book can shed some light on the matter: In the spring of 2008, Aslak Hellesøy set out to rewrite RSpec’s Story Runner with a real grammar defined with Nathan Sobo’s Treetop library. Aslak dubbed it Cucumber at the suggestion of his fiancée, Patricia Carrier, thinking it would be a short-lived working title until it was merged back into RSpec. Little did either of them know that Cucumber would develop a life of its own. How we roll Me, not so long ago. Bad me! What's wrong with it? As a potential diner. So that's who I am, someone by definition looking to dine. (We're particularly interested in these types of people.)

I know want to eat, and when I want to eat it. I don't really care how I do that. Also, I don't really know what a timeslot is. Don't worry if it takes you time to get a feature or scenario right. You're trying to get an insight into what it is the business is aiming at. Sometimes this is by no means easy. Revise, refactor, revisit.

It's a poem, not an essay. A quick aside... Step back, why am I (the potential diner) even on this page? I came here via a search of some kind (internal or search engine) and I'm therefore, presumably, at least open to the idea of booking this restaurant. So Now I want to see if it's even possible to make the kind of booking I want: tomorrow, for lunch with two clients. A better feature: Generally name your feature file in as feature_name.feature Where the rubber meets the road ToW Background Tables Scenario Outlines A rule I try and follow in my scenarios is whether I could read the scenario as-is over the phone to the person noted in the feature? "Everything should be made as simple as possible, but no simpler" -- Albert Einstein Much like features a scenario must start with 'scenario:' followed by a title Given The setup needed for the test

Avoid unecessary cluttering

Ands and Buts

Usually needed Actually the example given could be improved. Whilst the logged in or not is relevant to the example "WA Test Venue" is somewhat questionable.

Perhaps this should be hidden away in a 'background' section (covered in a moment) or else renamed to something like '"Restaurant with availability".

Discuss. } When The action, the thing the user does to set everything in motion.

Try to keep it down to one or two at most per scenario

Not always needed Then The expectation of the scenario

As with Given/When statements you can use as many Ands/Buts wanted.

All scenarios should have at least a Then statement (otherwise what's the point?) More advanced syntax... Quite often the setup for each scenario in a feature is necessaryly similar... And whilst important from a context point of view it is distracting noise. So for example: becomes... Quoted strings Sometimes you'll need to repeat the same scenario structure over and over again. boring! Instead fo all this repetition we would like to extract the common elements and just note the differences between each one. { { template section examples section Occasionally it would be clearer to list out some part of the scenario without the fluff of a fully formed sentence. ... in our code-base examples are scarce, so here's an example from the interwebs: source: http://cuke4ninja.com/sec_sets_of_attributes.html headings content More of a convention, although it may have consequnce for your step definitions... Only one content line is used in this example, but it should be clear how more than one can be added. ( I am generally wary of when I see tables being used. Sometimes they can be a great solution, but they are also open to misuse. Bottom line: does it make it simpler to understand the scenario? If yes, but still complex perhaps your scenario is trying to do too much and should be split into smaller more focused scenarios. ) WARNING Tags As with features, scenarios may be decorated with tags So, for example: Other possibilities may include: It is at this point the human friendly text is connected to something the computer can understand.

In our case via the Ruby languauge. Steps Each of the Given, When, Then, And and But lines are called 'steps' (Ruby code) Each step is matched to a 'step definition' (We'll come to exactly how this happens later on.) This then uses a Ruby library, called Capybara, connected to a utility call Selenium which is used to drive the web browser Firefox 3.6, but it should be possible to run against, say, Chrome. After which the success or not is shown Lather, rince, repeat. To know more we're going to have to recall some Ruby stuff.
Full transcript