Module | Shoulda::ClassMethods |
In: |
lib/shoulda/context.rb
|
Before statements are should statements that run before the current context‘s setup. These are especially useful when setting expectations.
class UserControllerTest < Test::Unit::TestCase context "the index action" do setup do @users = [Factory(:user)] User.stubs(:find).returns(@users) end context "on GET" do setup { get :index } should respond_with(:success) # runs before "get :index" before_should "find all users" do User.expects(:find).with(:all).returns(@users) end end end end
A context block groups should statements under a common set of setup/teardown methods. Context blocks can be arbitrarily nested, and can do wonders for improving the maintainability and readability of your test code.
A context block can contain setup, should, should_eventually, and teardown blocks.
class UserTest < Test::Unit::TestCase context "A User instance" do setup do @user = User.find(:first) end should "return its full name" assert_equal 'John Doe', @user.full_name end end end
This code will produce the method "test: A User instance should return its full name. ".
Contexts may be nested. Nested contexts run their setup blocks from out to in before each should statement. They then run their teardown blocks from in to out after each should statement.
class UserTest < Test::Unit::TestCase context "A User instance" do setup do @user = User.find(:first) end should "return its full name" assert_equal 'John Doe', @user.full_name end context "with a profile" do setup do @user.profile = Profile.find(:first) end should "return true when sent :has_profile?" assert @user.has_profile? end end end end
This code will produce the following methods
Just like should statements, a context block can exist next to normal def test_the_old_way; end tests. This means you do not have to fully commit to the context/should syntax in a test file.
Returns the class being tested, as determined by the test class name.
class UserTest; described_type; end # => User
Should statements are just syntactic sugar over normal Test::Unit test methods. A should block contains all the normal code and assertions you‘re used to seeing, with the added benefit that they can be wrapped inside context blocks (see below).
class UserTest < Test::Unit::TestCase def setup @user = User.new("John", "Doe") end should "return its full name" assert_equal 'John Doe', @user.full_name end end
…will produce the following test:
Note: The part before should in the test name is gleamed from the name of the Test::Unit class.
Should statements can also take a Proc as a :before option. This proc runs after any parent context‘s setups but before the current context‘s setup.
context "Some context" do setup { puts("I run after the :before proc") } should "run a :before proc", :before => lambda { puts("I run before the setup") } do assert true end end
Should statements can also wrap matchers, making virtually any matcher usable in a macro style. The matcher‘s description is used to generate a test name and failure message, and the test will pass if the matcher matches the subject.
should validate_presence_of(:first_name).with_message(/gotta be there/)
Just like should, but never runs, and instead prints an ‘X’ in the Test::Unit output.
Allows negative tests using matchers. The matcher‘s description is used to generate a test name and negative failure message, and the test will pass unless the matcher matches the subject.
should_not set_the_flash
Sets the return value of the subject instance method:
class UserTest < Test::Unit::TestCase subject { User.first } # uses the existing user should validate_uniqueness_of(:email) end