#204 TAURUS4: error running unittests with taurus.external.pint

[marc]

TAURUS4: error running unittests with taurus.external.pint

When pint is not installed in the system, the taurus local pint is used. But it fails when trying to import pint submodules (ex: pint.compat).

ERROR: external.pint.pint_local.testsuite.test_contexts (unittest.loader.ModuleImportFailure)

ImportError: Failed to import test module: external.pint.pint_local.testsuite.test_contexts
Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/loader.py", line 252, in _find_tests
    module = self._get_module_from_name(name)
  File "/usr/lib64/python2.7/unittest/loader.py", line 230, in _get_module_from_name
    __import__(name)
  File "/siciliarep/tmp/mrosanes/CTGENSOFT/taurus/lib/taurus/external/pint/pint_local/testsuite/__init__.py", line 9, in <module>
    from pint.compat import ndarray, unittest, np
ImportError: No module named pint.compat
</module>

---

To be explored: A possible solution would be to export the taurus local pint as pint, instead of taurus.external.pint.local_pint.

[marc]

These tests are not Taurus tests; they are Pint tests. Because of that these errors are not relevant for Taurus. But it should be good to do a 'Skip' in some way of the tests of the Pint directory (without modifying the code of PINT if possible).

[Carlos Pascual]

I would consider removing the pint_local/testsuite dir a valid solution.

[Carlos Falcon]

I'm agree. An other solution to prevent these possible errors will be limit the autodiscover of our test suite to core and qt directories only.

I attached a piece of code:

    main_path = os.path.dirname(taurus.file)

    core_path = os.path.join(main_path, 'core')

    qt_path = os.path.join(main_path, 'qt')

    suite = loader.discover(qt_path, top_level_dir=main_path)

    suite.addTests(loader.discover(core_path, top_level_dir=main_path))

[Carlos Pascual]

That solution is also ok for me. Can you please submit a patch?
On a closer look, I realize that this solution is not so good because the external module may (and in fact does) include interesting tests (e.g. test_qt.py)

So I rather go into eliminating pint_local/test_suite for now.
We could consider a more fine-grained Taurus testsuite as a separate feature request, though.

[Carlos Pascual]

fixed with commit [#c9ab9b] in taurus4-preview

[Carlos Falcon]

Who is the "owner" of these tests? taurus? If is taurus, the test should be in somewhere of taurus/qt. If not, you are testing with the taurus testsuite an external library, that I don't know if it is the best option. If we considered these test interesting for us we can copy them in our test.
In my opinion, the pint tests can give information about the behaviour of the library in you system (with the proper export these tests work), and should have the same value than the qt test for an user, in order to decide if the libraries work.

[Carlos Pascual]

The comparison with test_qt.py is not good because test_qt.py does not "test if the [PyQt] library work" but instead it tests our own code for providing an abstraction layer for compatibility with different Qt versions. The pint tests, on the other hand, just test the pint library (and it is the responsibility of the pint maintainer to run them). We should assume that our dependencies work (for example, we do not run the PyQt unit tests).