On 29 Jul 2007, at 03:22, Matt Aimonetti wrote: > Ezra, > > * test harness in new generated merb apps with helpers for testing > merb without starting a server. > * pin down plugin arch > > Seems to me that these two tasks go together unless you want to have > rspec built in Merb. >
I'd prefer app testing to be testing framework agnostic, with merb providing as much infrastructure as it can, but no more for xxx_on_merb plugins to use. I'd hope that these plugins might end up living in the merb repo too. I'd also like there to be no explicit dependencies on ActiveRecord in a merb app unless you want them there. I've some app ideas for which AR is overkill and something like ruby-sequel would be a better fit. So I think generating a new merb app should have at least two steps: 1. Generate the merb app & app level tests 2. Generate the DB layer access code & db layer tests The merb repo could contain the basic app & AR stuff as that's there already and other DB layers could either be done as plugins or added to the main repo in time. I think we'd need a separate app generator from merb -g, though that could stay and be re-wired to create a Merb/AR app via the new generator. > Regarding the test harness, my understanding is that: > > - a developer should be able to easily write specs against a merb > application. > - a developer should not need to start a merb server to test his/ > her app > Agreed > - a developer should be able to generate a Model and its examples Yes, but this shouldn't be hardwired to an AR model > - a developer should be able to generate a Controller and its examples > - a developer should be able to generate a view and its examples Yep, I'd include a Mailer here too > - a developer should be able to use merb built in example helpers > (mock a request..) > Yep, as Ezra mentioned in his reply we did some work to help with this yesterday. Controller instantiation and env/param parsing are now separate, so a test can create a controller, mock it, then fire off the request. We moved the Merb::MockRequest into the framework yesterday, so this can be removed from the xxx_on_merb plugins. Let me know if this causes any problems (it shouldn't, it's essentially the same code anywhere I look). I'm wondering whether the <verb> test methods, get, post etc. can be part of the framework too, or whether rspec and test/spec will do things differently enough to require specific versions. I don't know a lot about rspec and nothing about it's internals so I'm not sure here. > - a merb plugin developer should be able to test his/her plugin > Sounds good > Is that correct? Do you mind if we create a list of user stories, > assign priorities (critical, essential, nonessential) and try to get > things done? Or do you prefer to just work on it and we'll see later > on? ;) > 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. > -Matt > Cheers, Chris (octopod in #merb) _______________________________________________ Merb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/merb-devel
