Dan: Tks for the advice, i agree that the specs should test the outward behaviors of a model, rather than the internal declarations.
Roy: yup, i agree that it is probably a good project. I'll probably be focusing on testing the outward behaviors instead of the declarations ... Anyway, tks for showing me ur code, i'll take note of it, who know, i may need it next time :] Cheers == On Sun, Dec 28, 2008 at 3:29 AM, Dan Kubb (dkubb) <[email protected]> wrote: > > Hi NgTzeYang, > >> I'm quite sure that many of u probably experience frustration in >> writing specs for ur models' validations, its actually quite a >> repetitive process. I'm wondering if there already exists a DRYer >> approach to this, maybe something like the validation helpers >> inhttp://github.com/rsl/skinny_spec/tree/master/lib/lucky_sneaks/model_... >> ? >> >> Anyway, just want to make sure i'm not going to duplicate anyone's >> effort in writing these helpers :] > > I would love to see these, but I would probably prefer that any spec > helpers not use introspection to test the behavior of a Model or > Resource. It would be better to test the observable behavior because > some of the things that you'd need to introspect, for say, > relationships are private right now and will be changing within a > month or so. > > Even if that wasn't the case, I think specs should test the behavior > of the object not it's meta-data. So for example, if I want to test > that "User has many memberships", I would write: > > - User instance should respond to :memberships > - User instance should respond to :memberships= > - User#memberships should return an Enumberable of Membership > instances > - User#memberships= should accept an Enumerable of Membership > instances > - User#memberships= should set User#memberships > - User#save should persist Membership instances that are provided to > User#memberships= > > And so on. The rule I use when writing specs for dkubb/dm-core is > that for each method I test: > > 1) return values of methods > 2) state changes to the object, if any > 3) state changes to the arguments, if any > 4) exceptions thrown by the method > > The above behavior is testing the things you care about most. Treat > the methods as black boxes. Speccing with introspection is a short- > cut, and it also makes it harder to refactor the logic later. An > example of this is maybe down the road the memberships aren't retrieve > by a direct join between the User and Membership models. Maybe you > need to go through a few intermediaries to check permissions or > payment status. If you wrote the specs the way I recommend it won't > be a problem, but if you use introspection you'll likely end up having > to rewrite all the specs. IMHO it's always a red flag when your specs > need to change due to an internal refactoring of your methods. > > Dan > (dkubb) > > > -- http://ngty77.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
