Refactored tests to take into account that plantings now have owners
directly, not via gardens. Mostly this was just tweaking FactoryGirl
calls to do the right thing.
This commit builds off of @Skud's spike on locations and largely takes
off from the `nearby_members` feature which previously existed on
members.
One thing to note is that we needed to add a search route and action to
`PlacesController` to account for requests of new places as they could
not be redirected to properly from within `PlacesController#show`.
[Story #53848631]
When we fetched photos from a photoset, the response object didn't
respond to to_a, breaking our controller code. This turned out to be due
to weirdness in FlickRaw's API:
https://github.com/hanklords/flickraw/issues/58
... by stubbing out Member#flickr_sets in a photo_controller test. I
looked at the flickrmocks gem, but it doesn't seem very helpful - it
still requires you to connect to Flickr.
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.
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.
