[ckan-dev] test failures

[James Gardner]

What we actually agreed was that David would add a buildbot.ini file *in 
addition* to the test.ini file. Then if anyone wanted to run the tests 
exactly as buildbot does (ie with postgres) they could run:

     nosetests ckan/tests/ --config=builbot.ini

Unless there is a good reason not to do this, let's just do that as 
agreed? I can't see the problem.

James



On 04/02/11 09:04, David Read wrote:
>
>
> On 3 February 2011 22:35, David Raznick <kindly at gmail.com 
> <mailto:kindly at gmail.com>> wrote:
>
>
>
>     On Thu, Feb 3, 2011 at 9:50 PM, David Read <david.read at okfn.org
>     <mailto:david.read at okfn.org>> wrote:
>
>         Hi all,
>
>         I've changed buildbot to run ckan tests twice now: firstly
>         with sqlite and then again with postgres in the same buildbot
>         script (I should split it into two tasks, but that is for
>         another day). I've fixed a few problems with the tests under
>         sqlite and they pass now, but there are still problems with
>         tests in postgres.
>
>         Seb changed lots of 'rebuild_db' statements to 'clean_db',
>         which then requires 'init_db' at the start of the next test.
>         So there are now 'init_db' statements at the start of a great
>         many tests. Was there any reason for this?
>
>
>     This may not be necessary any more with the fix we did the other
>     day on migrate.  However, the in memory sqlite database gets lost
>     mysteriously sometimes and its hard to figure out where.  That is
>     why I thought the init_dbs were there.
>
>
> These problems are with postgres in this case, and there is no mystery 
> about losing the d.b. - we call clean_db!
>
> Note to Seb: Things were probably working in the past because the 
> 'faster_db_hacks' config option wasn't being read properly, which 
> David and I fixed last Friday, so the full init_db was happening even 
> with postgres, whereas it's not now. Also the init_db parameter 
> 'conditional' (BTW what a terrible name for a parameter...!) is not 
> being used. I think basically this all needs a bit of a review / tidy 
> up to get it to make sense and work too.
>
>         It seems a right faff to remember this - is there no better
>         way? Indeed I believe the current test failures are caused by
>         a test not having a init_db.
>
>         Note for everyone: Seb, James and I have agreed to set in
>         test.ini to use sqlite.
>
>
>     I disagree to this.  You should specify what database you want in
>     your own development.ini.  The template development.ini could have
>     sqlite as the default instead.  This is the only sane way to do it
>     in my opinion.
>
>
> Yes this might be better. Anyone else?
>
>         We think it is a good idea to default tests to being run
>         quickly. However, I can't see a good way to then run tests
>         under postgres - if you comment out the sqlite in test.ini (as
>         the buildbot currently does), 9/10 times you end up checking
>         it in by mistake. Maybe someone has a better idea, since
>         passing parameters to nose is a no no.
>
>
>     Why is this a no no?
>
>
> From what I read, nose doesn't believe in passing parameters onto 
> tests - they should be stateless. You can fudge it by hacking argv, 
> but then you lose flexibility of the many useful nose command-line params.
>
> Dave
>
>
>         David
>
>         _______________________________________________
>         ckan-dev mailing list
>         ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>         http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
>
>     _______________________________________________
>     ckan-dev mailing list
>     ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>     http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110204/513b6269/attachment-0001.html>