Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

get rid of the nav, add links to relishapp.com and rubydoc.info, have…

… a drink - it's Sunday
  • Loading branch information...
commit 7ddc80a72a035738f6b35b169f4c479364293ba9 1 parent ad478b9
@dchelimsky dchelimsky authored
Showing with 17 additions and 1,760 deletions.
  1. +13 −0 content/index.page
  2. +0 −8 content/rspec-core/changelog.page
  3. +0 −383 content/rspec-core/index.page
  4. +0 −61 content/rspec-core/tools/extensions/editors/index.page
  5. +0 −9 content/rspec-core/tools/extensions/index.page
  6. +0 −11 content/rspec-core/tools/heckle.page
  7. +0 −12 content/rspec-core/tools/index.page
  8. +0 −12 content/rspec-core/tools/rake.page
  9. +0 −51 content/rspec-core/tools/rcov.page
  10. +0 −23 content/rspec-core/tools/rspec-command.page
  11. +0 −8 content/rspec-expectations/changelog.page
  12. +0 −109 content/rspec-expectations/index.page
  13. +0 −8 content/rspec-mocks/changelog.page
  14. +0 −51 content/rspec-mocks/index.page
  15. +0 −340 content/rspec-mocks/message-expectations.page
  16. +0 −59 content/rspec-mocks/method-stubs.page
  17. +0 −48 content/rspec-mocks/other-frameworks.page
  18. +0 −21 content/rspec-mocks/partial-mocks.page
  19. +0 −8 content/rspec-rails/changelog.page
  20. +0 −139 content/rspec-rails/controllers.page
  21. +0 −29 content/rspec-rails/helpers.page
  22. +0 −154 content/rspec-rails/index.page
  23. +0 −11 content/rspec-rails/mailers.page
  24. +0 −34 content/rspec-rails/models.page
  25. +0 −11 content/rspec-rails/routing.page
  26. +0 −115 content/rspec-rails/views.page
  27. +3 −44 lib/rspec_extras.rb
  28. +1 −1  upload
View
13 content/index.page
@@ -16,6 +16,19 @@ h2. Overview
RSpec is a Behaviour-Driven Development tool for Ruby programmers. BDD is an approach to software development that combines Test-Driven Development, Domain Driven Design, and Acceptance Test-Driven Planning. RSpec helps you do the TDD part of that equation, focusing on the documentation and design aspects of TDD.
+h2. Documentation
+
+Cucumber Features
+
+* "http://relishapp.com/rspec":http://relishapp.com/rspec
+
+RDoc
+
+* "http://rubydoc.info/gems/rspec-core":http://rubydoc.info/gems/rspec-core/frames
+* "http://rubydoc.info/gems/rspec-expectations":http://rubydoc.info/gems/rspec-expectations/frames
+* "http://rubydoc.info/gems/rspec-mocks":http://rubydoc.info/gems/rspec-mocks/frames
+* "http://rubydoc.info/gems/rspec-rails":http://rubydoc.info/gems/rspec-rails/frames
+
h2. The RSpec Book
The RSpec Book will introduce you to RSpec, Cucumber, and a number of other tools that make up the Ruby BDD family. Replete with tutorials and practical examples, the RSpec Book will help you get your BDD on, taking you from executable requirements to working software that is clean, well tested, well documented, flexible and highly maintainable.
View
8 content/rspec-core/changelog.page
@@ -1,8 +0,0 @@
----
-title: changelog
-order: 7
-filter:
- - erb
- - textile
----
-<pre><%= IO.read '../rspec-core/Changelog.md' %></pre>
View
383 content/rspec-core/index.page
@@ -1,383 +0,0 @@
----
-title: rspec-core
-order: 1
-filter:
- - erb
- - markdown
----
-
-## rspec-core
-
-rspec-core provides a framework for writing executable examples of the expected
-behaviour of your code. The basic structure consists of _examples_ grouped
-together in _example groups_.
-
-<% coderay :lang => 'ruby' do %>
-describe Account do
- it "has a balance of $0 when first opened" do
- account = Account.new
- account.balance.should eq(Money.new(0, :USD))
- end
-end
-<% end %>
-
-The `describe` method creates an _example group_, and the `it` method creates
-an _example_ within that group. You can run this spec with the `rspec` command,
-like this:
-
-<% coderay :lang => 'shell' do -%>
-$ rspec account_spec.rb
-.
-
-1 example, 0 failures
-<% end %>
-
-The single dot represents the single example. You can add the `--format` option
-to use different formatters. Probably the most useful value is `documentation`:
-
-<% coderay :lang => 'shell' do -%>
-$ rspec account_spec.rb --format documentation
-
-Account
- has a balance of $0 when first opened
-
-1 example, 0 failures
-<% end %>
-
-This is a great way to quickly scan the docstrings of all the examples,
-encouraging you to make them readable, and exposing which behaviors you have
-and have not specified at a glance.
-
-## nested groups
-
-An example group can contain any number of examples, and can also be nested
-within other groups:
-
-<% coderay do -%>
-describe Account do
- describe "when first opened" do
- it "has a balance of $0" do
- account = Account.new
- account.balance.should eq(Money.new(0, :USD))
- end
- end
-end
-<% end %>
-
-The `documentation` format indents these nicely:
-
-<% coderay :lang => 'shell' do -%>
-$ rspec account_spec.rb --format documentation
-
-Account
- when first opened
- has a balance of $0
-
-1 example, 0 failures
-<% end %>
-
-You can nest groups arbitrarily deeply, but do so carefully because
-nesting can quickly get out of hand and make things difficult to
-understand.
-
-## before and after
-
-Use the `before` and `after` methods to define code that runs before and after
-each example or only once per group:
-
-<% coderay do -%>describe Thing do
- before(:all) do
- # this is run once and only once, before all of the examples and before any
- # before(:each) blocks in this group.
- end
-
- before(:each) do
- # this is run before each example.
- end
-
- before do
- # :each is the default, so this is the same as before(:each)
- end
-
- it "does something" do
- ...
- end
-
- it "does something else" do
- ...
- end
-
- after(:each) do
- # this is after each example
- end
-
- after do
- # :each is the default, so this is the same as after(:each)
- end
-
- after(:all) do
- # this is run once and only once, after all of the examples and after any
- # after(:each) blocks in this group.
- end
-
-end
-<% end -%>
-
-### before(:each)
-
-TODO
-
-### before(:all)
-
-TODO
-
-### after(:each)
-
-`after(:each)` is rarely needed, and should only be used when you're concerned
-that some state might be leaking into your other examples.
-
-### after(:all)
-
-TODO
-
-### before(:all) and after(:all)
-
-For expensive operations, like opening browsers using Spec::Ui, RSpec also allows
-you to set up and tear down state before(:all) and after(:all) examples in any
-given behaviour.
-
-<% coderay :lang => 'ruby' do -%>
-describe "Search page" do
- before(:all) do
- @browser = Watir::Browser.new
- end
-
- it "should find all contacts" do
- # ...
- end
-
- after(:all) do
- @browser.kill! rescue nil
- end
-end
-<% end -%>
-
-### global after and before hooks
-
-Sometimes you have some generic code you want to run before or after every
-single one of your examples. Such global before and after blocks can be defined
-in the RSpec configuration, which typically lives in a spec_helper.rb file that
-is required from other spec files. Example:
-
-<% coderay do -%>
-RSpec.configure do |config|
- config.before(:all) { ... }
- config.before(:each) { ... }
- config.after(:all) { ... }
- config.after(:each) { ... }
-end
-<% end -%>
-
-Global before blocks get run before local ones. Global after blocks get run
-after local ones.
-
-You can also specify that a before or after block should only be weaved into
-certain behaviours, in a similar way to how global includes are declared:
-
-TODO: mention behavior in rspec-rails where you can't access the stuff that
-Rails sets up in global before hooks.
-
-<% coderay do -%>
-RSpec.configure do |config|
- config.before(:each, :type => :controller) do
- login_aslak
- end
-end
-<% end -%>
-
-### errors in before and after hooks
-
-If a before hook raises an error, none of the following before hooks (if any)
-or the example itself will get run. If an after hook raises an error, the
-remaining ones will still be run.
-
-### <div class="warning">WARNING about `before(:all)` and `after(:all)`</div>
-
-It is very tempting to use before(:all) and after(:all) for situations in which
-it is not appropriate. before(:all) shares some (not all) state across multiple
-examples. This means that the examples become bound together, which is an
-absolute no-no in testing. We recommend that you only use before(:all) to set
-up things that are global collaborators but not the things that you are
-describing in the examples.
-
-The most common cases of abuse are database access and/or fixture setup. Every
-example that accesses the database should start with a clean slate, otherwise
-the examples become brittle and start to lose their value with false negatives
-and, worse, false positives.
-
-## helper methods
-
-You can write helper methods directly within an Example Group:
-
-<% coderay do -%>describe "..." do
-
- it "..." do
- helper_method
- end
-
- def helper_method
- ...
- end
-
-end
-<% end -%>
-
-## sharing helper methods
-
-You can include helper methods in multiple ExampleGroups by expressing them within a module, and then including that module in your ExampleGroup:
-
-<% coderay do -%>module AccountExampleHelperMethods
- def helper_method
- ...
- end
-end
-
-describe "A new account" do
- include AccountExampleHelperMethods
- before do
- @account = Account.new
- end
-
- it "should have a balance of $0" do
- helper_method
- @account.balance.should eql(Money.new(0, :dollars))
- end
-end
-<% end -%>
-
-## pending examples
-
-There are three ways to mark an example as "pending."
-
-### use `it` without a block
-
-<% coderay do -%>
-it "should say foo"
-<% end -%>
-
-The example does not get run and the output says `PENDING (Not Yet
-Implemented)`.
-
-### add `pending` to the example
-
-<% coderay do -%>
-it "should say foo" do
- pending("get the vocal chords working")
- subject.should say("foo")
-end
-<% end -%>
-
-The code after the `pending` statement does not get run, and output says
-`PENDING (get the vocal chords working)`.
-
-### add `pending` to the example, with a block
-
-<% coderay do -%>
-it "should say foo" do
- pending("get the vocal chords working") do
- subject.should say("foo")
- end
-end
-<% end -%>
-
-The code in the block _does_ get run. If the block results in any failed
-expectations or other errors, the example is reported as `PENDING (get the
-vocal chords working)`. If there are no failures or errors, the example fails,
-telling you to it is `FIXED`.
-
-## shared example groups
-
-You can create shared example groups and include those groups into other groups.
-
-Suppose you have some behavior that applies to all editions of your product, both large and small.
-
-First, factor out the "shared" behavior:
-
-<% coderay do -%>
-shared_examples_for "all editions" do
- it "should behave like all editions" do
- end
-end
-<% end -%>
-
-then when you need define the behavior for the Large and Small editions,
-reference the shared behavior using the `it_should_behave_like`
-method.
-
-<% coderay do -%>describe "SmallEdition" do
- it_should_behave_like "all editions"
-
- it "should also behave like a small edition" do
- end
-end
-
-describe "LargeEdition" do
- it_should_behave_like "all editions"
-
- it "should also behave like a large edition" do
- end
-end
-<% end -%>
-
-`it_should_behave_like` will search for an ExampleGroup by its
-description string, in this case, "all editions"
-
-All of the following are included from a shared group:
-
-* before(:all)
-* before(:each)
-* after(:each)
-* after(:all)
-* all included modules
-* all methods
-
-Shared example groups may not extend classes.
-
-Multiple shared example groups may be referenced in one (non-shared) group.
-
-Shared example groups may be included in other shared groups:
-
-<% coderay do -%>
-shared_examples_for "All Employees" do
- it "should be payable" do
- @employee.should respond_to(:calculate_pay)
- end
-end
-
-shared_examples_for "All Managers" do
- it_should_behave_like "All Employees"
- it "should be bonusable" do
- @employee.should respond_to(:apply_bonus)
- end
-end
-
-describe Officer do
- before(:each) do
- @employee = Officer.new
- end
-
- it_should_behave_like "All Managers"
-
- it "should be optionable" do
- @employee.should respond_to(:grant_options)
- end
-end
-
-$ spec officer_spec.rb
-
-Officer
-- should be payable
-- should be bonusable
-- should be optionable
-<% end -%>
-
View
61 content/rspec-core/tools/extensions/editors/index.page
@@ -1,61 +0,0 @@
----
-title: editors
-order: 1
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-RSpec's commandline API and pluggable formatters make it easy to integrate with
-external tools like text editors and IDEs. Here are the general steps you need
-to write an RSpec plugin for your editor.
-
-The RSpec team maintains a [TextMate
-bundle](https://github.com/rspec/rspec-tmbundle) which does exactly this. You
-may want to look at its source if you're about to write a plugin for a new
-editor.
-
-### Launch RSpec from the IDE
-
-Most advanced editors provide a mechanism to launch external processes by
-hitting a keystroke. Depending on your editor, you may want to launch RSpec
-directly via the `rspec` command (which must be on your `$PATH`).
-Alternatively, if your editor makes it possible to run Ruby scripts directly,
-you may execute RSpec via
-[`RSpec::Core::Runner.run`](http://rubydoc.info/gems/rspec-core/RSpec/Core/Runner.run)
-(which has a similar API to the `rspec` command, except you can call it
-straight from Ruby without forking a new Ruby process).
-
-### Tell RSpec what spec(s) to run
-
-You may want to assign different keystrokes to run your specs. You could run
-all specs in your project, the ones in the currently open file or just the one
-you have focused in the editor. RSpec's commandline API has a `--line_number`
-option which will make RSpec run the spec at the current line (it also works if
-the line is inside the spec). Most editors provide a way to query the current
-file and the line of the cursor when launching an external process, and you can
-use this to feed the right argument to the `--line_number` option.
-
-### Make the backtrace work with your editor
-
-When a spec fails, the backtrace is displayed in the error message. The
-backtrace contains lines with file paths and line numbers. Most editors have a
-mechanism that will open the file and put the cursor on the right line when
-such a line is clicked - provided the line is on a format that the editor
-understands.
-
-It is possible to customise the backtrace lines of RSpec's output to achieve
-this. All you need to do is to implement your own Formatter class, typically by
-subclassing
-[`DocumentationFormatter`](http://rubydoc.info/gems/rspec-core/RSpec/Core/Formatters/DocumentationFormatter)
-or [HtmlFormatter](http://rubydoc.info/gems/rspec-core/RSpec/Core/Formatters/HtmlFormatter)
-(depending on what your editor understands). In your formatter class you can
-override the `backtrace_line` method to make the output be something
-that works with your editor.
-
-Then, when the editor plugin launches RSpec, just make sure it uses the
-`--formatter` option to specify *your* custom formatter. Note that
-you will probably have to use `--require` too, so that the code for
-your custom formatter is loaded. See `rspec --help` for details.
View
9 content/rspec-core/tools/extensions/index.page
@@ -1,9 +0,0 @@
----
-title: extensions
-order: 5
-filter:
- - erb
- - markdown
----
-
-More soon ...
View
11 content/rspec-core/tools/heckle.page
@@ -1,11 +0,0 @@
----
-title: heckle
-order: 4
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-RSpec-2 dropped heckle integration since Heckle does not support ruby 1.9. If/when that changes, we'll revisit.
View
12 content/rspec-core/tools/index.page
@@ -1,12 +0,0 @@
----
-title: tools
-order: 6
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-RSpec combines several tools in one package. Follow the links above for details
-on specific tools.
View
12 content/rspec-core/tools/rake.page
@@ -1,12 +0,0 @@
----
-title: rake
-order: 2
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-RSpec comes with a "Rake":http://rubygems.org/gems/rake task for executing specs.
-See "RSpec::Core::RakeTask":http://rubydoc.info/gems/rspec-core/RSpec/Core/RakeTask API for details.
View
51 content/rspec-core/tools/rcov.page
@@ -1,51 +0,0 @@
----
-title: rcov
-order: 3
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-RSpec has tight integration with "RCov":http://eigenclass.org/hiki.rb?rcov, the excellent code coverage tool for Ruby.
-
-h3. Running specs with RCov
-
-The easiest way to use RCov with RSpec is from a rake script (Rakefile), using RSpec's
-"Rake task":rake.html. The snippet below is from RSpec's own Rakefile.
-
-[EXAMPLE PENDING]
-
-By adding <code>rcov=true</code> to the rake task, specs will be run with RCov
-instead of the standard ruby interpreter, and a coverage report like
-"this":../../coverage/index.html will be generated with the following command line:
-
-<pre>
-rake examples_with_rcov
-</pre>
-
-Also, because you don't want your example files to be included in the coverage report (you just
-want them to run), don't forget to add <code>t.rcov_opts = ['--exclude', 'examples']</code>. You
-can use this to exclude any other files that must be required but should not be measured (just
-use a comma separated list).
-
-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.
-(This is not the same as RCov's --threshold option, which is a filtering mechanism).
-
-[EXAMPLE PENDING]
-
-This will give you a :verify_rcov task that will fail your build if the
-coverage drops below the threshold you define.
-If it's too low you're encouraged to write more specs rather than "fix"
-the threshold value (which should usually only be adjusted upwards).
-
-In fact, the task will also fail the build if the coverage raises above the threshold as well.
-This might seem a bit counterintuitive, but this is when you should go and raise the
-threshold in your Rakefile. This way you won't miss temporary coverage increases. Crank it up!
-This is how we got to 100% coverage for RSpec.
-
-See "RCov::VerifyTask":../../rdoc/classes/RCov/VerifyTask.html for details.
View
23 content/rspec-core/tools/rspec-command.page
@@ -1,23 +0,0 @@
----
-title: rspec command
-order: 1
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-When you install the `rspec` gem (or `rspec-core`), it installs the `rspec`
-command on your PATH. This command can be used to run specs in one file, several files, all of the files in a directory, or all the files matching a glob pattern:
-
- rspec # runs all the files in the spec directory
- rspec spec # runs all the files in the spec directory
- rspec examples # runs all the files in the examples directory
- rspec spec/widgets/thing_spec.rb # runs all the examples in the file
- rspec spec/widgets/thing_spec.rb:37 # runs the example or group on line 37
- rspec spec/**/*things*_spec.rb # runs all files matching the pattern
-
-To learn more, just run:
-
- rspec --help
View
8 content/rspec-expectations/changelog.page
@@ -1,8 +0,0 @@
----
-title: changelog
-order: 5
-filter:
- - erb
- - textile
----
-<pre><%= IO.read '../rspec-expectations/Changelog.md' %></pre>
View
109 content/rspec-expectations/index.page
@@ -1,109 +0,0 @@
----
-title: rspec-expectations
-order: 2
-filter:
- - erb
- - markdown
----
-
-## rspec-expectations
-
-rspec-expectations defines <code>should</code> and <code>should_not</code> on
-every object in the system. Here is a list of all the built-in matchers
-provided by rspec-expectations. See
-[RSpec::Expectations](http://rdoc.info/gems/rspec-expectations/RSpec/Expectations)
-and [RSpec::Matchers](http://rdoc.info/gems/rspec-expectations/RSpec/Matchers)
-for more information.
-
-## built in matchers
-
-### Object eqivalence
-
-<% coderay lang='ruby' do %>
-actual.should eq(expected) # passes if actual == expected
-actual.should == expected # passes if actual == expected
-actual.should eql(expected) # passes if actual.eql?(expected)
-<% end %>
-
-### Object identity
-
-<% coderay lang='ruby' do %>
-actual.should equal(expected) # passes if actual.equal?(expected)
-actual.should be(expected) # passes if actual.equal?(expected)
-<% end %>
-
-
-### Comparisons
-
-<% coderay lang='ruby' do %>
-actual.should be > expected
-actual.should be >= expected
-actual.should be <= expected
-actual.should be < expected
-actual.should =~ /expression/
-actual.should match(/expression/)
-actual.should be_within(delta).of(expected)
-<% end %>
-
-### Types/classes
-
-<% coderay lang='ruby' do %>
-actual.should be_instance_of(expected)
-actual.should be_kind_of(expected)
-<% end %>
-
-### Truthiness
-
-<% coderay lang='ruby' do %>
-actual.should be_true # passes if actual is truthy (not nil or false)
-actual.should be_false # passes if actual is falsy (nil or false)
-actual.should be_nil # passes if actual is nil
-<% end %>
-
-### Expecting errors
-
-<% coderay lang='ruby' do %>
-expect { ... }.to raise_error
-expect { ... }.to raise_error(ErrorClass)
-expect { ... }.to raise_error("message")
-expect { ... }.to raise_error(ErrorClass, "message")
-<% end %>
-
-### Expecting throws
-
-<% coderay lang='ruby' do %>
-expect { ... }.to throw_symbol
-expect { ... }.to throw_symbol(:symbol)
-expect { ... }.to throw_symbol(:symbol, 'value')
-<% end %>
-
-### Predicate matchers
-
-<% coderay lang='ruby' do %>
-actual.should be_xxx # passes if actual.xxx?
-actual.should have_xxx(:arg) # passes if actual.has_xxx?(:arg)
-
-# examples
-
-[].should be_empty # passes because [].empty? returns true
-{ :a => 1 }.should have_key(:a) # passes because the hash has the key :a
-<% end %>
-
-### Collection membership
-
-<% coderay lang='ruby' do %>
-actual.should include(expected)
-
-# examples
-
-[1,2,3].should include(1)
-[1,2,3].should include(1, 2)
-{:a => 'b'}.should include(:a => 'b')
-"this string".should include("is str")
-<% end %>
-
-### Ranges (Ruby >= 1.9)
-
-<% coderay lang='ruby' do %>
-(1..10).should cover(3)
-<% end %>
View
8 content/rspec-mocks/changelog.page
@@ -1,8 +0,0 @@
----
-title: changelog
-order: 5
-filter:
- - erb
- - textile
----
-<pre><%= IO.read '../rspec-mocks/Changelog.md' %></pre>
View
51 content/rspec-mocks/index.page
@@ -1,51 +0,0 @@
----
-title: rspec-mocks
-order: 3
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-Mock objects are imitation objects that give you declarative control over their
-behaviour in the course of the execution of an example. Defining [message
-expectations](message-expectations.html) and [method stubs](method-stubs.html) on mock
-objects allows you to specify how one object collaborates with others before
-those other objects exist.
-
-You can also use mock objects to isolate your examples from services that are
-complex to set up or expensive to run, thereby keeping your suite of examples
-running quickly.
-
-RSpec ships with a built-in mock object framework that lets you create mock
-objects in your examples or add mock-object-like behaviour to your existing
-objects.
-
-### Creating a mock object
-
-You create a mock object with the <code>mock</code> method:
-
-<% coderay do -%>
-my_mock = mock(name)
-<% end -%>
-
-This creates a new mock with the given <code>name</code> (a string) and
-registers it. When the example finishes, all registered mocks are verified.
-
-<% coderay do -%>
-my_mock = mock(name, stubs)
-<% end -%>
-
-As above, but allows you to set stub return values for specific messages.
-
-### Notes
-
-There are many different viewpoints about the meaning of mocks and stubs. If
-you are interested in learning more, here is some recommended reading:
-
-* Mock Objects: "http://www.mockobjects.com/":http://www.mockobjects.com/
-* Endo-Testing:"http://www.mockobjects.com/files/endotesting.pdf":http://www.mockobjects.com/files/endotesting.pdf
-* Mock Roles, Not Objects: "http://www.mockobjects.com/files/mockrolesnotobjects.pdf":http://www.mockobjects.com/files/mockrolesnotobjects.pdf
-* Test Double Patterns: "http://xunitpatterns.com/Test%20Double%20Patterns.html":http://xunitpatterns.com/Test%20Double%20Patterns.html
-* Mocks aren't stubs: "http://www.martinfowler.com/articles/mocksArentStubs.html":http://www.martinfowler.com/articles/mocksArentStubs.html
View
340 content/rspec-mocks/message-expectations.page
@@ -1,340 +0,0 @@
----
-title: message expectations
-order: 1
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-A message expectation (a.k.a. mock method) is an expectation that an object
-should receive a specific message during the execution of an example.
-
-## expecting messages
-
-<br>
-<% coderay do -%>
-my_mock.should_receive(<message>)
-<% end -%>
-
-The <code>message</code> argument is a symbol that is the name of a message
-that you want the mock to expect.
-
-You can also specify that a message should _not_ be received:
-
-<% coderay do -%>
-my_mock.should_not_receive(:msg)
-<% end -%>
-
-This fails if :msg is ever received.
-
-## expecting arguments
-
-<br>
-<% coderay do -%>
-my_mock.should_receive(:msg).with(<args>)
-my_mock.should_receive(:msg).once.with(<args>)
-<% end -%>
-
-for example:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(1, 2, 3)
-my_mock.should_receive(:msg).once.with(1, 2, 3)
-<% end -%>
-
-The <code>args</code> argument is a series of arguments (e.g. 1, 2, 3) that are
-expected to be passed as arguments to the associated message.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(no_args())
-<% end -%>
-
-The message (<code>msg</code>) is expected to be passed no arguments.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(any_args())
-<% end -%>
-
-Any arguments (and any number of arguments) are to be accepted. This includes
-cases where no arguments are provided. *This is the default when no <code>with()</code>
-clause is specified.* Even so, sometimes you want to be explicit about it.
-
-## argument constraints
-
-Constraints can be placed on individual arguments which are looser than value
-equivalence (as above).
-
-### anything()
-
-accepts any value for this argument, e.g.:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(1, anything(), "A")
-<% end -%>
-
-### an_instance_of(<Class>)
-
-accepts any numeric value for this argument, e.g.:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(a, an_instance_of(Fixnum), "b")
-<% end -%>
-
-### hash_including(<hash>)
-
-accepts a hash (with or without curly braces) representing part of or the entire expected hash, e.g.:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(a, "b", hash_including(:c => 'd'))
-my_mock.should_receive(:msg).with(a, "b", hash_including({:c => 'd'}))
-<% end -%>
-
-These would pass for:
-
-<% coderay do -%>
-my_mock.msg(a, 'b', :c = 'd')
-my_mock.msg(a, 'b', :c = 'd', :e => 'f')
-<% end -%>
-
-but fail without the precise key/value pairs:
-
-<% coderay do -%>
-my_mock.msg(a, 'b', :c = 'e')
-my_mock.msg(a, 'b', :f = 'd')
-<% end -%>
-
-### boolean()
-
-accepts a boolean value for this argument, e.g.:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(a, boolean(), "b")
-<% end -%>
-
-### duck_type(message(s))
-
-accepts any object that responds to the prescribed message(s), e.g.:
-
-<% coderay do -%>
-#accepts a Fixnum for the second arg
-my_mock.should_receive(:msg).with(a, duck_type(:abs, :div), "b")
-<% end -%>
-
-### /regular expressions/
-
-matches a String against a regular expression. If a regular expression is submitted, compares the two expressions for equality
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(/bcd/)
-
-my_mock.msg "abcde" #passes
-my_mock.msg /bcd/ #passes
-my_mock.msg "def" #fails
-my_mock.msg /bcde/ #fails
-<% end -%>
-
-## receive counts
-
-The implicit expectation is that the message passed to <code>should_receive</code> will
-be called once. You can make the expected counts explicit using the following:
-
-### precise counts
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once
-<% end -%>
-
-An exception is raised if the message is never received, or it is received more than once.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).twice
-<% end -%>
-
-An exception is raised if the message is received anything but two times.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).exactly(n).times
-<% end -%>
-
-An exception is raised if the message is received anything but <code>n</code> times.
-
-### relative counts - at_least
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_least(:once)
-<% end -%>
-
-An exception is raised if the message is never received.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_least(:twice)
-<% end -%>
-
-An exception is raised if the message is never received or is received only once.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_least(n).times
-<% end -%>
-
-An exception is raised if the message is received fewer than <code>n</code> times.
-
-### relative counts - at_most
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_most(:once)
-<% end -%>
-
-An exception is raised if the message is received more than once (does not raise if message is never receieved).
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_most(:twice)
-<% end -%>
-
-An exception is raised if the message is received more than twice (does not raise if message is never receieved).
-
-<% coderay do -%>
-my_mock.should_receive(:msg).at_most(n).times
-<% end -%>
-
-An exception is raised if the message is received more than <code>n</code> times (does not raise if message is never receieved).
-
-### explicitly imprecise counts
-
-<% coderay do -%>
-my_mock.should_receive(:msg).any_number_of_times
-<% end -%>
-
-The message can be received 0 or more times.
-
-## return values
-
-### single return value
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_return(<value>)
-<% end -%>
-
-Each time the expected message is received, <code>value</code> will be returned as the result.
-
-### consecutive return values
-
-<% coderay do -%>
-and_return(<value-1>, <value-2>, ..., <value-n>)
-<% end -%>
-
-When the expected message is received, <code>value-i</code> will be returned as
-the result for the ith reception of the message. After the message has been
-received <code>i</code> times, <code>value-n</code> is returned for all
-subsequent receives.
-
-### computed return value
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_return {...}
-<% end -%>
-
-When the expected message is received, the result of evaluating the supplied
-block will be returned as the result. The block is passed any arguments passed
-as arguments of the message. This capability can be used to compute return
-values based on the arguments. For example:
-
-<% coderay do -%>
-my_mock.should_receive(:msg).with(instance_of(Numeric),instance_of(Numeric)).once.and_return {|a, b| a + b}
-<% end -%>
-
-## raising and throwing
-<br>
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_raise(<exception>)
-<% end -%>
-
-Tells the mock to raise an exception instead of returning a value.
-&lt;exception> may be any Exception class, an instance of
-any Exception class, or a String (in which case a RuntimeError will be raised
-with that String as its message).
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_throw(<symbol>)
-<% end -%>
-
-Tells the mock to throw a symbol instead of returning a value.
-
-## yielding
-<br>
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_yield(<value-1>, <value-2>, ..., <value-n>)
-<% end -%>
-
-When the expected message is received, the mock will yield the values to the passed block.
-
-To mock a method which yields values multiple times, and_yield can be chained.
-
-<% coderay do -%>
-my_mock.should_receive(:msg).once.and_yield(<value-0-1>, <value-0-2>, ..., <value-0-n>).
- and_yield(<value-1-1>, <value-1-2>, ..., <value-1-n>).
- and_yield(<value-2-1>, <value-2-2>, ..., <value-2-n>)
-<% end -%>
-
-## ordering
-
-There are times when you want to specify the order of messages sent to a mock.
-It shouldn't be the case very often, but it can be handy at times.
-
-Labeling expectations as being ordered is done by the <code>ordered</code> call:
-
-<% coderay do -%>
-my_mock.should_receive(:flip).once.ordered
-my_mock.should_receive(:flop).once.ordered
-<% end -%>
-
-If the send of <code>flop</code> is seen before <code>flip</code> the specification will fail.
-
-Of course, chains of ordered expectations can be set up:
-
-<% coderay do -%>
-my_mock.should_receive(:one).ordered
-my_mock.should_receive(:two).ordered
-my_mock.should_receive(:three).ordered
-<% end -%>
-
-The expected order is the order in which the expectations are declared.
-
-Order-independent expectations can be set anywhere in the expectation sequence, in any order.
-Only the order of expectations tagged with the <code>ordered</code> call is significant.
-Likewise, calls to order-independent methods can be made in any order, even interspersed with
-calls to order-dependent methods. For example:
-
-<% coderay do -%>
-my_mock.should_receive(:zero)
-my_mock.should_receive(:one).ordered
-my_mock.should_receive(:two).ordered
-my_mock.should_receive(:one_and_a_half)
-
-# This will pass:
-my_mock.one
-my_mock.one_and_a_half
-my_mock.zero
-my_mock.two
-<% end -%>
-
-## arbitrary handling of received messages
-
-You can supply a block to a message expectation. When the message is received
-by the mock, the block is passed any arguments and evaluated. The result is
-the return value of the block. For example:
-
-<% coderay do -%>
-my_mock.should_receive(:msg) { |a, b|
- a.should be_true
- b.should_not include('mice')
- "Chunky bacon!"
-}
-<% end -%>
-
-This allows arbitrary argument validation and result computation. It's handy and kind of cool to be able to
-do this, but it is advised to not use this form in most situations. Mocks should not be functional.
-They should be completely declarative. That said, it's sometimes useful to give them some minimal behaviour.
View
59 content/rspec-mocks/method-stubs.page
@@ -1,59 +0,0 @@
----
-title: method stubs
-order: 2
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-A method stub is an implementation of a method that returns a canned response.
-
-The main difference between a method stub and a "message expectation":message_expectations.html is that message expectations verify interactions that you expect, while method stubs just sit there and return values.
-
-h3. Setting an explicit return value
-
-This is the simplest (and recommended) approach to stubbing.
-
-<% coderay do -%>
-my_instance.stub!(:msg).and_return(value)
-MyClass.stub!(:msg).and_return(value)
-<% end -%>
-
-h3. Calculating a return value
-
-<% coderay do -%>
-my_instance.stub!(:msg).and_return { ... }
-MyClass.stub!(:msg).and_return { ... }
-<% end -%>
-
-While this is possible, it is generally to be avoided. Calculating a value to return defeats the declarative nature of stubs.
-
-h3. Multiple return values
-
-<% coderay do -%>
-my_instance.stub!(:msg).and_return("1",2)
-MyClass.stub!(:msg).and_return("1",2)
-<% end -%>
-
-This will return "1" the first time it is called and 2 every subsequent call. Like calculated return values, this is a little un-stubby, but it can be a handy feature once in a while.
-
-h3. Mixing method stubs and message expectations
-
-In some cases it can be helpful to stub a default return value, but set a message expectation for a specific set of args. For example:
-
-<% coderay do -%>
-A.stub!(:msg).and_return(:default_value)
-A.should_receive(:msg).with(:arg).and_return(:special_value)
-A.msg
-=> :default_value
-A.msg(:any_other_arg)
-=> :default_value
-A.msg(:arg)
-=> :special_value
-A.msg(:any_other_other_arg)
-=> :default_value
-A.msg
-=> :default_value
-<% end -%>
View
48 content/rspec-mocks/other-frameworks.page
@@ -1,48 +0,0 @@
----
-title: other frameworks
-order: 4
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-If you prefer to use a mocking framework other than RSpec's built in framework, you can do this quite simply. RSpec currently supports use of the following frameworks out of the box (in alphabetical order):
-
-* "flexmock":http://flexmock.rubyforge.org/
-* "mocha":http://mocha.rubyforge.org
-* "rr":http://rubyforge.org/projects/pivotalrb/
-
-RSpec supports use of a single framework per project, because these frameworks (including) RSpec's own, tend to add methods to Object that might or might not work well together. To choose a mock framework other than rspec, simply add the following to spec/spec_helper.rb (or any file that gets loaded when you run your examples):
-
-<% coderay do -%>
-Spec::Runner.configure do |config|
- config.mock_with :rr
-end
-<% end -%>
-
-Valid options are <code>:flexmock</code>, <code>:mocha</code>, <code>:rspec</code> (of course), and <code>:rr</code>.
-
-h2. Even more "other" frameworks
-
-If you have a different framework that is not supported directly by RSpec, you can easily choose that framework instead by creating an adapter and telling RSpec where to find it. Here is RSpec's own adapter as an example:
-
-<% coderay do -%><%= IO.read "../rspec-core/lib/rspec/core/mocking/with_rspec.rb" %><% end -%>
-
-This file must require any libraries or resources that implement the framework, and then define a <code>Spec::Plugins::MockFramework</code> module with the following methods:
-
-* <code>setup_mocks_for_rspec</code> is called before each example is run.
-* <code>verify_mocks_for_rspec</code> is called after each example is run. Use this if you want RSpec to automatically verify your mocks after each example. You must supply this method either way, but you can leave it empty if your framework doesn't support auto-verification.
-* <code>teardown_mocks_for_rspec</code> is guaranteed to be run after each example even when there are errors. Use this to ensure that there is no state shared across example, clearing out changes to static resources like class-level mock expectations, etc.
-
-Once you have defined your adapter, you can then tell RSpec to use your adapter like so:
-
-<% coderay do -%>
-Spec::Runner.configure do |config|
- config.mock_with '/path/to/my/adapater.rb'
-end
-<% end -%>
-
-
-
View
21 content/rspec-mocks/partial-mocks.page
@@ -1,21 +0,0 @@
----
-title: partial mocks
-order: 3
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-RSpec allows you to add mock object behaviour to real objects, so you can set "message expectations":message_expectations.html and "method stubs":stubs.html on any object in your system.
-
-One common use of this support is isolating examples from ActiveRecord (and therefore the database) in Ruby on Rails examples.
-
-<% coderay do -%>
-MyModel.should_receive(:find).with(id).and_return(@mock_model_instance)
-<% end -%>
-
-Controlling the behaviour of the class level methods (for example, having them return a mock object instead of a real instance of the model class) allows you to describe your controllers and views in isolation from the instance level logic of your model classes. This means that you can change the validation rules for a model, for example, and drive that in the model examples without affecting the controller and view examples.
-
-This also helps to keep the context of your example completely in view (no having to look at fixtures/xyz.yml to understand what's going on).
View
8 content/rspec-rails/changelog.page
@@ -1,8 +0,0 @@
----
-title: changelog
-order: 9
-filter:
- - erb
- - textile
----
-<pre><%= IO.read '../rspec-rails/Changelog.md' %></pre>
View
139 content/rspec-rails/controllers.page
@@ -1,139 +0,0 @@
----
-title: controllers
-order: 3
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-Controller Examples live in $RAILS_ROOT/spec/controllers/.
-
-In contrast to Test::Unit, where the controller is initialized in the <code>setup</code> method,
-with Spec::Rails you don't. Instead, pass the controller class to the describe method.
-Spec::Rails automatically instantiates a controller for you, which you can access
-from the examples (it blocks) using the <code>controller</code> method.
-
-h2. Isolation from views
-
-By default, Spec::Rails will run your controller actions in isolation from
-their related views. This allows you to spec your controllers before the views
-even exist, and will keep the specs from failing when there are errors in your
-views.
-
-h2. Optional integration with views
-
-If you prefer to integrate views (a la rails functional testing) you can by including
-the keyword/commmand "integrate_views".
-
-<% coderay do -%>
-describe ArticlesController do
- integrate_views
- ...
-end
-<% end -%>
-
-When you integrate views in the controller specs, you can use any of the
-expectations that are specific to views as well. Read about "View Examples":views.html
-to learn more.
-
-h2. Isolation from the database
-
-We strongly recommend that you use RSpec's "mocking/stubbing framework":../../documentation/mocks/index.html
-to intercept class level calls like <code>:find</code>, <code>:create</code> and
-even <code>:new</code> to introduce mock instances instead of real active_record instances.
-
-This allows you to focus your specs on the things that the controller does and not
-worry about complex validations and relationships that should be described in
-detail in the "Model Examples":models.html
-
-<% coderay do -%>
-account = mock_model(Account)
-Account.should_receive(:find).with("37").and_return(account)
-<% end -%>
-
-or
-
-<% coderay do -%>
-account = mock_model(Account)
-Account.stub!(:find).and_return(account)
-<% end -%>
-
-See "Mocks and Stubs":../../documentation/mocks/index.html for more information about the
-built in mocking/stubbing framework.
-
-h2. Response Expectations
-
-These expectations will work whether in isolation or integration mode. See "Spec::Rails::Expectations":../../../rdoc-rails/index.html for details.
-
-h3. response.should be_success
-
-Passes if a status of 200 was returned. NOTE that in isolation mode, this will
-always return true, so it's not that useful - but at least your specs won't break.
-
-<% coderay do -%>
-response.should be_success
-<% end -%>
-
-h3. response.should be_redirect
-
-Passes if a status of 300-399 was returned.
-
-<% coderay do -%>
-response.should be_redirect
-<% end -%>
-
-h3. response.should render_template
-
-<% coderay do -%>
-get 'some_action'
-response.should render_template("path/to/template/for/action")
-<% end -%>
-
-h3. response.should have_text
-
-<% coderay do -%>
-get 'some_action'
-response.should have_text("expected text")
-<% end -%>
-
-h3. response.should redirect_to
-
-<% coderay do -%>
-get 'some_action'
-response.should redirect_to(:action => 'other_action')
-<% end -%>
-
-The following forms are supported:
-
-<% coderay do -%>
-response.should redirect_to(:action => 'other_action')
-response.should redirect_to('path/to/local/redirect')
-response.should redirect_to('http://test.host/some_controller/some_action')
-response.should redirect_to('http://some.other.domain.com')
-<% end -%>
-
-h3. assigns, flash and session
-
-Use these to access assigns, flash and session.
-
-<% coderay do -%>
-assigns[:key]
-flash[:key]
-session[:key]
-<% end -%>
-
-h2. Routing Expectations
-
-Specify the paths generated by custom routes.
-
-<% coderay do -%>
-route_for(:controller => "hello", :action => "world").should == "/hello/world"
-<% end -%>
-
-Specify the parameters generated from routes.
-
-<% coderay do -%>
-params_from(:get, "/hello/world").should == {:controller => "hello", :action => "world"}
-<% end -%>
View
29 content/rspec-rails/helpers.page
@@ -1,29 +0,0 @@
----
-title: helpers
-order: 4
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-Helper Examples live in $RAILS_ROOT/spec/helpers/.
-
-Writing specs for your helpers is a snap. Just tell the Example Group the name of the
-helper ...
-
-<% coderay do -%>
-describe RegistrationHelper do
- ...
-end
-<% end -%>
-
-... and the Example Group will expose an object that includes the helper.
-
-h2. Conveniences
-
-h3. assigns
-
-Use assigns[:key] to set instance variables to be used in the view that
-includes the helper. See example below.
View
154 content/rspec-rails/index.page
@@ -1,154 +0,0 @@
----
-title: rspec-rails
-order: 4
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-The rspec-rails gem extends rspec-core and Rails' built-in testing framework to
-support full-stack, application-level specs (request specs), as well is
-isolated specs for models, views, controllers, helpers, mailers, and routing.
-
-## Install
-
-First, add rspec-rails to your Gemfile:
-
-<% coderay do -%>
-gem "rspec-rails", :group => [:development, :test]
-<% end -%>
-
-It needs to be in the `:development` group to expose the generators and rake
-tasks to your development environment. Otherwise you'd have to type
-`RAILS_ENV=test rails generate ....`, and who wants that?
-
-Now install the bundle and the rspec files and directories:
-
-<% coderay :shell do -%>
-bundle install
-rails generate rspec:install
-<% end -%>
-
-## Directory structure
-
-rspec-rails uses a directory naming convention based on the component being
-spec'd:
-
-<% coderay do -%>
-project
- |
- +--app
- |
- +--...
- |
- +--spec
- |
- +-- spec_helper.rb
- |
- +-- controllers
- |
- +-- helpers
- |
- +-- mailers
- |
- +-- models
- |
- +-- requests
- |
- +-- routing
- |
- +-- support
- |
- +-- views
-<% end -%>
-
-Model, view, controller, helper, mailer, and routing specs each focus on the
-named component.
-
-Request specs wrap Rails' integration tests. These go through the full stack,
-including the router. By themselves, or combined with
-[Capybara](https://github.com/jnicklas/capybara), request specs are a great
-starting point for outside-in development if you're not using another tool like
-[Cucumber](http://cukes.info) or [Fitnesse](http://fitnesse.org). The name
-"request specs" came out of the Merb project. We use that instead of
-"integration" or "acceptance" due to the lack of consensus on what those names
-mean.
-
-The generated `spec_helper.rb` file requires any `.rb` files in the "support"
-directory, which is the conventional container for helpers, custom matchers,
-etc.
-
-## Fixtures
-
-While most of the Rails world uses factories these days, you _can_ still use
-Rails fixtures the same way you would use them in the Rails testing framework.
-First, declare their location in `spec_helper.rb`:
-
-<% coderay do -%>
-RSpec.configure do |config|
- config.fixture_path = "#{::Rails.root}/spec/fixtures"
-end
-<% end -%>
-
-Now declare which fixtures you want to use in each example group:
-
-<% coderay do -%>
-describe WidgetsController do
- fixtures :widgets
-end
-<% end -%>
-
-You can also declare them globally in `spec_helper.rb`:
-
-<% coderay do -%>
-RSpec.configure do |config|
- config.global_fixtures = [:things, :widgets]
-end
-<% end -%>
-
-## Generators
-
-When you include rspec-rails in the `:development` group in your `Gemfile`,
-rspec-rails registers itself with Rails as the generator for tests. The only
-rspec-specific generator you need to know about is `rspec:install`, mentioned
-above. Otherwise, just run the rails generators and you'll get specs for free:
-
-<% coderay do -%>
-rails generate model thing name:string
- invoke active_record
- create db/migrate/20111013140413_create_things.rb
- create app/models/thing.rb
- invoke rspec
- create spec/models/thing_spec.rb
-<% end -%>
-
-## Running specs
-
-### using the `rspec` command
-
-<% coderay do -%>
-rspec path/to/directory/with/specs
-rspec path/to/individual_spec.rb
-rspec glob/pattern/to*/*_be_matched*
-<% end -%>
-
-### using `rake`
-
-When you include rspec-rails in the `:development` group in your `Gemfile`,
-rspec-rails registers several rake tasks
-
-<% coderay do -%>
-$ rake --tasks spec
-rake spec # Run all specs in spec directory (excluding plugin specs)
-rake spec:controllers # Run the code examples in spec/controllers
-rake spec:helpers # Run the code examples in spec/helpers
-rake spec:lib # Run the code examples in spec/lib
-rake spec:mailers # Run the code examples in spec/mailers
-rake spec:models # Run the code examples in spec/models
-rake spec:rcov # Run all specs with rcov
-rake spec:requests # Run the code examples in spec/requests
-rake spec:routing # Run the code examples in spec/routing
-rake spec:views # Run the code examples in spec/views
-<% end -%>
View
11 content/rspec-rails/mailers.page
@@ -1,11 +0,0 @@
----
-title: mailers
-order: 5
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-Coming soon ...
View
34 content/rspec-rails/models.page
@@ -1,34 +0,0 @@
----
-title: models
-order: 1
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-Model Examples live in $RAILS_ROOT/spec/models/ and provide access to fixtures.
-
-h2. Expectations
-
-Model Examples support the following custom expectations.
-See "Spec::Rails::Expectations":../../../rdoc-rails/index.html for more detail.
-
-h3. Records
-
-<% coderay do -%>
-Model.should have(:no).records
-Model.should have(1).record
-Model.should have(3).records
-<% end -%>
-
-This is a shortcut for <code>Model.find(:all).length.should == 3</code>.
-
-h3. Errors
-
-<% coderay do -%>
-model.should have(:no).errors_on(:attribute)
-model.should have(1).error_on(:attribute)
-model.should have(3).errors_on(:attribute)
-<% end -%>
View
11 content/rspec-rails/routing.page
@@ -1,11 +0,0 @@
----
-title: routing
-order: 6
-filter:
- - erb
- - textile
----
-
-h2. <%= @page.title %>
-
-Coming soon ...
View
115 content/rspec-rails/views.page
@@ -1,115 +0,0 @@
----
-title: views
-order: 2
-filter:
- - erb
- - markdown
----
-
-## <%= @page.title %>
-
-View examples live in `spec/views/`.
-
-rspec-rails supports the specification of views in complete isolation from
-their controllers. This allows you to spec and write your views even before
-their controllers exist, or before the related actions have been developed. It
-also means that bugs introduced into controllers will not cause view specs to
-fail.
-
-As noted in the "introduction":index.html, these are great benefits but they
-could hide bugs that exist in the interaction between a controller and its
-view. We strongly recommend combining these isolated view specs with some sort
-of application level functional testing, ideally using
-"Cucumber":http://github.com/aslakhellesoy/cucumber
-
-Here are some of the methods available to you, but see
-"rspec-rails::Expectations":../../../rdoc-rails/index.html for more detail.
-
-## Conveniences
-
-### assigns
-
-Use assigns[:key] to set instance variables to be used in the view. We highly
-recommend that you exploit the mock framework here rather than providing real
-model objects in order to keep the view specs isolated from changes to your
-models.
-
-<% coderay do -%>
-# example
-article = mock_model(Article)
-article.should_receive(:author).and_return("Joe")
-article.should_receive(:text).and_return("this is the text of the article")
-assigns[:article] = article
-assigns[:articles] = [article]
-
-# template
-<%% for article in @articles -%>
-<!-- etc -->
-<% end -%>
-
-### flash, params and session
-
-Use flash[:key], params[:key] and session[:key] to set values in the example
-that can be accessed by the view.
-
-<% coderay do -%>
-# example
-flash[:notice] = "Message in flash"
-params[:account_id] = "1234"
-session[:user_id] = "5678"
-
-# template
-<%%= flash[:notice] %>
-<%%= params[:account_id] %>
-<%%= session[:user_id] %>
-<% end -%>
-
-## Expectations
-
-rspec-rails' View Examples support the following custom expectations.
-
-### response.should have_tag
-
-This wraps assert_select and is available in both View Examples and Controller
-Examples run in integration mode.
-
-<% coderay do -%>
-response.should have_tag('div') #passes if any div tags appear
-response.should have_tag('div#interesting_div')
-response.should have_tag('div', 'expected content')
-response.should have_tag('div', /regexp matching expected content/)
-response.should have_tag('form[action=?]', things_path)
-response.should have_tag("input[type=?][checked=?]", 'checkbox', 'checked')
-response.should have_tag('ul') do
- with_tag('li', 'list item 1')
- with_tag('li', 'list item 2')
- with_tag('li', 'list item 3')
-end
-<% end -%>
-
-Note that any of the hash values can be either Strings or Regexps and will be
-evaluated accordingly.
-
-### response[:capture].should have_tag
-
-This way you can access content that has been captured with
-<tt>content_for</tt>.
-
-<ruby>
-# example
-response[:sidebar].should have_tag('div')
-
-# template
-&lt;% content_for :sidebar do %>
- <div><p>Sidebar content here</p></div>
-&lt;% end %>
-</ruby>
-
-## Mocking and stubbing helpers
-
-If you wish to mock or stub helper methods, this must be done on the
-<tt>template</tt> object:
-
-<% coderay do -%>
-template.should_receive(:current_user).and_return(mock("user"))
-<% end -%>
View
47 lib/rspec_extras.rb
@@ -53,57 +53,16 @@ def rspec_version
end
def breadcrumb_menu(page)
- '<div class="breadcrumb-menu">' + breadcrumbs(page) + menu(page) + '</div>'
+ ""
end
def breadcrumbs(page)
- b = binding
- ERB.new(<<-EOF, nil, '-').result(b)
- <div class="breadcrumbs">
- <ul>
- <% page.path_from_root.each do |p| %>
- <% if p != page %>
- <li><%= p.link %></li>
- <% else %>
- <li class="current"><%= p.link %></li>
- <% end %>
- <% end %>
- </ul>
- </div>
- EOF
+ ""
end
def menu(page)
- pages = if page.filename == 'index'
- (page.siblings + page.immediate_children).sort{|a,b| a.order <=> b.order}
- else
- []
- end
-
- b = binding
- ERB.new(<<-EOF, nil, '-').result(b)
- <div class="menu">
- <ul>
- <% pages.each do |p| %>
- <li>
- <%= p.link %>
- </li>
- <% end %>
- <% if page.url == '/documentation/' %>
- <li>
- <a href="http://rdoc.info/gems/rspec/frames" target="_blank">rdoc</a>
- </li>
- <% end %>
- <% if page.url == '/rails/' -%>
- <li>
- <a href="http://rdoc.info/gems/rspec-rails/frames" target="_blank">rdoc</a>
- </li>
- <% end -%>
- </ul>
- </div>
- EOF
+ ""
end
-
end
end
View
2  upload
@@ -1,2 +1,2 @@
#!/bin/sh
-rsync -av --delete output/ rspec@rspec.info:/www/rspec.info
+rsync -av --delete output/ rspec.info:/www/new.rspec.info
Please sign in to comment.
Something went wrong with that request. Please try again.