Sounds good to me. I'm willing to try working on the generator. This is what I had in mind:
$ merb -g app bookshop $ merb -g model Book name:string author:string published_at:date After a collision check, merb would automatically generate: - an Active Record Model - a migration file - a fixture file - a rspec example - a unit test I would personally stick to only rspec but I'm fine with adding a unit test template and generate a test and an example per model. Regarding using ruby-sequel instead of Active Record, I think that's a good idea. I would probably have to modify the actual generator and we could add an option for the ORM you want to use. When the developer decides to generate a model, the generator could check on the ORM used and use the proper template. What do you think? Also, I have few newbie questions. How's your development/testing environment like? I guess you don't package/install the gem every time, do you? Do you just work on the files directly in your gems folder? I'm sorry, I never worked on a gem and I couldn't find the rubygems developer guide. (and I prefer to sound ignorant than to waste my time not doing things properly :) ) -Matt On 7/29/07, Chris McGrath <[EMAIL PROTECTED]> wrote: > > > On 29 Jul 2007, at 12:54, Chris McGrath wrote: > > > Stories are good, code is better :) I think having some high level > > statements about what merb will and will not do/provide for plugins > > and testing frameworks agreed would be a good start and stories would > > be one way of getting to them. > > Replying to my own mail :) > I've had a look at the rspec_on_rails plugin in mrblog (is this the right > place?) and test_spec_on_rails from it's repo. My initial impressions are > there are several things merb should do for a test harness: > > 1. Load the test database > 2. Load the app files > 3. Provide a FakeRequest > 4. Provide MultiPart functionality > > This seems to be the common stuff between the two plugins at the moment. > > 1 & 2 are concerned with merb initialization and i'm unsure what the best > way of handling this is. > > re 3 & 4. I called the FakeRequest MockRequest yesterday, this is a bad name > as it's not a mock :). I'd like to add in a Merb::Test namespace and have > Merb::Test::FakeRequest and Merb::Test::MultiPart for the plugins to use. > > Chris > _______________________________________________ > Merb-devel mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/merb-devel > > _______________________________________________ Merb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/merb-devel
