Rails Strange Unit Test Fails

rails strange unit test fails

Quote from http://guides.rubyonrails.org/testing.html

Rails by default automatically loads all fixtures from the
test/fixtures folder for your unit and functional test. Loading
involves three steps:

• Remove any existing data from the table corresponding to the fixture
• Load the fixture data into the table
• Dump the fixture data into a
  variable in case you want to access it directly

So I think you need to check those fixtures. Also I suggest you to read that tutorial. It is very well written.

Having trouble with unit test in Rails (newbie). Strange and unexpected behavior

Based the way you are wording your question, I am guessing that you don't fully understand how fixtures work. The fixture files ('things.yml' in your case), are used to load objects into the database to be available as sample data during each test. When you run Thing.all, you are seeing the models that the fixture files have created for you.

There is also no reason (probably) for you to be assigning the :id for your models during your test. Generally, rails will create an auto-incrementing database field, and will handle setting the id for you when the item is saved. (There are exceptional cases that require your setting the id, but this is not the norm.)

To get back to your problem, here is the error message causing the failure you are seeing:

    :name => [
        [0] "has already been taken"
    ]

This is because your validation requirement validates :name, :uniqueness => true checks that a name is unique (not used by more than one record), and isn't going to let you reuse an existing :name - in this case one of the fixtures is already using it (the one whose attributes you are copying). You'll either need to modify your test (change the :name of the new model you want to create), or change the validation rules.

Another option for testing you may want to consider would be to use a factory (like FactoryGirl), rather than fixtures to create your test models.

Rails, RSpec unit test failing for username

Ok, having read around it appears this may actually be a bug related to the shoulda matcher for some edge case when testing for uniqueness with a NOT NULL database constraint on a different column.

https://github.com/thoughtbot/shoulda-matchers/issues/600

As a workaround I would suggest that you explicitly set up a valid model and allow the shoulda matcher to do its own thing on the attribute to be tested. You can set the subject that all shoulda matchers should use like so:

describe User do
  subject { User.new(
    username: 'username',
    seeking_coach: 'coach',
    #
    # set other valid attributes here
    #
  )}

  it { should have_valid(:username).when('Groucho', 'Marx')}
  it { should_not have_valid(:username).when(nil, '')}
  it { should validate_uniqueness_of(:username) }
end

Of course if you are using FactoryGirl, and have a user factory that can build a valid user, then you can simply use:

subject { FactoryGirl.build(:user) }

Now all the shoulda matcher tests will use that object to run the tests with, and you shouldn't get database constraint issues for an attribute you aren't testing.

Strange Error when Unit Testing a particular function in Ruby

The line

skip(small_list, :verb)

makes your test skip through the whole list (2 verbs). Finally, it is empty.
So small_list.firstis nil which has no method/field word.

I get the error

undefined method `word' for nil:NilClass (NoMethodError)

though.

Probably in your code this exception is caught by some other code which itself raises the exception you are seeing.

UPDATE

It turns out in Ruby 1.9's test/unit (more specifically in the minitest/unit it is based on), there is a method skip which collides with your skip. See minitest/unit.rb, line 610. That method raised the exception because it expected its 2nd parameter to be an array.

Just rename your skip.

Jenkins succeed when unit test fails (Rails)

Jenkins executes the commands you type into a Build Step box by writing them to a temporary file and then running the script using /bin/sh -xe.

Usually this produces the desired effect: Commands are executed in sequence (and printed) and the script aborts immediately when a command fails i.e. exits with non-zero exit code.

If this is not happening to you, the only reason can be that you have overridden this behavior. You can override it by starting the first line of your Build Step with these two characters: #!.

For example, if your Build Step looks like this:

#!/bin/bash
bundle install
rake db:migrate:reset
rake test:units
rake spec:models

Then it means Jenkins will write the script to a temporary file and it will be executed with /bin/bash. When invoked like that, bash will execute commands one-by-one and not care if they succeed. The exit code of the bash process will be the exit code of the last command in the script and that will be seen by Jenkins when the script ends.

So, take care in what you put on the first line of the Build Step. If you do not know how shell works, do not put a hash-bang at all and let Jenkins decide how the script should be run.

If you need more control over how the Build Step is executed, you should study the man page of the shell you use to find out how to make it behave the way you want. Jenkins doesn't have much of a role in here. It just executes the shell you wanted the way you wanted.

Rails: Old, non-existant database table causes tests to error

Check the test folder for a fixture file called vendors.yml. If it's there and you don't have a vendors tabler, you'll get those errors because Rails is, by default, trying to populate your vendors table with data from that file.

---

Related Topics