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. 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 - a developer should be able to generate a Model and its examples - a developer should be able to generate a Controller and its examples - a developer should be able to generate a view and its examples - a developer should be able to use merb built in example helpers (mock a request..) - a merb plugin developer should be able to test his/her plugin 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? ;) -Matt On 7/27/07, Ezra Zygmuntowicz <ez at engineyard.com> wrote:> > On Jul 27, 2007, at 3:35 PM, Matt Aimonetti wrote: > > > Ezra, > > > > I''m sure you are really busy and can''t spend too much working on > > Merb. Please let us know how we can help you. > > If the plugin architecture is stable, would you be interested in > > some of us porting few rails plugins over (such as attachment_fu) ? > > Or is there anything else we could do during our free hacking time? > > > > Thanks, > > > > -Matt > > Hey Matt- > > I have been super busy that last few weeks. But I am giving a talk > on merb at the ruby hoedown in a few weeks and really want to push > out a 0.4 release by then. > > The things outstanding for 0.4 release are: > > * test harness in new generated merb apps with helpers for testing > merb without starting a server. > * more docs > * work on mrblog so I can launch it on merbivore.com > * always nice to get more specs for core framework. > * better app initialization code > * pin down plugin arch > > I''m hoping to knock out some of these things this weekend. But if > anyone wants to help work on these things I welcome it. > > ALso look at the trac for [Help Wanted] tickets, there are a few in > place looking for someone to send patches ;) > > > Cheers- > -- Ezra Zygmuntowicz > -- Founder & Ruby Hacker > -- ez at engineyard.com > -- Engine Yard, Serious Rails Hosting > -- (866) 518-YARD (9273) > > >-- m|a agile development -------- (760) 536-4425 Skype: mattdesktop GTalk: mattaimonetti at gmail.com blog: http://railsontherun.com
Matt- Chris and I did some work today on refactoring merb to be more testable. We will be doing some more work tomorrow. You should hop on irc.freenode.net in #merb and discuss stuff with us in there. Its failry active for bouncing around ideas. If you wanted to work on model,controller and view generators I think that would be great. Hopefully we will nail down the test interfaces tomorrow and we can go from there. Cheers- -Ezra On Jul 28, 2007, at 7:22 PM, 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. > > 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 > > - a developer should be able to generate a Model and its examples > - a developer should be able to generate a Controller and its examples > - a developer should be able to generate a view and its examples > - a developer should be able to use merb built in example helpers > (mock a request..) > > - a merb plugin developer should be able to test his/her plugin > > 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? ;) > > -Matt > > > On 7/27/07, Ezra Zygmuntowicz <ez at engineyard.com> wrote: >> >> On Jul 27, 2007, at 3:35 PM, Matt Aimonetti wrote: >> >>> Ezra, >>> >>> I''m sure you are really busy and can''t spend too much working on >>> Merb. Please let us know how we can help you. >>> If the plugin architecture is stable, would you be interested in >>> some of us porting few rails plugins over (such as attachment_fu) ? >>> Or is there anything else we could do during our free hacking time? >>> >>> Thanks, >>> >>> -Matt >> >> Hey Matt- >> >> I have been super busy that last few weeks. But I am >> giving a talk >> on merb at the ruby hoedown in a few weeks and really want to push >> out a 0.4 release by then. >> >> The things outstanding for 0.4 release are: >> >> * test harness in new generated merb apps with helpers for testing >> merb without starting a server. >> * more docs >> * work on mrblog so I can launch it on merbivore.com >> * always nice to get more specs for core framework. >> * better app initialization code >> * pin down plugin arch >> >> I''m hoping to knock out some of these things this weekend. >> But if >> anyone wants to help work on these things I welcome it. >> >> ALso look at the trac for [Help Wanted] tickets, there are >> a few in >> place looking for someone to send patches ;) >> >> >> Cheers- >> -- Ezra Zygmuntowicz >> -- Founder & Ruby Hacker >> -- ez at engineyard.com >> -- Engine Yard, Serious Rails Hosting >> -- (866) 518-YARD (9273) >> >> >> > > > > -- > m|a agile development > -------- > (760) 536-4425 > Skype: mattdesktop > GTalk: mattaimonetti at gmail.com > blog: http://railsontherun.com > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel-- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez at engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)
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 examplesYes, 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 examplesYep, 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)
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070729/1fca8975/attachment.html
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 <chris at octopod.info> 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 > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel > >
On 30 Jul 2007, at 07:26, Matt Aimonetti wrote:> 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. >I like the idea of having a separate script to generate AR/rspec models, which merb -g might call by default. We can then have other scripts for AR/test-spec, ruby-sequel/rspec etc. if people want them enough to write them. They could also be installed as plugins. So you''d be able to do something like: merb -g model -t test-spec -o ruby-sequel name:string author:string but so we don''t have to have merb -g know all this stuff before we can test / use it, you should be able to do something like: merb_ar _rspec -g model ... etc.> 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? >Having it autodetect which ORM / BDD library would be cool, but not as important as being able to generate the stuff first.> 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 :) ) > >You want to checkout merb trunk somewhere locally on your machine using svn. Where $ is your terminal prompt $ svn co http://svn.devjavu.com/merb/trunk merb $ cd merb $ rake specs This makes sure everything is working on your machine. For the merb_ar script I mentioned above, I''d break it down into something like the following: bin/merb_ar lib/merb/merb_activerecord_generator/merb_activerecord.rb lib/merb/merb_activerecord_generator/templates/model.erb lib/merb/merb_activerecord_generator/templates/rspec.erb lib/merb/merb_activerecord_generator/templates/test-spec.erb specs/merb/merb_active_record_generator/merb_activerecord_spec.rb specs/merb/merb_active_record_generator/fixtures/model.rb specs/merb/merb_active_record_generator/fixtures/rspec.rb specs/merb/merb_active_record_generator/fixtures/test-spec.rb bin/merb_ar is a simple script which processes command line options and calls the appropriate methods in the merb_activerecord.rb lib. The specs would make sure that calling the methods on the lib generated the correct output by comparing with the expected output in the fixtures dir. You''d possibly need more than the fixtures I''ve listed here of course :) I''d start with the specs and a simple model fixture, make the lib create the fixture, then move on to the creating the rspec file the same way. You could leave off test-spec for now if you don''t know it and someone else can add that. When the lib is producing what it should then you can write the bin/merb_ar script to call it. svn add all the files you''ve created as part of this, then run svn diff > merb_ar_generator_1.diff and upload that to a new ticket on Trac> -MattHTH, Cheers, Chris
Thanks for the help. My ''newbie question'' was more related to the fact when I call merb, the request goes through the gem and not my local repo, I was wondering what was the official procedure to avoid that behaviour without breaking my other merb projects. I guess I can just call my generator directly. About the suggested structure, I was thinking more about creating a generic generator class and having many sub classes so we keep our code consistent and we make things easier for developers wanting to write new generators. I''ll try to work on that asap -Matt On 7/30/07, Chris McGrath <chris at octopod.info> wrote:> > On 30 Jul 2007, at 07:26, Matt Aimonetti wrote: > > > 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. > > > > I like the idea of having a separate script to generate AR/rspec > models, which merb -g might call by default. We can then have other > scripts for AR/test-spec, ruby-sequel/rspec etc. if people want them > enough to write them. They could also be installed as plugins. > > So you''d be able to do something like: > > merb -g model -t test-spec -o ruby-sequel name:string author:string > > but so we don''t have to have merb -g know all this stuff before we > can test / use it, you should be able to do something like: > > merb_ar _rspec -g model ... > > etc. > > > 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? > > > > Having it autodetect which ORM / BDD library would be cool, but not > as important as being able to generate the stuff first. > > > > 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 :) ) > > > > > > You want to checkout merb trunk somewhere locally on your machine > using svn. > > Where $ is your terminal prompt > > $ svn co http://svn.devjavu.com/merb/trunk merb > $ cd merb > $ rake specs > > This makes sure everything is working on your machine. > > For the merb_ar script I mentioned above, I''d break it down into > something like the following: > > bin/merb_ar > lib/merb/merb_activerecord_generator/merb_activerecord.rb > lib/merb/merb_activerecord_generator/templates/model.erb > lib/merb/merb_activerecord_generator/templates/rspec.erb > lib/merb/merb_activerecord_generator/templates/test-spec.erb > specs/merb/merb_active_record_generator/merb_activerecord_spec.rb > specs/merb/merb_active_record_generator/fixtures/model.rb > specs/merb/merb_active_record_generator/fixtures/rspec.rb > specs/merb/merb_active_record_generator/fixtures/test-spec.rb > > bin/merb_ar is a simple script which processes command line options > and calls the appropriate methods in the merb_activerecord.rb lib. > The specs would make sure that calling the methods on the lib > generated the correct output by comparing with the expected output in > the fixtures dir. You''d possibly need more than the fixtures I''ve > listed here of course :) > > I''d start with the specs and a simple model fixture, make the lib > create the fixture, then move on to the creating the rspec file the > same way. You could leave off test-spec for now if you don''t know it > and someone else can add that. When the lib is producing what it > should then you can write the bin/merb_ar script to call it. > > svn add all the files you''ve created as part of this, then run svn > diff > merb_ar_generator_1.diff and upload that to a new ticket on Trac > > > -Matt > > HTH, Cheers, > > Chris > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070730/ba1d43f9/attachment.html
On 30 Jul 2007, at 11:07, Matt Aimonetti wrote:> Thanks for the help. My ''newbie question'' was more related to the > fact when I call merb, the request goes through the gem and not my > local repo, I was wondering what was the official procedure to > avoid that behaviour without breaking my other merb projects. I > guess I can just call my generator directly.My apologies, I misread and thought your were a total newbie.> > About the suggested structure, I was thinking more about creating a > generic generator class and having many sub classes so we keep our > code consistent and we make things easier for developers wanting to > write new generators. > > I''ll try to work on that asap >Cool, what services would this generic class provide?> > -Matt >Cheers, Chris