> if you're doing proper BDD or TDD, a lot of unit tests are just unnecessary
Could you maybe clarify this a bit? If you mean unit tests of private methods, or avoiding overarchitecting (YAGNI), then I agree. But to me testing the existence of associations certainly falls within the remit of BDD--it's part of your class's public API, it's one of its responsibilities, and to test it exercises the behavior of that class. All a basic test of an association says is that there exists a method with that name, and when you call it under certain circumstances then it responds in certain ways--for example, with an empty array when called on a new instance of an object. It doesn't say anything about the way you've gone about declaring that method, nor should it (in this case, with an assist from ActiveRecord). If you decided to ditch those ActiveRecord associations tomorrow and custom-design a method that does the same thing, those tests would have value, because you'd want to make sure that class's behavior with regard to its collaborators remains unchanged. If you skip these tests, you're technically cheating a bit, aren't you? You have knowledge about the contents of that class, and you're choosing not to exercise that behavior because it seems self-evident. Brian -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
