[heikodachi]

Hi all

I am new to Ruby and I am currently learning Ruby on Rails. I am learning testing and I was hoping that someone could explain the following line of code to me?

test "should require a name" do
t = Treasure.new
t.name = nil
t.valid?
refute_empty t.errors['name']
end

[sepp2k]

It creates a test called "should require a name", which creates a new Treasure object, sets its name to nil and then runs validations on that object. The test will succeed if the errors array for the object's "name"-property is not empty.

refute_empty is an assertion which succeeds if and only if its argument is not empty, i.e. refute_empty foo is the same as assert !foo.empty? (except that it produces more helpful messages when the test fails).

Generally for every assert_foo assertion, which succeeds if condition foo is met, there's a corresponding refute_foo assertion, which succeeds if condition foo is not met.

[NotarySojac]

To know more about that test code, you'd also need to look at:
(APPNAME/app/models/treasures.rb)

There, you'll likely find a line such as

 validates :name, :presence => true,
                   :length   => { :maximum => 50 }

That treasure model code is ensuring that a :name is "present", so any treasure objects you create, and specify to have a nil name will be considered invalid. Calling myTreasureObj.valid? will return nil.

I might be wrong, but I don't think that, in your code, the line t.valid? has any effect on the test, since it's just returning 'true/false' and nothing else is being done with the value. I might be wrong on this point though, I'm a little more accustomed to the way rspec works than unit::tests.

This post has been edited by NotarySojac: 13 July 2011 - 11:28 AM

[sepp2k]

NotarySojac, on 13 July 2011 - 08:18 PM, said:

I might be wrong, but I don't think that, in your code, the line t.valid? has any effect on the test, since it's just returning 'true/false' and nothing else is being done with the value.

The call to valid? causes the validations to run. If you don't do this t.errors will be empty, whether the object is valid or not - accessing errors does not automatically run the validations.

[NotarySojac]

Oh, I don't think I've encountered that usage of x.errors before.

I just did a rails --console test to get a little more comfortable with it myself. I'll post in case it helps heikodachi.

root@sweets:/home/sweets/dev/rails/sample_app# rails c
Loading development environment (Rails 3.0.7)
ruby-1.9.2-p180 :001 > my_user = User.new()
 => #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil, encrypted_password: nil, salt: nil, admin: false>
ruby-1.9.2-p180 :002 > my_user.errors
 => {}
ruby-1.9.2-p180 :003 > my_user.valid?  # cause my_user.errors to be populated
 => false
ruby-1.9.2-p180 :004 > my_user.errors
 => {:name=>["can't be blank"], :email=>["can't be blank", "is invalid"], :password=>["can't be blank", "is too short (minimum is 6 characters)"]}

Heikodachi, could you post a link to the material you're referencing from?

[heikodachi]

sepp2k and NotarySojac, thank you for your help, your explanations have helped me to better understand this test.

The material that I am referencing from can be found here: https://github.com/h.../dungeon_keeper