Fix tox errors for py2.7

[livenson]

Replaced set comprehension syntax with py2.6+ compatible syntax, cleanup of pylint issues.

[review-ninja]

[coveralls]

Changes Unknown when pulling 5c8e30b on livenson:develop into * on pycontribs:develop*.

[livenson]

Ok, the tests are working locally, but CI seems to be running against a remote server, which seems to be causing issues with pseudo-mockup objects in test setup. The easiest would be to use the same env on travis as locally, but I didn't quite chew through the variables/setup idea. @ssbarnea , could you please help out a bit?

[ssbarnea]

The only thing that is different between running locally and running on Travis is that it will try to use different project names, which are generated based on current username. This is needed in order to prevent affecting the same projects while running tests in parallel.

Also Travis is running tests in parallel with different Python versions, and sometimes this is causing problems. It's tricky to make the tests pass on these conditions but not impossible. I will have a look.

[lechat]

I think that it is worth splitting tests into multiple files. Of course it is possible to call specific tests, if needed, but if each test will be in separate file, it will be easier to add new tests.

Basically the same way we've done it in jenkinsapi.

[livenson]

I guess if you do that in a PR, it will be accepted 😉

[lechat]

I sure am can do that, but decided to ask if there are any objections. ;) There must be a reason why all tests are in the same file and I find it impolite to make drastic changes w/o asking.

[ssbarnea]

That's not so easy, I don't want to see 100+ files, one for each test but splitting them in several files one for each class should be something good.

Keep in mind that execution order matters for the tests that are inside the same class, or at least it still matters at this moment.

Running test-classes in parallel should work well but not each test method. This is mostly caused by the really fat tear-up and tear-down code, which is impossible to avoid.

In fact we have integration tests implementing using py.test, not real unittests.

[livenson]

I suggest using mock library for that. Currently that "fat tear-up" is extremely hard to understand/debug.