1dir = File.dirname(__FILE__)
2
3require 'spec/rails/example/ivar_proxy'
4require 'spec/rails/example/assigns_hash_proxy'
5
6require "spec/rails/example/render_observer"
7require "spec/rails/example/rails_example_group"
8require "spec/rails/example/model_example_group"
9require "spec/rails/example/functional_example_group"
10require "spec/rails/example/controller_example_group"
11require "spec/rails/example/helper_example_group"
12require "spec/rails/example/view_example_group"
13
14module Spec
15 module Rails
16 # Spec::Rails::Example extends Spec::Example (RSpec's core Example module) to provide
17 # Rails-specific contexts for describing Rails Models, Views, Controllers and Helpers.
18 #
19 # == Model Examples
20 #
21 # These are the equivalent of unit tests in Rails' built in testing. Ironically (for the traditional TDD'er) these are the only specs that we feel should actually interact with the database.
22 #
23 # See Spec::Rails::Example::ModelExampleGroup
24 #
25 # == Controller Examples
26 #
27 # These align somewhat with functional tests in rails, except that they do not actually render views (though you can force rendering of views if you prefer). Instead of setting expectations about what goes on a page, you set expectations about what templates get rendered.
28 #
29 # See Spec::Rails::Example::ControllerExampleGroup
30 #
31 # == View Examples
32 #
33 # This is the other half of Rails functional testing. View specs allow you to set up assigns and render
34 # a template. By assigning mock model data, you can specify view behaviour with no dependency on a database
35 # or your real models.
36 #
37 # See Spec::Rails::Example::ViewExampleGroup
38 #
39 # == Helper Examples
40 #
41 # These let you specify directly methods that live in your helpers.
42 #
43 # See Spec::Rails::Example::HelperExampleGroup
44 module Example
45 end
46 end
47end