thoughtbot / shoulda

Makes tests easy on the fingers and the eyes — Read more

Sort by: Priority | Votes | Last Updated

Loading…

71.

0 votes

Push previous versions to Gemcutter
2 comments Created about 1 month ago by mwilliams

Title

Body
Is Thoughtbot managing the Gemcutter Shoulda gem? The most recent version of the gem is the only one there, it would be nice if we could get a few previous versions as not everyone has migrated to the most recent Shoulda gem and we're trying to get off of Github as a gem host ASAP.
or cancel

Is Thoughtbot managing the Gemcutter Shoulda gem? The most recent version of the gem is the only one there, it would be nice if we could get a few previous versions as not everyone has migrated to the most recent Shoulda gem and we're trying to get off of Github as a gem host ASAP.

Comments

stevenderocher Fri Dec 18 12:01:25 -0800 2009 | link

Yes, all of our gems are available and managed via gem cutter. Thanks for your suggestion to post previous versions of Shoulda. It has been done.

Comment
Yes, all of our gems are available and managed via gem cutter. Thanks for your suggestion to post previous versions of Shoulda. It has been done.
or cancel

stevenderocher Fri Dec 18 12:56:27 -0800 2009 | link

Thanks for your suggestion. This has been done.

Comment
Thanks for your suggestion. This has been done.
or cancel

Parsed with GitHub Flavored Markdown
65.

3 votes

glob urls testing always fails
4 comments Created 2 months ago by kron4eg

Title

Body
#routes.rb map.wiki_page '*wiki_page', :controller => 'wikis', :action => :show_wiki_page #wiki_test.rb should_route :get, "/faq", :controller => "wikis", :action => "show_wiki_page", :wiki_page => ["faq"] this will fail anyway (but should not have been) in my fork I committed patch and test (glog_urls branch) http://github.com/kron4eg/shoulda/commit/a7e001182b762b9a60fe7b54d6a8844772aa0df5 P.S. tested on ruby 1.8.7
or cancel

routes.rb

map.wiki_page '*wiki_page', :controller => 'wikis', :action => :show_wiki_page

wiki_test.rb

should_route :get, "/faq", :controller => "wikis", :action => "show_wiki_page", :wiki_page => ["faq"]

this will fail anyway (but should not have been)

in my fork I committed patch and test (glog_urls branch)
http://github.com/kron4eg/shoulda/commit/a7e001182b762b9a60fe7b54d6a8844772aa0df5

P.S.
tested on ruby 1.8.7

Comments

kron4eg Sun Oct 11 13:50:06 -0700 2009 | link

little, but important, fix
http://github.com/kron4eg/shoulda/commit/b86d799d9d5fff32c8f5b6c5643233b0a8110e3a

Comment
little, but important, fix http://github.com/kron4eg/shoulda/commit/b86d799d9d5fff32c8f5b6c5643233b0a8110e3a
or cancel

eveel Sun Oct 11 13:51:07 -0700 2009 | link

bump

Comment
bump
or cancel

nahy Fri Oct 16 04:36:24 -0700 2009 | link

bump

Comment
bump
or cancel

rmm5t Thu Oct 22 18:29:41 -0700 2009 | link

kron4eg, All taken care of. Thanks for the contribution!

Comment
kron4eg, All taken care of. Thanks for the contribution!
or cancel

Parsed with GitHub Flavored Markdown
61.

0 votes

pending tests (to compliment should)
2 comments Created 3 months ago by adamsalter

Title

Body
Could you add a 'pending' test function call alongside 'should'? Then you could just replace 'should' with 'pending' to effectively comment out tests before implementation. (Pretty sure this functionality doesn't already exist... looked through code and couldn't find it... )
or cancel

Could you add a 'pending' test function call alongside 'should'?

Then you could just replace 'should' with 'pending' to effectively comment out tests before implementation.

(Pretty sure this functionality doesn't already exist... looked through code and couldn't find it... )

Comments

cpytel Wed Sep 30 04:35:26 -0700 2009 | link

Hi, it actually already exists, its called #should_eventually.

thanks,
-Chad

Comment
Hi, it actually already exists, its called #should_eventually. thanks, -Chad
or cancel

adamsalter Wed Sep 30 18:26:42 -0700 2009 | link

Ok.

Not sure... Maybe it's just my old ways of thinking, (ie test/pending test) but that didn't jump immediately to mind.

'should_eventually' kind of implies that it will be executed 'eventually', not that it should be fixed. (I don't even want to say fixed eventually because that implies that it is not urgent).

Could you document this in the README?

I was also going to ask for an alias to 'pending_should', but I'm kind of conflicted.

Comment
Ok. Not sure... Maybe it's just my old ways of thinking, (ie test/pending test) but that didn't jump immediately to mind. 'should_eventually' kind of implies that it will be executed 'eventually', not that it should be fixed. (I don't even want to say fixed eventually because that implies that it is not urgent). Could you document this in the README? I was also going to ask for an alias to 'pending_should', but I'm kind of conflicted.
or cancel

Parsed with GitHub Flavored Markdown
58.

2 votes

subject should roll down
2 comments Created 3 months ago by zdennis

Title

Body
In 2.10.2 subject blocks do not roll down. For example in the belo code, the call to "subject" in the inner-setup block returns nil. class YourTest context "foo" subject { Factory(:foo) } context "when Foo's owner is a superuser" setup do subject.owner.superuser = true end end end end This is easily solved by updating Context#subject_block to ask its parent for its subject_block if it is nil. This will end up being the innermost subject block or nil if there is no subject_block.
or cancel
In 2.10.2 subject blocks do not roll down. For example in the belo code, the call to "subject" in the inner-setup block returns nil.
```
class YourTest
  context "foo"
    subject { Factory(:foo) }

    context "when Foo's owner is a superuser" 
      setup do
        subject.owner.superuser = true
      end
    end
  end
end
```
This is easily solved by updating Context#subject_block to ask its parent for its subject_block if it is nil. This will end up being the innermost subject block or nil if there is no subject_block.
Comments

zdennis Sat Sep 19 12:41:39 -0700 2009 | link

Here's a patch: http://github.com/zdennis/shoulda/commit/08969bb5b5dde32d1dc922353022b12cdce3e36e

Comment
Here's a patch: http://github.com/zdennis/shoulda/commit/08969bb5b5dde32d1dc922353022b12cdce3e36e
or cancel

joshuaclayton Mon Sep 21 20:12:30 -0700 2009 | link

This has been resolved with http://github.com/thoughtbot/shoulda/commit/2e855629f2b04c63dc3cfd2383e581e52a6cd046

Comment
This has been resolved with http://github.com/thoughtbot/shoulda/commit/2e855629f2b04c63dc3cfd2383e581e52a6cd046
or cancel

Parsed with GitHub Flavored Markdown
57.

1 vote

subject should persist during each test run
6 comments Created 3 months ago by zdennis

Title

Body
Right now in 2.10.2 #subject evaluates the #subject_block each time it is called. This means you can't call #subject more than once in a test and have it reference the same subject. It would be nice if #subject was cached per test-run. This would allow you to refer to #subject more than once within a test/example or your own custom macros without having to introduce an unnecessary variable to store reference. This shouldn't affect folks already using "should_blah_blah_blah" macros. If folks need to create more than one subject for an example perhaps provide a new method which will always invoke the subject block. Perhaps #another_subject.
or cancel
Right now in 2.10.2 #subject evaluates the #subject_block each time it is called. This means you can't call #subject more than once in a test and have it reference the same subject. It would be nice if #subject was cached per test-run. This would allow you to refer to #subject more than once within a test/example or your own custom macros without having to introduce an unnecessary variable to store reference.

This shouldn't affect folks already using "should_blah_blah_blah" macros. If folks need to create more than one subject for an example perhaps provide a new method which will always invoke the subject block. Perhaps #another_subject.

Comments
zdennis Sat Sep 19 11:38:25 -0700 2009 | link
So rather than writing...

context "some test" do subject { @foo } setup do @foo = Factory(:foo) end ... end

You'd write:

context "some test" do subject { Factory(:foo) } ... end

Which is less code to express ultimately the same thing.
Comment
So rather than writing... context "some test" do subject { @foo } setup do @foo = Factory(:foo) end ... end You'd write: context "some test" do subject { Factory(:foo) } ... end Which is less code to express ultimately the same thing.
or cancel
zdennis Sat Sep 19 13:59:15 -0700 2009 | link

Here's a patch for this as well... http://github.com/zdennis/shoulda/commit/cbb83f50751e32c14c18f727077818682d8ead8a

Comment
Here's a patch for this as well... http://github.com/zdennis/shoulda/commit/cbb83f50751e32c14c18f727077818682d8ead8a
or cancel
joshuaclayton Sat Sep 19 14:00:26 -0700 2009 | link
Zach,

Since the subject itself isn't very telling as a local variable, why not assign it to one in the context of that should block? For example:

context "An active user" do subject { Factory(:active_user) } should_validate_presence_of :active should "be able to be deactivated" do user_to_deactivate = subject assert user_to_deactivate.active? user_to_deactivate.deactivate! assert user_to_deactivate.inactive? end end

That way, you're dealing with more explicit variable names instead of "subject", which has an implied state is based solely on the context.

The method I've outlined accomplishes few things - it removes the unnecessary instance variable as shown in your first example, it requires no modification of the Shoulda code base, and also gives both you and other developers more explicit local variables instead of referencing "subject" throughout your tests.
Comment
Zach, Since the subject itself isn't very telling as a local variable, why not assign it to one in the context of that should block? For example: context "An active user" do subject { Factory(:active_user) } should_validate_presence_of :active should "be able to be deactivated" do user_to_deactivate = subject assert user_to_deactivate.active? user_to_deactivate.deactivate! assert user_to_deactivate.inactive? end end That way, you're dealing with more explicit variable names instead of "subject", which has an implied state is based solely on the context. The method I've outlined accomplishes few things - it removes the unnecessary instance variable as shown in your first example, it requires no modification of the Shoulda code base, and also gives both you and other developers more explicit local variables instead of referencing "subject" throughout your tests.
or cancel
zdennis Sat Sep 19 14:18:56 -0700 2009 | link

Josh, your example covers one possible case, which I find to be redundant. Besides having been explicit in the context description, "An active user", you are already being explicit in the subject block, "Factory(:active_user)". The additional "user_to_deactivate" doesn't continue the story, it simply repeats it. We already know we're working with an active user.

Another example which comes into play is modular functionality that can get included on other objects, like "acts_as_..." in Rails models. When writing something modular like that I will pull out my own macro which I can drop into my model's test to make sure it's working. In those cases I may have a user, a group, a person, an account, a project, etc. So I lose the explicit specificity in that macro code. And simply having another variable assignment to say "@thing_to_deactivate = subject" feels unnecessary. The convention is "subject", I already know the "subject" is what I'm de-activating.

Convention wins out here IMO. If we're going to rely on #subject let's use it to its maximum potential.

Comment
Josh, your example covers one possible case, which I find to be redundant. Besides having been explicit in the context description, "An active user", you are already being explicit in the subject block, "Factory(:active_user)". The additional "user_to_deactivate" doesn't continue the story, it simply repeats it. We already know we're working with an active user. Another example which comes into play is modular functionality that can get included on other objects, like "acts_as_..." in Rails models. When writing something modular like that I will pull out my own macro which I can drop into my model's test to make sure it's working. In those cases I may have a user, a group, a person, an account, a project, etc. So I lose the explicit specificity in that macro code. And simply having another variable assignment to say "@thing_to_deactivate = subject" feels unnecessary. The convention is "subject", I already know the "subject" is what I'm de-activating. Convention wins out here IMO. If we're going to rely on #subject let's use it to its maximum potential.
or cancel
zdennis Sat Sep 19 14:24:57 -0700 2009 | link
Personally, I find it cleaner to right the example you provided as:

context "Deactivating a user" do subject { Factory(:active_user) } should "set active to false" do subject.deactivate! assert !subject.active? end should "set inactive to true" do subject.deactivate! assert subject.inactive? end end

No unnecessary noise, and the context I'm working in is short enough I don't need to introduce additional local variables to help me try to remember that I'm working with a user.
Comment
Personally, I find it cleaner to right the example you provided as: context "Deactivating a user" do subject { Factory(:active_user) } should "set active to false" do subject.deactivate! assert !subject.active? end should "set inactive to true" do subject.deactivate! assert subject.inactive? end end No unnecessary noise, and the context I'm working in is short enough I don't need to introduce additional local variables to help me try to remember that I'm working with a user.
or cancel
jferris Mon Sep 21 14:15:31 -0700 2009 | link

This has been merged in. Thanks for the patch.

Comment
This has been merged in. Thanks for the patch.
or cancel

Parsed with GitHub Flavored Markdown
55.

0 votes

shouda runs setup many times
3 comments Created 4 months ago by boriscy

Title

Body
Shoulda runs setup many times Iam using using nested_attributes in Rails. It runs the setup for each should test. <pre> <code> require 'test_helper' require 'mocha' # En este caso no utilizamos el test por defecto de Rails # sino que usamos una gem llamada shoulda, para poder ver la configuracion # deben ir a: config/environments/test.rb class InventarioTest < Test::Unit::TestCase should_belong_to :almacen should_have_many :inventario_detalles should_validate_presence_of :almacen_id context "Creacion" do setup do @fecha = DateTime.now DateTime.stubs(:now).returns(@fecha) @inventario = Inventario.new(:descripcion => 'Prueba', :tipo => 'ingreso', :almacen_id => 1) @inventario.inventario_detalles_attributes = [ {:item_id => 1, :cantidad => 2, :precio_unitario => 1.5}, {:item_id => 2, :cantidad => 1, :precio_unitario => 1}] @inventario.save! # This line will print for each should test there is, in this case 2 times puts "Stock Creation: #{Stock.find_by_item_id_and_almacen_id(1,1).valor_inventario}" end should "debe tener fecha" do assert_equal @fecha, @inventario.fecha puts "test fecha" end should "have 2 items" do assert_equal 2, @inventario.inventario_detalles.size puts "test items" end end </code> </pre>
or cancel
Shoulda runs setup many times Iam using using nested_attributes in Rails. It runs the setup for each should test.
```
require 'test_helper'
require 'mocha'

# En este caso no utilizamos el test por defecto de Rails
# sino que usamos una gem llamada shoulda, para poder ver la configuracion
# deben ir a: config/environments/test.rb

class InventarioTest < Test::Unit::TestCase
  should_belong_to :almacen
  should_have_many :inventario_detalles

  should_validate_presence_of :almacen_id

  context "Creacion" do
    setup do
      @fecha = DateTime.now
      DateTime.stubs(:now).returns(@fecha)

      @inventario = Inventario.new(:descripcion => 'Prueba', :tipo => 'ingreso', :almacen_id => 1)
      @inventario.inventario_detalles_attributes = [ {:item_id => 1, :cantidad => 2, :precio_unitario => 1.5},
            {:item_id => 2, :cantidad => 1, :precio_unitario => 1}]
      @inventario.save!
      # This line will print for each should test there is, in this case 2 times
      puts "Stock Creation: #{Stock.find_by_item_id_and_almacen_id(1,1).valor_inventario}"
    end

    should "debe tener fecha" do
      assert_equal @fecha, @inventario.fecha
      puts "test fecha"
    end

    should "have 2 items" do
      assert_equal 2, @inventario.inventario_detalles.size
      puts "test items"
    end
end
```
Comments

thoughtbot Wed Sep 09 06:31:50 -0700 2009 | link

This is what is supposed to happen. The setup and teardown gets run before and after each test so they run in isolation, without side effects from other tests.

Comment
This is what is supposed to happen. The setup and teardown gets run before and after each test so they run in isolation, without side effects from other tests.
or cancel

boriscy Wed Sep 09 12:59:06 -0700 2009 | link

Thanx, I hava tested it and you are right, I would like to make it possible not to repeat each time the setup, because I want to first create, then edit, and delete, and this Model affects other model when chages are made.

Comment
Thanx, I hava tested it and you are right, I would like to make it possible not to repeat each time the setup, because I want to first create, then edit, and delete, and this Model affects other model when chages are made.
or cancel

briandoll Wed Sep 09 13:35:44 -0700 2009 | link

If you have dependencies between tests, it's best to nest the context blocks to match those dependencies.

For example, you my have a context that sets up a valid AR object, with several tests against it. Inside the scope of that context, start another context that edits that AR object, and run tests against it.

Keep in mind that when a test in a nested context runs, it runs the setup block for the outer-most context on down, in order.

If setting up related models is a pain point, check out factory girl. Using the two together makes for happy tests the world over.

Comment
If you have dependencies between tests, it's best to nest the context blocks to match those dependencies. For example, you my have a context that sets up a valid AR object, with several tests against it. Inside the scope of that context, start another context that edits that AR object, and run tests against it. Keep in mind that when a test in a nested context runs, it runs the setup block for the outer-most context on down, in order. If setting up related models is a pain point, check out factory girl. Using the two together makes for happy tests the world over.
or cancel

Parsed with GitHub Flavored Markdown
50.

0 votes

Status of test suite against ruby19
1 comment Created 5 months ago by drnic

Title

Body
When running "rake" within ruby19 the current status of tests (which all pass in ruby1.8.6) is: 463 tests, 596 assertions, 10 failures, 20 errors, 0 skips
or cancel
When running "rake" within ruby19 the current status of tests (which all pass in ruby1.8.6) is:
```
463 tests, 596 assertions, 10 failures, 20 errors, 0 skips
```
Comments

qrush Fri Aug 21 13:02:44 -0700 2009 | link

Shoulda is passing on my machine with: ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.5.0]. We also build shoulda with 1.8.7 and 1.9 on our CI server: http://ci.thoughtbot.com/

If you could open up issues with the specific issues/failures you're seeing that would be great. I'd also make sure you're on p129 or greater of 1.9.

Comment
Shoulda is passing on my machine with: `ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.5.0]`. We also build shoulda with 1.8.7 and 1.9 on our CI server: http://ci.thoughtbot.com/ If you could open up issues with the specific issues/failures you're seeing that would be great. I'd also make sure you're on p129 or greater of 1.9.
or cancel

Parsed with GitHub Flavored Markdown
34.

0 votes

Confusing behavior of should_allow_values_for
2 comments Created 7 months ago by matflores

Title

Body
Should_allow_values_for will only fail if you use a value that doesn't pass an existing validates_format_of validation (well, actually any validation that uses the :invalid error). I would expect should_allow_values_for to fail if there is ANY error, and should_not_allow_values_for to pass if it detects ANY error (unless the the :message option is used). I have created a patch for this at: http://github.com/matflores/shoulda/tree/should_allow_values_for_fix Instead of allowing the :message option on should_allow_values_for macro, what I did was to make the test fail if ANY error is detected on the specified attribute. And should_not_allow_values_for still handles the :message option if present, but if it's omitted it will pass as long as it detects ANY error on the specified attribute. Personally I expect that if I say "attr should accept 'xyz'" then the value 'xyz' should pass all validations for attr, without having to worry about the messages I would expect to get if I had passed an invalid (and different) value. But that's just my opinion, of course. See the full discussion about this issue at: https://thoughtbot.lighthouseapp.com/projects/5807/tickets/194-should_allow_values_for-macro-always-passes
or cancel

will only fail if you use a value that doesn't pass an existing validates_format_of validation (well, actually any validation that uses the :invalid error).

I would expect should_allow_values_for to fail if there is ANY error, and should_not_allow_values_for to pass if it detects ANY error (unless the the :message option is used).

I have created a patch for this at:
http://github.com/matflores/shoulda/tree/should_allow_values_for_fix

Instead of allowing the :message option on should_allow_values_for macro, what I did was to make the test fail if ANY error is detected on the specified attribute. And should_not_allow_values_for still handles the :message option if present, but if it's omitted it will pass as long as it detects ANY error on the specified attribute.

Personally I expect that if I say "attr should accept 'xyz'" then the value 'xyz' should pass all validations for attr, without having to worry about the messages I would expect to get if I had passed an invalid (and different) value. But that's just my opinion, of course.

See the full discussion about this issue at: https://thoughtbot.lighthouseapp.com/projects/5807/tickets/194-should_allow_values_for-macro-always-passes

Comments

jferris Tue Jun 09 17:43:19 -0700 2009 | link

I merged this into master earlier today. Thanks.

Comment
I merged this into master earlier today. Thanks.
or cancel

sethladd Tue Jun 09 21:03:24 -0700 2009 | link

yay! thanks! This always bugged me.

Comment
yay! thanks! This always bugged me.
or cancel

Parsed with GitHub Flavored Markdown
32.

0 votes

Change should_change to accept a block
1 comment Created 7 months ago by matflores

Title

Body
I have updated both should_change and should_not_change to accept a string description and a block. The "old" behavior is still maintained but will display a deprecation warning. You can find the updated code in my fork: http://github.com/matflores/shoulda/tree/should_change_with_block For more details please see the complete discussion at Lighthouse: https://thoughtbot.lighthouseapp.com/projects/5807/tickets/154-change-should_change-to-use-a-block
or cancel

I have updated both should_change and should_not_change to accept a string description and a block.

The "old" behavior is still maintained but will display a deprecation warning.

You can find the updated code in my fork: http://github.com/matflores/shoulda/tree/should_change_with_block

For more details please see the complete discussion at Lighthouse:

https://thoughtbot.lighthouseapp.com/projects/5807/tickets/154-change-should_change-to-use-a-block

Comments

jferris Tue Jun 09 17:39:37 -0700 2009 | link

Thanks for the patch. I merged this in earlier today.

Comment
Thanks for the patch. I merged this in earlier today.
or cancel

Parsed with GitHub Flavored Markdown
26.

0 votes

bug
x

should_assign_to should raise invalid option when :equal is passed
1 comment Created 7 months ago by qrush

Title

Body
**Reported by gaffo** When using should assign to, if you accidentally put in :equal, it silently works and does not check the :equals condition. It should either raise invalid options for anything it's not expecting, or it should handle :equal and :equals.
or cancel

Reported by gaffo

When using should assign to, if you accidentally put in :equal, it silently works and does not check the :equals condition. It should either raise invalid options for anything it's not expecting, or it should handle :equal and :equals.

Comments

qrush Tue Jun 09 08:24:56 -0700 2009 | link

Actually invalid, the method doesn't accept this option anymore.

Comment
Actually invalid, the method doesn't accept this option anymore.
or cancel

Parsed with GitHub Flavored Markdown
16.

0 votes

bug
x

ArgumentError: interning empty string
2 comments Created 7 months ago by qrush

Title

Body
**Reported by Justin** In my tests I use `should_not_allow_values_for`. After I updated to Rails 2.3.2 I started getting the following error: <pre> test: User should not allow login to be set to "testguy!". (UserTest): ArgumentError: interning empty string /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:7:in `to_sym' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:7:in `pretty_error_messages' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:5:in `map' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:5:in `pretty_error_messages' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/matchers/allow_value_matcher.rb:95:in `error_description' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/matchers/allow_value_matcher.rb:52:in `negative_failure_message' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/assertions.rb:56:in `assert_rejects' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/macros.rb:174:in `__bind_1237419160_416826' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `call' /Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `test: User should not allow login to be set to "testguy!". ' </pre>
or cancel
Reported by Justin

In my tests I use should_not_allow_values_for. After I updated to Rails 2.3.2 I started getting the following error:
```
test: User should not allow login to be set to "testguy!". (UserTest):
ArgumentError: interning empty string
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:7:in `to_sym'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:7:in `pretty_error_messages'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:5:in `map'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/helpers.rb:5:in `pretty_error_messages'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/matchers/allow_value_matcher.rb:95:in `error_description'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/matchers/allow_value_matcher.rb:52:in `negative_failure_message'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/assertions.rb:56:in `assert_rejects'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/active_record/macros.rb:174:in `__bind_1237419160_416826'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `call'
/Library/Ruby/Gems/1.8/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `test: User should not allow login to be set to "testguy!". '
```
Comments

bandito Wed Sep 23 00:21:03 -0700 2009 | link

I think this error actually comes from a call to I18n.translate. I had an error message for one of my validations that was something like 'blah blah blah...blah blah' and the I18n splits on the dots , ending up with two empty strings (normalize_translation_keys in i18n.rb).

Comment
I think this error actually comes from a call to I18n.translate. I had an error message for one of my validations that was something like 'blah blah blah...blah blah' and the I18n splits on the dots , ending up with two empty strings (normalize_translation_keys in i18n.rb).
or cancel

mjankowski Fri Dec 11 17:35:09 -0800 2009 | link

Yes, this is an I18n bug, from the version of the lib bundled with rails.

Comment
Yes, this is an I18n bug, from the version of the lib bundled with rails.
or cancel

Parsed with GitHub Flavored Markdown
13.

0 votes

bug
x

patch
x

Rails 2.3 Functional Test Failures
1 comment Created 7 months ago by qrush

Title

Body
The problem and my potential solution is outlined here: http://groups.google.com/group/shoulda/browse_thread/thread/8c0a66c80ff4fd76 Patch: http://pastie.org/418093
or cancel

The problem and my potential solution is outlined here:

http://groups.google.com/group/shoulda/browse_thread/thread/8c0a66c80ff4fd76

Patch:

http://pastie.org/418093

Comments

rmm5t Thu Sep 24 06:58:45 -0700 2009 | link

This looks like an old clearance issue that was later resolved. assert_template expects a string, not a symbol, and Shoulda handles this correctly inside should_render_template. Closing.

Comment
This looks like an old clearance issue that was later resolved. `assert_template` expects a string, not a symbol, and Shoulda handles this correctly inside `should_render_template`. Closing.
or cancel

Parsed with GitHub Flavored Markdown
3.

0 votes

docs
x

patch
x

Clarify README
1 comment Created 7 months ago by railsdog

Title

Body
Added a helpful clarification to README. Absence of this code caused me some unnecessary confusion. http://github.com/railsdog/shoulda/commit/632b0452d813957a92bc08873158e020d3db3af8
or cancel

Added a helpful clarification to README. Absence of this code caused me some unnecessary confusion.

http://github.com/railsdog/shoulda/commit/632b0452d813957a92bc08873158e020d3db3af8

Comments

qrush Mon Jun 08 08:55:24 -0700 2009 | link

Just merged this in. Thanks!

Comment
Just merged this in. Thanks!
or cancel

Parsed with GitHub Flavored Markdown
1.

0 votes

Adding a rspec macro for validates_format_of
3 comments Created 7 months ago by stevenbristol

Title

Body

or cancel

Comments

stevenbristol Fri May 15 14:12:22 -0700 2009 | link

Here is my commit: http://github.com/stevenbristol/shoulda/commit/a0cf3c29b1841f920b1d4dd0a5053c32dedd367c

Comment
Here is my commit: http://github.com/stevenbristol/shoulda/commit/a0cf3c29b1841f920b1d4dd0a5053c32dedd367c
or cancel

amerine Fri May 15 17:18:58 -0700 2009 | link

great idea

Comment
great idea
or cancel

dancroak Tue Jun 02 18:00:54 -0700 2009 | link

Committed.

Comment
Committed.
or cancel

Parsed with GitHub Flavored Markdown