Do they belong to you? Claim these comments.
DHH
Is this you? Claim Profile »
5 months ago
in Francis Hwang: On fixtures and first-time testers on Francis Hwang
You seem to be missing the point of fixtures. If all you're doing is setting up a single fixture, with a single value, for a single test case, well, duh, of course they're not worth it. If, on the other hand, you're setting up an entire slate of fixtures that have relations, like creating an entire, valid account in Basecamp with all the child objects that go with that, it's absolutely worth it in my opinion.
I still use fixtures for current and new projects. I'm aware that there are other ways to get test data, yet I still choose to use fixtures. So of course they're not a lie. How can we be lying about things that we actually use?
You don't like fixtures. Good for you.
I still use fixtures for current and new projects. I'm aware that there are other ways to get test data, yet I still choose to use fixtures. So of course they're not a lie. How can we be lying about things that we actually use?
You don't like fixtures. Good for you.
- 2 points
- Jump to »
1 year ago
in Twitter off the Rails? And, so what? on philcrissman.com
We certainly don't run a special version of Rails at 37signals. That wouldn't make any sense. The whole point of open-sourcing Rails was to participate in the shared commons. Running our own fork isn't very compatible or sensible for that.
2 years ago
in CRUD, REST, DDD, Rails - these are a few of my favorite things on Thinking inside a bigger box
Thanks for the kind words. DDD is indeed one of my favorite programming books. Lots of inspiration from Mr. Evans.
It sounds like in fixtures you have a tool that works for you. But it's been my experience and the experience of most of the people I know that fixtures have not worked for them, especially in cases where setting up an entire set of fixtures to describe a user with accounts that are shared with other people, etc. Could be we're all using fixtures wrong. Could also be that testing is complex, and different approaches will work best for different people.
From the outsider's point of view--that is, from the point of view of someone who didn't design Rails fixtures, never looked at the implementation code--I don't understand why putting my data in different YAML files, separated out not by context but by the underlying database table, should simplify things for me. Managing different contexts is very hard in Rails fixtures, or at least it seems to require a level of discipline that I'm incapable of. I'd suggest that the proliferation of alternatives to Rails fixtures would indicate that a lot of other people feel the same way.
And I don't understand why YAML is simpler here than Ruby, why they should be in separate directories, files, etc. The whole thing sort of feels like a Test Data Specification Layer or something, like out was out of Hibernate.