On Thu, Feb 5, 2009 at 8:17 AM, Ben Mabey <b...@benmabey.com> wrote: > Any thoughts? Are Ruby's Object Mothers really Test Data Builders?
Here's what I think is important: * Make fixture setup explicit by inlining it on a per example/group basis * Keep fixture setup short by hiding the object graph construction * Allow concise parameterization of the fixture objects * Focus 100% on structure (0% on behavior) in methods/objects to build your data. This minimizes accidental coupling between examples. The name you give a tool that fulfills these goals is never going to be central to valuable conversation, so I think it's of minimal importance. The rest of this email is somewhat ranty, and originally appeared before what you just read above...but I figured I'd save some people time and separate it out so you can skip over it if you want :) ----------------- I don't know what the distinction is, and to tell you the truth I don't think it matters. There's miniscule evidence to suggest that these are fundamentally different (quotes from http://martinfowler.com/bliki/ObjectMother.html) 1) These canned objects often aren't just right for a particular test, but often can be made right with some additional setup Okay, but he doesn't say HOW that additional setup comes about. Do you get an object from the mother and then call some setters on it? Do you parameterize calls to the OM? You can do either of those with all of the fixture replacement tools that I know of. 2) The canned objects that the Object Mother produces become familiar to the team, often invading even discussions with the users I guess this is where the "mother" thing comes from...mothers have children, children are unique like snowflakes and have names and personalities and yadda yadda. Personally I think that cast of characters blows as a testing pattern. It always leads to inadvertent coupling between tests and muddles intent. What makes more sense to you as a developer, "that customer object in this test is Joe Bob" or "that customer object is a customer with an account balance of $10k". If you want to get into pattern specifics, the question really is "am I using factory methods or a builder," to which the answer is "factory methods" for every tool I've seen. Well, not quite. You can imagine that new_user :name => "Pat", :email => "pat.mad...@gmail.com" is a different form of UserBuilder.new.with_name("Pat").with_email("pat.mad...@gmail.com").build see... def new_user(options={}) options.inject(UserBuilder.new) {|b,pair| b.send("with_#{pair.first}", pair.last) }.build end A beautiful outcome of using Ruby is that many traditional patterns fade in importance. If you want to be very technical, these tools are neither Object Mothers nor Test Data Builders right out of the box (assuming that TDB uses the actual Builder pattern). Rather, they're just factories/factory methods, dynamically generated by reflecting on given classes. The real question is which one communicates better. I'd say TDB does because it says exactly what it is - it builds data for your tests. You could use it in a conversation and the other party would not need to know that it's a pattern of any kind. But...Rails has fucked up the testing lexicon for tons of Ruby programmers. There's already a lot of fuzziness between unit/functional/integration in the testing community as a whole, and as David pointed out it's made worse in the Rails world by how *wrong* Rails gets the names. So when I talk to people I strictly use "developer tests" and "acceptance tests." I find that a much more valuable distinction to make. And for developer tests, it makes a lot more sense to discuss them in terms of value and tradeoffs than it is to try to put them in certain buckets. How does that fit into this discussion? Well, to me, a fixture is a set of objects in known states that comprise the context in which a test runs. To lots of Rails developers, fixtures are yaml files that define records in the test db. Instant communication problem, because it implies the question is Fixjour vs Foxy fixtures, which is absolutely not the case. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
