I'm also struggling to find a good way to extend the assert_uniqueness_of to work for scoped uniqueness.  I have individual tests that work, but they require a more complicated pre-configured fixture.... so moving the tests into the generic code will place additional demands on the conventions surrounding the test suite....  The current requirements I think are reasonable, but adding more might make it less friendly.

Finally I'd like to create an assert_format_of to piggyback on the main assert_attribute_required, via a :format=>/ / add-on.  However, I'm drawing a blank at a good way to dynamically create strings that don't match a given regexp -- other than something brute forice like building a random length random string from a large characters set and looping until it doesn't pass the regexp, and then testing it in the model class.  Generating 5-10 such strings within the test to hopefully exercise more of the possible failure modes.  However that adds non-determinism into testing, which I don't like doing...  Otherwise I'd need to basically write a parallel regexp parser that creates a list of known failing words by going through the regexp and generating an invalid character at each point in the expression while keeping the rest legit....  Anyone know of any existing code that might help me with this?

[PS, any chance we can get a Ruby syntax highlighter for this forum so we can use ruby blocks and not just code blocks?]

You wanted something?

I also think that in order to tie the migratory state of the db to tests (like you mentioned) we'd have to either 1) always revert to a previous code version when testing against a previous migration or 2) require each test method to only execute if the current schema_info.version is above a certain level.

That's not quite what I meant by driving the migrations.  What I'm trying to find a good way to express in test code is the notion of "this class must include the following persist-able attributes"  The simple fact that the class respond_to? the names of the various accessors/mutators isn't enough to imply that those attributes are round-tripped to the DB.  As well as the notion that some attributes aren't persisted -- take a stereotypical User class.  It'll have to deal with "raw" password and password confirmation fields that aren't persisted and the hashed password that is persisted, but set indirectly, etc.

I've started writing a "baby-steps" approach to this, but I'm not happy with where its going, so I'm letting it stew while I hope for inspiration... It needs to be updated to my current level of understanding,  but ....  http://www.verticalexpressionsoftware.c … s-and-tdd/  the back 2/3rd are most applicable to what I'm struggling with.

I first learned TDD from the Astel book, and he was extremely aggressive about refactoring test code.  And I've normally found that being aggressive in refactoring test code keeps you more honest in refactoring production code.   In some sense its the "Broken Window" effect that the Pragmatic Programmers talk about, once you let one place get sloppy, it rapidly degenerates.  In the book for instance he'll have a separate test case for testing a zero element list, versus testing a one-element list.  Both test cases needed a custom setup, that was shared by multiple test methods, thus leading to their separation.  Furthermore often the two setups are slightly similar so you end up extracting a common superclass for them both to inherit from, etc..  The test code quickly gets very DRY.  However it does make naming even more important, a lot of your test case setup (called a fixture in other languages, but not too exactly equal to Rails fixtures) can get pushed to super classes and you might not be able to tell at a quick glance exactly what the state of the object was in pre-test.  If your naming is clear, that solves that problem.  (Rails conventions and those of Test::Rails on top, can get slightly in the way here as well).

Rails makes it slightly hard to refactor functional (or controller under Test::Rails) tests as some of the automated plumbing can get confused, but I've been working through that most of today, and have a workable solution -- ie one that meets my needs and is clean, but not one that is releasable as a plugin/patch.

I also need to covert them to give better default failure messages, they should probably be changed to use assert_block in many cases, and I think I should extract a wrapper lambda/block to remove the duplicated code for retrieving the classname and deal with caching the attribute hash.

These currently live in test_helper.rb

class Test::Unit::TestCase
  self.use_transactional_fixtures = true
  self.use_instantiated_fixtures  = false
    
  protected
  def assert_unique_on (field)
    klass = class_under_test
    cached = @attr_hash.clone
    cached[field]=get_reference_fixture.send(field)
    current = klass.count
    tmp = klass.create(cached)
    assert_field_invalid tmp, field
    assert_equal current, klass.count
    tmp.destroy
  end
  
  
  def assert_attribute_required(field,opt={})
    klass = class_under_test
    cached = @attr_hash.clone
    cached[field]=nil
    obj = klass.new(cached)
    assert_not_valid obj
    assert_field_invalid obj, field
    assert_required_length(field,opt[:length],opt) if opt.has_key? :length
    assert_unique_on(field) if (opt.has_key?(:unique) && opt[:unique])
    assert_confirmation_required(field, opt[:confirmed]) if (opt.has_key?(:confirmed))
  end
  def assert_confirmation_required(field, confirm)
    klass = class_under_test
    cached = @attr_hash.clone
    cached[confirm]=cached[confirm].swapcase.reverse
    obj = klass.new(cached)
    assert_not_valid obj
    assert_field_invalid obj, field
  end
  def assert_required_association(field)
     field_id = (field.to_s + "_id").to_sym
     klass = class_under_test
     cached = @attr_hash.clone
     obj = klass.new
     assert_respond_to obj, ("build_"+field.to_s)
     field_id = (field.to_s + "_id").to_sym
     cached[field_id]=nil
     obj = klass.new(cached)
     assert_not_valid obj
     assert_field_invalid obj, field_id
   end
   def assert_optional_association(field, opts)
      klass = class_under_test
      obj = klass.new
      assert_respond_to obj, field
      assert_respond_to obj.send(field), :find
      assert_instance_of Array, obj.send(field)
    end
   
  def assert_not_valid (obj)
    assert_block("#{obj.to_s} should not be valid.") { !obj.valid?} 
  end
  
  def assert_required_length(field,allowed,opt={})
    klass =class_under_test
    cached = @attr_hash.clone
    failing = [allowed.first-1,allowed.last+1]
    passing = [allowed.first,allowed.last].uniq
    for length in failing do
      populate_field_with_fixed_length_string cached, field, length, opt
      assert_not_valid klass.new(cached)
    end
    for length in passing do
      populate_field_with_fixed_length_string cached, field, length, opt
      assert_valid klass.new(cached)
    end
  end
  def populate_field_with_fixed_length_string(cached, field, length, opt)
    cached[field]='a' * length
    cached[opt[:confirmed]]=cached[field] if opt.has_key? :confirmed
  end
  
  def get_reference_fixture
    return class_under_test.find(1)
  end
  
  def class_under_test
    /([A-Z][A-Za-z_]*)Test/.match(self.class.to_s)
    $1.constantize
  end
  
  private
  def assert_field_invalid(obj, field)
    assert_block("#{obj.to_s}'s #{field.to_s} should be invalid.") {obj.errors.invalid?(field)}
  end
end

Please ignore the "assert_[required|optional]_association" assertions those are initial essays into the solution space, but are no where near solid enough yet.

For reference, could you post the code from your custom asserts?

def test_validations
  assert_attribute_required :username, :length=>(4..20), :unique=>true
  assert_attribute_required :password, :length=>(4..20), :confirmed=>:password_confirmation
  assert_attribute_required :email
end

I'm still working on a similar set of assertions for associations.

[PS, any chance we can get a Ruby syntax highlighter for this forum so we can use ruby blocks and not just code blocks?]

  def test_needs_filename
    p = pages(:about)
    p.filename = nil
    assert_false p.save
    assert_equal 1, p.errors.length
    assert_equal "can't be blank", p.errors.on(:filename)
  end

I believe testing associations and built-in validations is anything but trivial - all my code gets tested.

I also think that in order to tie the migratory state of the db to tests (like you mentioned) we'd have to either 1) always revert to a previous code version when testing against a previous migration or 2) require each test method to only execute if the current schema_info.version is above a certain level.

I haven't personally run into a situation where I needed agile data modeling beyond creating new migrations to handle changes.

How do you approach testing use of the built-in validations, and association link?  (has_many, etc)  Do you feel these fall under the category of "trivial" like a lot of accessors and don't bother testing them?  Do you test them indirectly by normal exercise of the class, etc?

Note that this does assume not just the regular agile development practices, but agile data modeling as well...