deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Lutterkort <lut...@redhat.com>
Subject Re: [PATCH core 01/32] Core: Added sinatra-rabbit gem to gemspec
Date Fri, 11 May 2012 18:50:50 GMT
Hi Michal,

On Fri, 2012-05-11 at 12:56 +0200, Michal Fojtik wrote:
> On 05/10/12, David Lutterkort wrote:
> > I get some errors on the modular branch; they need to be addressed
> > before we can commit this patch series.
> > 
> > (1) Running 'rake test' gives me
> >         
> >         /homes/lutter/.gem/ruby/1.8/gems/rake-0.9.2.2/lib/rake/ext/module.rb:36:in
`const_missing': uninitialized constant Deltacloud::Helpers::Application::API_ROOT_URL (NameError)
> 
> Right, this task will trigger the Test::Unit tests we have. I can fix them
> to use Deltacloud::API.

Yes, either that or get rid of them entirely.

> > (5) Running 'rake features' in tests/ gives me 
> > 
> >         Error creating formatter: html (Errno::ENOENT)
> >         /homes/lutter/.gem/ruby/1.8/gems/cucumber-1.1.4/bin/../lib/cucumber/formatter/io.rb:7:in
`initialize'
> >
> 
> The Cucumber tests should be launched from the 'server' directory:
> 
> firefly ~/code/core/server $ rake cucumber:mock:test
> ...........
> 41 scenarios (41 passed)
> 292 steps (292 passed)
> 0m10.489s
> 
> Note that I just fixed the Mock Cucumber suite, still working on EC2 one,
> but I assume since there were no changes to EC2 driver they will just work.

The mock cucumber tests now work for me too, on your new branch. Longer
term, we need to have a good look at how these are set up right now -
ideally tests/ would have its own Rakefile that can be pointed at
arbitrary drivers.

> > To commit these, we need to get to a state where all the tests pass;
> > that's the biggest blocker right now.
> 
> Agree, I'll do that as high priority. Btw. I suggest to replace the 'mock'
> unit tests we have in server/tests/drivers/mock with the 'api' tests. They
> are doing the same thing now and the 'api' tests are more up-to-date.
> What do you think?

If they are just duplication, then yes, we should get rid of them.

> > Also, to make the patch series a little less daunting, you might
> > consider splitting patches that aren't directly related to modularizing
> > DC out (e.g., 14/32 or 30-32/32) This will make it much easier to review
> > them and get them committed separately.
> 
> Yeah, should I do that and send a new patch bomb? I can do it when rebasing
> against master when pushing but that will not be anyhow usefull for review
> ;-)

I mostly meant that to speed things up: send those unrelated patches
separately while you're still working on the modular stuff; that way,
there's less churn when the modular patches go in. And it's easier to
review a few patch series with a handful of patches, rather than 40+
patches ;)

David


Mime
View raw message