small medium large xlarge

02 Jul 2012, 19:03
Jeff Lim (9 posts)

in chapter 7, task b, in the test on the product price (depot_c/test/unit/product_test.rb), why is there the need to provide that funky string (I am referring to ‘; ‘) to the join method? It seems totally unnecessary, and really, I dont know what the thought was to use such a string.

You could simply join with ‘’ - or even just call “.join” without providing an argument. Using “.join(‘; ‘)” just raises more questions than necessary, and doesnt even prove anything. Sorry if i sound a bit pissed, but… i am. I would rather have a book (AND code!) that’s straightforward without trying to be fancy…

02 Jul 2012, 20:08
Sam Ruby (633 posts)

Indeed, that could be clearer. What would you think about my replacing:

    assert_equal "must be greater than or equal to 0.01", 
      product.errors[:price].join('; ')

… with:

    assert_equal ["must be greater than or equal to 0.01"],
03 Jul 2012, 01:28
Jeff Lim (9 posts)

Way better, thanks!

I was initially hoping for (and did try out on my own) an “assert_contains” - but apparently there isnt such a check…. But i just found an alternative:

assert product.errors[:price].include? ‘must be greater than or equal to 0.01’

So then we give space for other errors to creep in as well. What do u think? In some sense, we just care that ONE of the error messages should be the one we’re looking for. Our invalid values might trigger other error messages (perhaps in the future), but for the purpose of our test, we want to make sure that at least one of them is this one we’re looking for? (But of course we still keep that last “assert product.valid?” test!)

03 Jul 2012, 12:55
Sam Ruby (633 posts)

If other errors “creep in” without being noticed then that’s a problem.

My thoughts are that if another change is made in the future that causes these results to change, then that change should be flagged by a failing test. If, upon inspection of the failure, the decision is made to change the test, then that change should be made at that time.

While we appear to differ on this hopefully minor point of philosophy, I’m glad that this part of the book got you thinking and exploring!

03 Jul 2012, 15:10
Jeff Lim (9 posts)

right. Well my personal thoughts are that if we want to account for other errors due to having more validations in the future, we can just tag on another similar “assert product.errors[:price].include?” check.

And yeah, I’m personally glad too to have gone on this process. Even more so to have had your presence along the way!

You must be logged in to comment