rspec 0.5.11 → 0.5.12

data/doc/src/documentation/underscores.page

@@ -1,21 +0,0 @@
----
-title: Underscore sugar
-inMenu: true
----
-h2. Underscore sugar
-
-The internal implementation of RSpec actually uses chained method calls, so it's possible
-to write:
-
-<ruby>
-lambda { 1.should.not.equal 1 }.should.raise
-</ruby>
-
-However, in order to make RSpec look and feel closer to other ruby code,
-RSpec allows you to use underscores instead if you wish:
-
-<ruby>
-lambda { 1.should_not_equal 1 }.should_raise
-</ruby>
-
-Therefore, you will see the underscored syntax throughout the documentation and examples.

data/doc/src/examples.page

@@ -1,9 +0,0 @@
----
-title: Examples
-inMenu: true
----
-h2. Examples
-
-Here is an example of an RSpec spec:
-
-<ruby file="../examples/stack_spec.rb" />

data/doc/src/index.page

@@ -1,74 +0,0 @@
----
-title: Overview 
-inMenu: true
---- 
-
-h2. Behaviour Driven Development 
-
-Test Driven Development (TDD) has you define the behaviour of your system by
-writing small tests that precisely define some small piece of your system's
-behaviour. Then you implement that behaviour. Then you clean up & improve your
-design.
-
-At least that's how you're supposed to do it.
-
-This focus on behaviour is the real value in TDD, and marks the genuinely
-experienced TDD practitioner.
-
-However, with the ubiquity of testing related terminology in TDD and it's
-supporting frameworks, it is no surprise that it takes beginners some time to
-get to the understanding that TDD isn't about testing at all... if they ever
-do.
-
-The aim of BDD is to address this shortcoming and, by using terminology
-focused on the behavioural aspects of the system rather than testing, attempt
-to help direct developers towards a focus on the real value to be found in TDD
-at its most successful, or BDD as we call it.
-
-(paraphrased from "behaviour-driven.org":http://behaviour-driven.org)
-
-Dan North, who was the first to coin the term BDD, and who has been actively 
-refining it since, started promoting BDD in 2003. "JBehave":http://jbehave.codehaus.org/ 
-was the first BDD framework to support this new thinking.
-
-h2. RSpec
-
-RSpec is a framework for practicing __Behaviour Driven Development__ (BDD) in Ruby.
-
-It all started with a blogpost 
-("A New Look at Test Driven Development":http://blog.daveastels.com/articles/2005/07/05/a-new-look-at-test-driven-development) 
-of Dave's where he talked about his ideas for BDD and a BDD framework. One thing he mentioned was that his ideas
-would be easily implemented in Smalltalk, and probably Ruby.
-
-Steven Baker wrote the first version of the rspec core.  Dave added mock support (initially inspired from Schmock by 
-Ben Griffiths). Dave and David had met & talked about BDD at Agile'05 just after Dave's blog
-post (above). David started thinking about a BDD framework in C#. As fate, or
-the gods, would have it Dave & David ended up working at the same client in
-the greater Chicago area, allowing them to explore some ideas resulting in the totally rewriting of the expectation mechanism. 
-Aslak joined in and the three rewrote the higher level syntax and the core, reworking RSpec into what you see now:
-
-<ruby>
-context "BDD framework" do
-
-  setup do
-    @bdd_framework = BddFramework.new
-  end
-
-  specify "should be adopted quickly" do
-    @bdd_framework.should_be_adopted_quickly
-  end
-  
-  specify "should be intuitive" do
-    @bdd_framework.should_be_intuitive
-  end
-
-end
-</ruby>
-
-RSpec provides a framework for writing what we call __executable
-specifications of program behaviour__. Since that's rather wordy, we usually
-just call them __specs__. 
-"Some other people":http://www.testing.com/cgi-bin/blog/2006/04/12#spec-vs-example call these things __examples__.
-
-On this site you will find examples, documentation, and tutorials as well as
-links to download and community resources.

data/doc/src/meta.info

@@ -1,33 +0,0 @@
-index.page:
-  orderInfo: 1
-
-examples.page:
-  orderInfo: 2
-
-tutorials:
-  title: Tutorial
-  orderInfo: 5
-
-documentation:
-  title: Documentation
-  orderInfo: 6
-
-download.html:
-  title: Download
-  inMenu: true
-  dest: http://rubyforge.org/frs/?group_id=797
-  orderInfo: 7
-
-tools:
-  title: Tools
-  orderInfo: 8
-
-core_team.page:
-  orderInfo: 9
-
-community.html:
-  title: Community
-  inMenu: true
-  dest: http://rubyforge.org/projects/rspec
-  orderInfo: 10
-  

data/doc/src/tools/index.page

@@ -1,49 +0,0 @@
----
-title: Seven tools in one
-inMenu: true
----
-
-h2. Seven tools in one
-
-RSpec combines several tools in one...
-
-h3. 1) A language for expressing behavior
-
-RSpec provides programmers with a domain specific language for defining expected behavior of Ruby code.
-
-h3. 2) A runner for verifying behavior
-
-RSpec provides a command line utility for executing behavior specifications.
-
-h3. 3) Mock objects
-
-Mock objects frameworks usually come as separate add-ons to existing XUnit frameworks. In RSpec it's an integrated
-part of the framework.
-
-h3. 4) Testdox-like reports
-
-Expressing behavior in real sentences improves communication between programmer, 
-analysts and testers. It also helps programmers keep a more critical mind about the code being developed.
-
-RSpec's built in support for generating "testdox-like":http://agiledox.sourceforge.net/ reports makes the code's behavior more transparent 
-to everybody (assuming you publish it to a webpage where everybody who needs to can see it).
-
-h3. 5) Coverage tool
-
-While coverage tools cannot prove that you have verified everything there is to verify about your code,
-they can prove when you have not verified everything there is to verify about your code. RCov is such a
-coverage tool, and RSpec supportws it out-of the box via its Rake task.
-
-h3. 6) Coverage threshold verification
-
-Except for the times when programmers agree to keep a close eye on coverage and keep it at, say 90%, it
-will inevitably drop when they get other things to think about and start to write code in the wild.
-
-RSpec ships with a special Rake task that can verify that the coverage remains on a level defined by the 
-development team. Should the coverage drop, the build will fail, and developers are encouraged to address 
-it right away.
-
-h3. 7) Test::Unit translation
-
-Did you invest a lot of time in writing Test::Unit tests and want to switch to RSpec? Try out the test2spec
-tool, which will do most of the translation for you. (test2spec tool is experimental)

data/doc/src/tools/meta.info

@@ -1,18 +0,0 @@
-index.page:
-  orderInfo: 10
-
-spec.page:
-  orderInfo: 11
-
-rake.page:
-  orderInfo: 12
-
-rcov.page:
-  orderInfo: 13
-
-test2spec.page:
-  orderInfo: 14
-
-rails.page:
-  orderInfo: 15
-

data/doc/src/tools/rails.page

@@ -1,132 +0,0 @@
----
-title: RSpec on Rails
-inMenu: true
----
-h2. RSpec on Rails
-
-RSpec's rspec_generator Rubygem brings RSpec to Rails.
-
-h3. Features
-
-* Integrated fixture loading
-* Uses many of the controller-test integration features
-* Special generators for models and controllers that generate specs instead of tests.
-
-h3. Installation
-
-RSpec support for rails lives in a separate gem. Install that gem:
-
-<pre>
-gem install rspec_generator
-</pre>
-
-Once the gem is installed, you must configure you Rails app. Stand in the root of your Rails app and run:
-
-<pre>
-ruby script/generate rspec
-</pre>
-
-Now, you can generate models and controllers in a similar fashion to Rails' builtin generators. Example:
-
-<pre>
-ruby script/generate rspec_model person
-</pre>
-
-or
-
-<pre>
-ruby script/generate rspec_controller person
-</pre>
-
-For more information on each generator, just run them without any arguments.
-
-h3. Running specs
-
-All specs can be run with
-
-<pre>
-rake spec
-</pre>
-
-Model specs can be run with
-
-<pre>
-rake spec:models
-</pre>
-
-Controller specs can be run with
-
-<pre>
-rake spec:controllers
-</pre>
-
-To see all the RSpec related tasks, run
-
-<pre>
-rake --tasks spec
-</pre>
-
-h3. Naming conventions
-
-When you use Rails without RSpec (with Test::Unit), tests for models end up in tests/unit and tests for controllers
-end up in tests/functional.
-
-In order to make things more consistent, RSpec chooses a slightly different naming convention for direcotries and
-Rake tasks. So you will find model specs under specs/models, and controller specs under specs/controllers. The
-Rake tasks are named accordingly.
-
-h3. Examples
-
-RSpec on Rails adds several methods to your specs with a look and feel similar to Test::Unit. Example:
-
-Model:
-<ruby file="../vendor/rspec_on_rails/spec/models/person_spec.rb"/>
-
-Controller:
-<ruby file="../vendor/rspec_on_rails/spec/controllers/person_controller_spec.rb"/>
-
-h3. Translating existing Test::Unit tests
-
-The test2spec tool that ships with RSpec translates existing tests into RSpec specs. 
-Translating tests to specs in a Rails environment requires some manual steps...
-
-h4. Install the rspec_generator
-How to do this is described above
-
-h4. Modify your test/test_helper.rb
-In order to be able to translate any Rails tests, you must modify your test/test_helper.rb file:
-<pre>
-# This line must be commented out in order for test2spec to work.
-# require 'test_help'
-require 'test2spec_help'
-</pre>
-
-The reason for this is that the <tt>test_help</tt> mixin confuses test2spec to the point
-where it's unable to perform the translation. The <tt>test2spec_help</tt> addresses this
-shortcoming.
-
-h4. Perform the translations
-Now you can translate your unit tests (model tests) with:
-<pre>
-test2spec --template spec/test2spec.erb --specdir spec/models test/unit
-</pre>
-and your functional tests (controller tests) with:
-<pre>
-test2spec --template spec/test2spec.erb --specdir spec/controllers test/functional
-</pre>
-
-h4. Edit your translated specs
-test2spec currently doesn't translate class-level statements such as <tt>fixtures</tt>, so you have to do this yourself.
-Copy all the <tt>fixtures</tt> statements in your tests to the corresponding contexts. Example:
-
-<ruby>
-context "The Foo Model" do
-  fixtures :foo
-end
-</ruby>
-
-h4. Make sure fixtures are found.
-By default, RSpec on Rails expects to find fixtures under <tt>spec/fixtures</tt>. You should either move your
-existing <tt>test/fixtures/*.yml</tt> files to <tt>spec/fixtures</tt> or edit your <tt>spec/spec_helper.rb</tt>
-to point to the old <tt>test/fixtures</tt> location. Beware that every time you do a <tt>script/generate rspec_model</tt>,
-new fixstures will always be written to <tt>spec/fixtures</tt>.

data/doc/src/tools/rake.page

@@ -1,21 +0,0 @@
----
-title: Rake Task
-inMenu: true
----
-h2. Rake Task
-
-RSpec comes with a Rake task for executing specs.
-See "Spec::Rake::SpecTask":../rdoc/classes/Spec/Rake/SpecTask.html for details.
-
-h3. Run specs
-
-<ruby file="../test/tasks/examples.rake"/>
-
-Also see the "RCov":rcov.html page for info about how to generate a coverage report.
-
-h3. Generate specdocs
-
-<ruby file="../test/tasks/examples_specdoc.rake"/>
-
-This will output the specdocs to a file, which can be included in your RDoc. 
-Just like "this":../rdoc/files/EXAMPLES_rd.html.

data/doc/src/tools/rcov.page

@@ -1,28 +0,0 @@
----
-title: RCov
-inMenu: true
----
-h2. RCov
-
-RSpec has tight integration with "RCov":http://eigenclass.org/hiki.rb?rcov=.
-
-h3. Run specs with RCov
-
-<ruby file="../test/tasks/examples_with_rcov.rake"/>
-
-By adding rcov=true to the rake task, specs will be run with rcov
-instead of ruby, and a coverage report like "this":../coverage/index.html will be generated.
-
-See "Spec::Rake::SpecTask":../rdoc/classes/Spec/Rake/SpecTask.html for details.
-
-h3. Coverage threshold
-
-You can guard your codebase's coverage from dropping below a certain threshold
-by using RSpec's built-in task for verification of the total RCov coverage.
-
-<ruby file="../test/tasks/rcov_verify.rake"/>
-
-This will give you a :rcov_verify task that will fail your build if the
-coverage drops below the threshold you define (the higher the better).
-
-See "RCov::VerifyTask":../rdoc/classes/RCov/VerifyTask.html for details.

data/doc/src/tools/spec.page

@@ -1,129 +0,0 @@
----
-title: Spec Runner
-inMenu: true
----
-
-h2. Executing specs directly
-
-Every RSpec context can be run directly from the command line:
-
-<pre>
-ruby path/to/my_spec.rb [options]
-</pre>
-
-This will print the results to STDOUT. Use the --help option for more details. This is
-practical when you only want to run one context. If you want to run more, use the spec tool
-or the Rake task. It should also be noted that the exitcode will always be 0 when run in standalone mode.
-
-h2. The spec command line
-
-After you install RSpec, you should have the spec command line tool on your PATH.
-This tool can be used to process several RSpec contexts in one go. 
-
-spec will exit with the exitcode 1 if one or more specs fail.
-
-The general form of the command is
-
-<pre>
-spec [options] (FILE|DIRECTORY|GLOB)+
-</pre>
-
-Any number of files, directories and shell globs can be provided, all ruby source files
-that are found are loaded. Running spec on the previous example results in:
-
-<pre>
-bin/spec examples
-{execute: ruby ../bin/spec ../examples}
-</pre>
-
-Very simple and to the point. Passing specifications are indicated by a '.',
-failing ones by a 'F'. Note that failure indicates a violated expectation as
-well as an unexpected exception being raised.  Here's an example with a failing specification:
-
-<pre>
-bin/spec failing_examples/stack_spec.rb
-{execute: ../bin/spec ../failing_examples/stack_spec.rb}
-</pre>
-
-In this case, the context is named "An almost full stack (with one item less than capacity)" 
-and the specification is named "should return top when sent pop". These two are concatenated 
-on the first line of the backtrace.
-
-h2. Command line options
-
-Additional command line options can be passed to customize the output and behaviour of RSpec.
-The following options apply whether specs are run in standalone mode (by executing the .rb files directly), 
-or using the spec command.
-
-h3. -f, --format [specdoc|s|rdoc|r|]
-
-Specify the output format. Default format is "progress bar" ("." for pass, "F" for fail). Most formats will produce some form of "testdox":http://agiledox.sourceforge.net/
-output. The --dry-run options may also affect the output format.
-
-For example, by setting the formatter to rdoc, we can output the kind of input that RDoc
-needs to produce something like "this":../rdoc/files/EXAMPLES_rd.html 
-<pre>
-$ bin/spec failing_examples/team_spec.rb -f rdoc
-
-{execute: ../bin/spec ../failing_examples/team_spec.rb -f rdoc}
-</pre>
-
-h4. Custom formatters
-
-As of RSpec 0.5.7 custom formatters are supported. If the argument to the --format option is none
-of the builtin formatters, RSpec will assume it's a class name, and try to instantiate that class.
-If you're using this feature, make sure to use the --require option as well - *before* the
---format option.
-
-See the RDoc for "Spec::Runner::BaseTextFormatter":../rdoc/classes/Spec/Runner/BaseTextFormatter.html 
-for details on how to implement your own. A custom formatter can be found under examples/custom_formatter.rb.
-
-h3. -r, --require FILE
-
-Causes FILE to be loaded (via require) before any specs are executed. If you're using a custom
-formatter, you have to specify this option *before* the --format option.
-
-h3. -d, --dry-run
-
-This option tells RSpec not to execute the specs, but they are still being parsed.
-This can be useful when generating "testdox-like":http://agiledox.sourceforge.net/ documents
-
-h3. -b, --backtrace
-
-In order to make it easier to identify causes of failing specifications, RSpec will filter out
-the parts of the backtrace that come from RSpec itself by default. If you wish to see them,
-you can use -b or --backtrace:
-
-<pre>
-$ bin/spec failing_examples/team_spec.rb -b
-
-{execute: ../bin/spec ../failing_examples/team_spec.rb -b}
-</pre>
-
-h3. -s, --spec &lt;name of context and/or specification&gt;
-
-Enter the name of a context, spec, or both to run:
-
-all the specs in a context ...
-
-<pre>
-$ bin/spec examples --spec "A stack with one item" -f s
-
-{execute: ../bin/spec ../examples --spec "A stack with one item" -f s}
-</pre>
-
-... any spec in any context with a given name ...
-
-<pre>
-$ bin/spec examples --spec "should return top when sent top" -f s
-
-{execute: ../bin/spec ../examples --spec "should return top when sent top" -f s}
-</pre>
-
-... or a specific spec in a specific context:
-
-<pre>
-$ bin/spec examples --spec "A stack with one item should return top when sent top" -f s
-
-{execute: ../bin/spec ../examples --spec "A stack with one item should return top when sent top" -f s}
-</pre>