How to run the tests in a convenient way?

[lesteve]

Sorry if i haved missed it somewhere in the documentation, but how do you run the dill tests in a convenient way? I am used to projects where nosetests is used but trying with dill yields plenty of errors.

Here is what I did:

git clone https://github.com/uqfoundation/dill
cd dill
python setup.py build
nosetests

While I am at it, nosetests --with-doctest shows some failing doctests.

Would you be interested in contributions that make the tests more nosetests friendly?

I saw that there were some test files in dill/tests that you could run directly with python but it is unclear whether a test failure is expected or not. For example, here is the output I get with master for tests/test_objects.py:

❯ python tests/test_objects.py
fails: ListIteratorType <type 'listiterator'>
fails: TupleIteratorType <type 'tupleiterator'>
fails: XRangeIteratorType <type 'rangeiterator'>
fails: CycleType <type 'itertools.cycle'>
fails: PermutationsType <type 'itertools.permutations'>
fails: CombinationsType <type 'itertools.combinations'>
fails: RepeatType <type 'itertools.repeat'>
fails: CompressType <type 'itertools.compress'>

[mmckerns]

See #138.

The tests in dill/tests should not produce any output -- with the exception of dill/tests/test)objects.py. dill/tests/test_objects.py prints a collection of objects that fail to serialize with dill. The plan is to have it set up for nose (or similar) to conveniently run all tests.

[lesteve]

See #138.

I see, I somehow missed this issue completely.

I would be keen on working on making the tests runnable with nosetests if you are interested.

[mmckerns]

@lesteve: It's on my to do list… so if you want to do it, go for it.

[disconnect3d]

@lesteve Is there any progress on it?

[lesteve]

Not any significant progress I am afraid, although I haven't given up on it completely. Last time I tried I got tripped up by the fact that some tests in test_classdef.py pass fine when run with python but not with nosetests. My understanding was that dill seems to behave differently when __name__ == __main__, which isn't the case when the tests are run with nosetests. I never got to the bottom of this.

[lesteve]

I decided to tackle this one test file at a time. The idea is to keep the current behavior of being able to do for i in tests/*.py; do python $i; done while I am making the tests py.test friendly.

The main idea is to have a structure like this for each test file:

  def test1():
      ...

  def test2():
     ...

  def main():
      test1()
      test2()

  if __name__ == '__main__':
      main()

This way you can still do python the_test_file.py and py.test the_test_file.py during the process. My hope is that eventually only py.test will be used thanks to its convenience.

Note: it seems like py.test is better than nosetests since the latter is not maintained anymore. Probably a bit of an over-simplification since there is something like nosetests2 but I'll go with that for now.

[matsjoyce]

Yup, I use py.test too. Lots of colors and stats and things. @mmckerns If you do go along with using py.test, they've got a coverage plugin which may be useful.

[mmckerns]

@lesteve: Cool, I will check this out, and either pull or comment afterward.