[ckan-dev] RFC: use oktest for ckan

Wed Sep 19 11:27:49 UTC 2012

Added opinions below.

On Sep 19, 2012, at 11:11 , Toby Dacre <toby.okfn at gmail.com> wrote:

> On 18 September 2012 21:48, Dominik Moritz <domoritz at gmail.com> wrote:
> 
>> Hi CKAN devs,
>> 
>> I'm currently working on integration tests for CKAN. Before that I worked
>> on the datastore and wrote quite a few tests. Testing takes a lot of time
>> and the syntax and fixture injection is not simple. In my Summer of Code
>> Projekt and other project at university, I used Oktest and would like to
>> show you the advantages.
>> 
>> List of Features/ Advantages:
>> 
>> * Full backwards compatible, you don't have to use it.
>> * Easy to install and setup (pip install oktest, import, done)
>> * Works with the current testing environment
>> * Shorter syntax and easier to read syntax
>> * Better errors with diffs[1]
>> * Tests for expected errors
>> * Simple type checking and file path checking
>> * Test decorator for better naming of tests (I actually wrote better test
>> names after I started using oktest)
>> * MIT License
>> * The name Oktest sounds like Okfn. We could tell people its actually the
>> "open knowledge test" ;-)
>> 
>> If that sounds mouthwatering wait until you see the syntax. It's quite
>> nice [2]
>> You want to see some code. No problem. Here is a rest api wrapper test [3]
>> and a simple pylons app test [4] that I've written with Oktest.
>> 
>> Cheers,
>> Dominik
>> 
>> [1]
>> AssertionError: 'foo' == 'bar' : failed.
>> --- expected
>> +++ actual
>> @@ -1 +1 @@
>> -bar
>> +foo
>> 
>> instead of:
>> 
>> AssertionError
>> 
> 
> Hmm,
> 
> interesting personally I dont like the syntax it looks a bit to
> un-pythonic  is ok a function or a keyword?

I agree, we could simply add ok to the test case class and then write self.ok instead of ok. Then we wouldn't even have to import it every time and have the same behaviour as assertEqual.

> it looks like it's pretending
> to be a keyword when it's a function also redefining _(...) repeatedly for
> the tests seems evil

Definitely true. However, you don't have to use the test decorator if you think that it is too evil. Or use the test decorator to give longer descriptions.

> 
> the output looks like it could be nicer what is it like with differences in
> dicts as that is the main thing that is currently problematic although we
> could create a nice dict_diff helper for that.

Improving/ Extending the library is always an option. I think the current oktest could be a good starting point, though. I ran into the diff problem multiple times and it took me significantly longer to find errors when I had to do the manual diff.

> generally the tests do need a massive overhaul in my opinion so options are
> good
> 
> I don't have any major objections just observations
> 
> cheers
> 
>> 
>> [2] http://www.kuwata-lab.com/oktest/oktest-py_users-guide.html
>> [3] https://github.com/domoritz/popit-python/blob/master/test.py
>> [4] https://github.com/domoritz/Professors/blob/master/profs/tests.py
>> _______________________________________________
>> 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