RubyGems - aslakhellesoy-cucumber - Versions diffs - 0.1.3 → 0.1.4 - Mend

aslakhellesoy-cucumber 0.1.3 → 0.1.4

Files changed (4) hide show

data/Manifest.txt CHANGED Viewed

@@ -1,7 +1,6 @@
 History.txt
 License.txt
 Manifest.txt
-README.textile
 README.txt
 Rakefile
 TODO.txt

data/README.txt CHANGED Viewed

@@ -5,6 +5,7 @@
 == DESCRIPTION:
 Cucumber executes plain text documentation of code against that code.
+Documentation: http://github.com/aslakhellesoy/cucumber/wikis/home
 == REQUIREMENTS:

metadata CHANGED Viewed

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: aslakhellesoy-cucumber
 version: !ruby/object:Gem::Version
-  version: 0.1.3
+  version: 0.1.4
 platform: ruby
 authors:
 - "Aslak Helles\xC3\xB8y"
@@ -75,7 +75,6 @@ files:
 - History.txt
 - License.txt
 - Manifest.txt
-- README.textile
 - README.txt
 - Rakefile
 - TODO.txt

data/README.textile DELETED Viewed

@@ -1,191 +0,0 @@
-h1. Cucumber
-"Cucumber":http://github.com/aslakhellesoy/cucumber is a tool that can execute feature documentation written in plain text.
-Cucumber targets non technical business analysts, interaction designers, domain experts, testers (for the plain text part)
-and programmers (for the steps, which are written in Ruby).
-Cucumber itself is also written in Ruby, but it can be used to "test" code written in Ruby, Java (or web applications written
-in any language). When "IronRuby":http://www.ironruby.net/ matures it can be used to "test" .NET code too.
-Cucumber only requires minimal use of Ruby programming, so don't be afraid to try it out even if the code you're
-developing is in a different language. Most programmers should pick up the required Ruby skills and be productive
-with Cucumber in a few of days.
-While Cucumber can be thought of as a "testing" tool, the intent of the tool is to support "BDD":http://behaviour-driven.org/
-This means that the "tests" (plain text feature descriptions with scenarios) are typically written before anything else, and
-the production code is then written outside-in, to make them pass.
-h2. Installation
-After you have installed Ruby or JRuby - install Cucumber with the following commands:
-Ruby:
-<pre><code>gem sources --add http://gems.github.com/
-gem install aslakhellesoy-cucumber
-</code></pre>
-JRuby:
-<pre><code>jruby -S gem sources --add http://gems.github.com/
-jruby -S gem install aslakhellesoy-cucumber
-</code></pre>
-h2. Getting started
-There are several ways to get started, depending on the architecture of your application.
-Take a look at the "examples":http://github.com/aslakhellesoy/cucumber/tree/master/examples.
-Each example directory has a Rakefile, and you can run the features in an example directory with
-<pre><code>rake features</code></pre>
-The examples deliberately have errors so you can get a taste of how the error output looks like. You can get help by asking
-for it:
-<pre><code>cucumber --help</code></pre>
-h2. Ruby on Rails
-Cucumber has very nice Rails support, and I really recommend using "Webrat":http://github.com/brynary/webrat
-in the step definitions. Here is how to get you started.
-h3. Install Cucumber, Webrat and RSpec
-<pre><code>git submodule add cucumber git://github.com/aslakhellesoy/cucumber.git vendor/plugins/cucumber
-git submodule add webrat git://github.com/brynary/webrat.git vendor/plugins/webrat
-git submodule add rspec git://github.com/dchelimsky/rspec.git vendor/plugins/rspec
-git submodule add rspec-rails git://github.com/dchelimsky/rspec-rails.git vendor/plugins/rspec-rails
-</code></pre>
-If your own Rails code is not in Git, just replace "submodule add" with "clone".
-h3. Install Other dependencies
-<pre><code>gem install hpricot cucumber</code></pre>
-Yes, you did already install cucumber as a plugin, but this will install all the dependent libraries you need.
-h3. Bootstrap Cucumber
-You'll need a Rake task and a couple of files that configure Cucumber for use with Ruby on Rails and Webrat.
-You create these with:
-<pre><code>ruby script/generate cucumber</code></pre>
-Check out the generated files. If you need to, you can go and tweak them later.
-h3. Start a feature
-It's really, really recommended that you write your features by hand - in collaboration with your
-customer / business analyst / domain expert / interaction designer. However, to get you started (and so you can see how to use
-Webrat), you can use the feature generator to generate the first few features:
-<pre><code>ruby script/generate feature Frooble name color description</code></pre>
-This will generate a simple plain text feature with associated steps. Don't get addicted to this
-generator - you're better off writing these by hand in the long run. See the BDD tips section below.
-h3. Run features
-<pre><code>rake features</code></pre>
-This should result in failing scenarios, because you haven't written any code yet (I hope). Now you it's time
-to write some code, or generate some. Try this:
-<pre><code>script/generate rspec_scaffold Frooble name:string color:string description:text
-rake db:migrate
-rake features
-</code></pre>
-h3. Tips
-These tips apply to Rails development in general...
-* Talk to models directly in *Given* steps to set up a known state. Don't use fixtures.
-* Use Webrat in *When* steps
-* Use *response.should have_tag(...)* (and models) in *Then* steps to verify the *outcomes* (which are on the screen, not only in the database).
-* Organise steps in files named accordingly to resources used
-* Avoid keeping state in @variables in steps. It will couple your steps and make them harder to reuse.
-h3. View spec redundancy
-Since I recommend you verify outcomes (*Then* steps) by looking at the HTML, you might end up having some degree
-of redundancy with view specs. I recommend you delete generated view specs if you run into too much maintenance
-headaches and rely on the features instead of view specs. However, in some cases it can be handy to use both.
-h2. BDD
-If you have found a bug or want to add a feature, start by writing a new feature or scenario that describes the
-Now run the features again. The one you wrote should have yellow, pending steps - or failing, red ones.
-(If you don't get that you're doing something wrong, or the feature is already implemented).
-This is when you start writing code. You might as well get used to doing it this way, because we won't accept
-any patches unless you also have stories or specs for your code. This is because we don't want to end up with a
-brittle, unmaintainable, undocumented pile of code that nobody understands. (Yes, stores and specs are *documentation* too).
-If you think this sounds annoying, try it out anyway. You'll end up writing better (and less) code this way. Trust me.
-Work outside-in (the outside being the story, the inside being the low level code). Do it the "BDD":http://en.wikipedia.org/wiki/Behavior_driven_development way.
-h3. Business value and MMF
-You should discuss the "In order to" part of the feature and pop the "why" stack max 5 times (ask why recursively)
-until you end up with one of the following business values:
-* Protect revenue
-* Increase revenue
-* Manage cost
-If you're about to implement a feature that doesn't support one of those values, chances are you're about to
-implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on
-implementing the MMFs (Minimal Marketable Features) that will yield the most value.
-h3. Outcomes and bottom-up scenarios.
-The value provided by a system is what you can get out of it - not what you put into it. Just like the value
-is expressed at the top of a feature (In order to...), the value should be in the steps of a scenarios too,
-more precicely in the *Then* steps.
-When you're writing a new scenario, I recommend you start with the formulation of the desired outcome. Write the
-*Then* steps first. Then write the *When* step to discover the action/operation and finally write the *Given*
-steps that need to be in place in order for the When/Then to make sense.
-h2. Background and Credits
-Cucumber is a rewrite of RSpec's "Story runner", which was originally written by Dan North. Dan's original
-implementation required that stories be written in Ruby. Shortly after, David Chelimsky added
-"plain text":http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english support with
-contributions from half a dozen other people.
-The business value guidelines and general wording in features is based on several conversations and blog posts
-by Chris Matts, Liz Keogh and Dan North.
-This brought executable stories a little closer to non-technical users, which is one of the target audiences
-for this kind of tool.
-However, the RSpec Story runner has several shortcomings which is rather common for tools that move into new territory.
-Some of the biggest problems with it are:
-* Hard to get started with. A special "all.rb" file must be written before it can be used.
-* No out of the box Rake support, which puts a lot of people off.
-* No i18n, so if you want to write stories in a different language than English you're out of luck.
-* Poor error reporting. No way to know on what line a plain text story failed during execution or parsing.
-* Limited colouring of output.
-* No simple way to execute only one scenario.
-* No command line tool to run stories.
-* No easy before or after hooks.
-While all of this could have been fixed in the existing codebase, I figured it would be easier to do a rewrite from scratch.
-I also had some ideas for extensions of the story grammar (like FIT style tables that you can see in some of the examples),
-so I decided to base it on a proper
-"grammar":http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/treetop_parser/feature.treetop.erb using
-"Treetop":http://treetop.rubyforge.org/.
-Cucumber addresses all of the above mentioned shortcomings of RSpec's Story runner.
-If the community likes it, perhaps it will replace the RSpec story runner - either by
-being assumed into RSpec proper, or remaining a separate tool like now.
-The term "Feature" has been adopted in favour of "Story" because I believe it is a more
-appropriate term. A feature's scenarios typically grow over time - fed by several user
-stories.
-The name Cucumber means absolutely nothing, it was suggested by my girlfriend who was eating a cucumber sandwich
-while I started to write it.