Nose 2 compatibility

[magmax]

Nose is the most used test runner. It allows lots of things, so I think it doesn't worth it to write another new, with coverage, etc.

They are moving to nose2 (still under development), but it is quite easy to write a plugin for it. This will allow us to use pyspecs with coverage, other reporting systems (like xml, useful for automatic processes) without any work.

This issue may require some changes in the code, in order to split the repoting and execution in two different plugins or maybe add configuration options to allow it.

[magmax]

I will fix this.

[mdwhatcott]

@magmax - Go for it. I've added you as a contributor on this project so you can commit and push directly rather than opening pull requests.

[magmax]

Thank you.

I didn't wait for your approval. I was already having a look, and a lot of work should be done:

• runner is not a runner, but a test discover. I will have to rename it.
• reporter is not a reporter, but a reporter and a runner. I will have to split it.
• the runner should return one or more standard unittest.TestSuite, that contains unittest.TestCase.
• the reporter should take the unittest.TestSuite and unittest.TestCase and render them.
• the nose plugin will use the runner and (optionally) the reporter.

I think I will release each of these changes individually... But it may be hard.

Despite having permissions, I think these changes are quite heavy, and I will ask you for a code review.

[mdwhatcott]

When I started pyspecs I considered making it a nose plugin but wasn't willing to invest the time necessary to learn the API at the time. I'm interested to see what you come up with.

Maybe development could be done in a separate branch? That way, you can implement each change one-by-one, then when you're finished with everything just merge back into master.

[magmax]

Well.. a second long view reveled that I was wrong XD

But I identified my first challenge: the relationship between _report and _counter is some like a visitor pattern. This may be a problem. I'm thinking in transform it into a builder pattern, inverting the relationship. There are two reasons to do this:

• You can execute once and show results in several formats
• This is the way nosetests works.

This will be my starting point.

And do not worry... branches are a must!

[mdwhatcott]

Sounds good. Good luck.

[magmax]

Hi there!

It has been harder than expected... Much harder than expected.

I almost rewrote the whole thing. And I'm afraid I had to take some decision that may make it different from current approach.

I'm going to put it in this repository as a pull-request, but feel free to deny it. If you do, I will continue on my own and it will be ok.

Some differences:

• Your runner allows to execute unittest tests and pyspecs. Mine do not.
• That forced you to import some methods in your test files. In my approach, they are already imported.
• Your approach is executing tests in same environment; indeed, they share the environment with the runner. In my approach, they are executed isolately.
• You generated the report while executing tests. Now it executes tests and generates a report, but it has to be parsed again in order to be rendered.
• Now there is no global variable.

I saw another thing: This library can be splitted in two. One with the "_should" content and another with the rest. I think this can be a good improvement.

I'm going to send the pull request, but only to maintain the project joint. As I said, it looks like a different one.

I still have some ideas to improve the code, but the general behavior is finished. My next stop is the nose-2 plugin, as I promised.

Well... I hope you to like it ;)