[ckan-dev] test failures

Fri Feb 4 10:51:07 UTC 2011

On 4 February 2011 10:37, James Gardner <james at 3aims.com> wrote:

>  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
>

But that's the nose config, not a pylons config.

test.ini is referred to in the tests/__init__.py. I guess you're thinking of
'nose --with-pylons=buildbot.ini', but then you have to replicate all the
rest of the test.ini options (apart from the sqlalchemy one) in there. You
also have to work out how to tell the other pylons instances that tests
start independently to use this other config file. So I don't see it as
simple as you suggested.

> 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> wrote:
>
>>
>>
>>  On Thu, Feb 3, 2011 at 9:50 PM, David Read <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
>>> 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
>>
>>
>
> _______________________________________________
> ckan-dev mailing listckan-dev at lists.okfn.orghttp://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/5528b0ee/attachment-0001.html>