Merb test harness

[Chris McGrath]

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)