-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide test runner #83
Comments
I suggest using nose |
To illustrate nose usage, I created a testrunner-with-buildout branch. It introduces a sample buildout configuration to
Full recipe to configure environment, including getting the source:
Then run nose and pylint:
Notice that this buildout configuration is not intended to be cross-platform (it includes pyinotify). It may be adapted to fit your needs. |
A note about my last comment: my intention is not to force you to use buildout. It is to show that we can use third-party tools to run tests. The focus should be on nose (and maybe pylint). To include a sample buildout configuration or not, that is a true question. Opinions differ about it. I guess it could be discussed in a separate thread. |
|
Agreed for the .pyc files. |
About nose and dependencies In the proposal, Nose is not really a dependency: Nose is a tool to discover tests, run them and improve feedback. The tests remain standard! One could run them with another testrunner. My suggest is:
The other dependencies in the sample (ipdb, ipython, rednose, pylint...) were provided as examples too. The fileconveyor project does not depend on them! The point was to show how to use some external tools to run tests:
|
Is the buildout error a bug with distribute on OSX? https://bitbucket.org/tarek/distribute/issue/113/distribute-fails-on-fresh-osx-106-system |
I have no idea if it's a bug on OS X, but if it fails, then it's not a good choice IMO. (For the record: yes, I'm using OS X.) Regarding preferred toolchains and not including a testrunner: I agree it's good to offer the user a choice. But most users don't tend to be Python experts such as yourself. Then it's nice to have a So, how about a simple |
Yes, you can write some testsuite.py. Buildout or not buildout was not the point here. I tried to give you some shortcuts to experiment nose. I'm sorry it fails currently. Moreover, the buildout configuration includes pyinotify, so it is not suitable for OS X (not without some edit). My bad. |
Unit tests are currently written per Python module (since I wrote this module per module, until each module was suitably tested and pretty much bug-free) and don't come with a project-wide test runner yet, that runs all individual unit tests.
This issue is about writing that test runner.
(The above is copied almost verbatim from #81, more specifically from this comment.)
The text was updated successfully, but these errors were encountered: