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

aslakhellesoy-cucumber 0.1.3 → 0.1.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

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.