Association existence probably isn't all that helpful, but once you
start to use some of the more arcane options then it really, really
helps to have tests around them. I've been burned before by
associations that weren't really working the way I expected them to
(some of the more arcane flags in h
On 10/09/2011, at 4:08 PM, Ben Hoskings wrote:
> My stance is this: those associations are there for a reason: you want to
> somehow relate artists and releases, and do operations on them in tandem, or
> from one to the other. If you directly unit test (ideally, test-drive) those
> operations
I'd argue that none of these tests are necessary.
You're testing that the many-to-many relationship you've set up between Artist
and Release works, but that's already covered in Rails' test suite. You should
only test up to the boundary between your app and rails -- i.e. that you've
correctly d
Warren's spot on. You're testing Rails, not your own code. These days I don't
bother checking whether associations exist - that's something integration tests
will pick up.
--
Pat
On 10/09/2011, at 4:04 PM, Warren Seen wrote:
> There's not really anything wrong with your specs, but the general
There's not really anything wrong with your specs, but the general wisdom is
that there's not a lot of point testing what's essentially part of rails
itself.
In the past, I've used rspec matchers to confirm that models have the correct
associations defined, eg: https://github.com/thoughtbot/sh
Hi ladies and gents
I joined this group a few week ago and keep an eye on it but am a little too
'green' to help out a lot of the time. Instead, my first mail will be to
look for advice!
I'm looking to test some model (HABTM) relationships in a small application
I'm building, and I'm keen to show
