the tests generated by 'rails g scaffold...' are boring and brittle.
they don't actually test anything other than the rails framework, and
they were causing us all kinds of trouble. we've started to blow them
away (and raised a PT chore to remove them from other controllers in due
course).
- still trying to make sure we explicitly use a real member, not just
assume there's one with id = 1
- also it looks like the tests for post activity are passing for obscure
reasons on sqlite when they shouldn't be. this is a known bug
(https://www.pivotaltracker.com/story/show/51280861) apparently
invisible to us under sqlite.
The old order total method did not account for quantities. The
view test for order totals was not catching this, so we've
strengthened it. We also added a conversion link to the order
summary page and created an additional test to check that orders
with more than one item were generating the correct total.
Tests used to check that the default account type was always "Free".
Now that we have a default account type as a config variable, the
tests test to see the default account type matches the value of that
variable.
PT: https://www.pivotaltracker.com/story/show/51457917
Maco found this. The problem was that if you had a blank planting date,
and then re-edited the planting, it would say "not yet set" in the form
field, then die when it later tried to convert that to a date.
I replaced Miles's planted_at_string stuff in the model with a simpler
parse_date method in the application helper.
It seems this interacts badly with the default_scope on postgres (but
not on sqlite3). Error message from the logs:
2013-06-01T02:21:05.312099+00:00 app[web.1]: ActiveRecord::StatementInvalid (PG::Error: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list
2013-06-01T02:21:05.312099+00:00 app[web.1]: LINE 1: ...photo_id" = 2 AND "plantings"."id" = 181 ORDER BY created_at...
2013-06-01T02:21:05.312099+00:00 app[web.1]: app/controllers/photos_controller.rb:59:in `create'
2013-06-01T02:21:05.312099+00:00 app[web.1]: ^
2013-06-01T02:21:05.312099+00:00 app[web.1]: : SELECT DISTINCT 1 AS one FROM "plantings" INNER JOIN "photos_plantings" ON "plantings"."id" = "photos_plantings"."planting_id" WHERE "photos_plantings"."photo_id" = 2 AND "plantings"."id" = 181 ORDER BY created_at desc LIMIT 1):
For now, we'll just have to rely on the controller (which adds the
association) to keep things unique.
Strictly speaking this doesn't prevent you adding them if you really
try, but the validation for that was beyond what I could figure out (the
docs don't help, and all SO/blog posts are outdated and didn't
work).
However, if you do somehow manage to add dups, you will never see them
again thanks to the :uniq => true in the model. That's good enough for
me.
Set up a validation to make sure there's only ever one account_detail
attached to a member. This broke a bunch of tests, and means you
basically can't use a factory to generate account details. Instead, to
test account details, create a member and then look at their account
details.
