[TIP] Multiplatform testing with nose

Herman Sheremetyev herman at swebpage.com
Mon Feb 14 16:00:38 PST 2011


You could stick a fake win32api library into your sys.path or maybe
wrap importing it in a try/except ImportError. Without knowing more
details about the setup it's hard to say just how ugly a hack either
of those will be..

-Herman

On Tue, Feb 15, 2011 at 2:14 AM, Yoni Tsafir <yonix85 at gmail.com> wrote:
> OK,
> So I know a few weeks ago there was a multiplatform related question, but
> mine is a bit different.
> I'm working on a project that has platform specific code in its working
> tree.
> No matter what are the reasons, but currently in the same project tree there
> is platform specific code for several platforms side by side, and it
> currently can't be separated to different trees.
> Now, about the unit-tests: pretty simple, each unit-test that can run only
> on a specific platform, raises a SkipTest in case you try running it on a
> different one (similar to what was suggested here a few weeks back).
> Also, notice that some unit-tests may be in a platform specific package, but
> can actually run on all packages (because of mocks).
> Great.
> Now,
> I want to be able to run all tests in my project with nose by running
> nosetests recursively on the root directory.
> What's the problem with that?
> The problem is that some of my __init__.py of the windows specific code,
> imports win32api, which exists only in windows.
> Now from what I could understand, when nose is given a directory rather than
> a list of tests, it tries finding tests in all the packages recursively, and
> in the process it actually imports all __init__.py of modules, including the
> ones that are trying to import other platform specific stuff.
> This is a problem, because there are no tests to skip here, and I end up
> getting an Error in my test-suite that isn't actually connected to a test.
> Now, the way I see handling this right now, is avoiding importing stuff in
> __init__.py of packages, and either insert it into the function definitions,
> or to other .py files that are imported only explicitly and not from other
> __init__.py
> I must say I'm not really crazy about this solution.
> Other solutions I thought of is to separate my code to different working
> trees and run on them (which is a big problem currently),
> Or using something like --exclude=windows in nose, but this is bad because
> under windows there are unit tests that can be ran on any platform (because
> of mocks).
> I was wondering if any of you can think of a better way to solve this
> annoying problem.
> Thanks!
> Yoni.
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
>



More information about the testing-in-python mailing list