Why do I have to use the --exe argument while I run django-nose tests.
If I don't use it, it will skip the tests to run
e.g.
manage.py test myapp
Ran 0 tests in 0.000s
while my tests are in the correct place etc.
Running it in verbosity 3 it shows:
nosetests --verbosity 3 myapp
it shows: (changed the path names, but anyway, nose finds them but skips them!!)
nose.selector: INFO: /path_to_project/path_to_app/myapp/tests.pyc is executable; skipped
nose.selector: INFO: /path_to_project/path_to_app/myapp/tests.py~ is executable; skipped
The only way to run the tests is using the --exe argument
I Am using:
Ubuntu (both 10.4 or 11.4 doesn't matter)
Python 2.6 and 2.7
Django 1.4.3
why is that?
According to the documents you won't need --exe
But after puzzling for a while... and googling and looking here, i got this suggestion.
see Nose doesn't find Django tests
and Nose unable to find tests in ubuntu
But nowhere the explanation of this workaround for what seems to be a bug?
Or Am I missing something?
I requestion this, because the other questions are quite old, and no satisfactory answer to this problem found.....
It's not a bug - it's a feature.
Please, see good explanations here: What does "import safe" mean in Python?
Related
So, I'm working on a robotframework test project, and the goal is to run several test suites in parallel. For this purpose, pabot was chosen as the solution. I am trying to implement it, but with little success.
My issue is: after installing Pabot (which, I might say, I did by cloning the project and running "setup.py install", instead of using pip, since the corporate proxy I'm behind has proven an obstacle I can't overcome), I created a new directory in the project tree, moved some suites there, and ran:
pabot --processes 2 --outputdir pabot_results Login*.robot
Doing so results in the following error message:
2018-10-10 10:27:30.449000 [PID:9676] [0] EXECUTING Suites.LoginAdmin
2018-10-10 10:27:30.449000 PID:400 EXECUTING Suites.LoginUser
2018-10-10 10:27:30.777000 PID:400 FAILED Suites.LoginUser
2018-10-10 10:27:30.777000 [PID:9676] [0] FAILED Suites.LoginAdmin
WARN: No output files in "pabot_results\pabot_results"
Output:
[ ERROR ] Reading XML source '' failed: invalid mode ('rb') or filename
Try --help for usage information.
Elapsed time: 0 minutes 0.578 seconds
Upon inspecting the stderr file that was generated, I have this message:
Traceback (most recent call last):
File "C:\Python27\Lib\site-packages\robotframework-3.1a2.dev1-py2.7.egg\robot\running\runner.py", line 22, in
from .context import EXECUTION_CONTEXTS
ValueError: Attempted relative import in non-package
Apparently, this has to do with something from the runner.py script, which, if I'm not mistaken, came with the installation of robotframework. Since manually modifying that script does not seem to me the optimal solution, my question is, what am I missing here? Did I forget to do anything while setting this up? Or is this an issue of compatibility between versions?
This project is using Maven as the tool to manage dependencies. The version I am running is 3.5.4. I am using a Windows 10, 64bit system; I have Python 2.7.14, and Robot Framework 3.1a2.dev1. The Pabot version is 0.44. Obviously, I added C:\Python27 and C:\Python27\Scripts to the PATH environment variable.
Edit: I am also using robotframework-maven-plugin version 1.4.0.8, if that happens to be relevant.
Edit 2: added the error messages in text format.
I believe I've come across an issue similar when setting up parallel execution on my machine. Firstly I would confirm that pabot is installed using pip show robotframework-pabot.
Then you should define the directory your results are going to using -d.
I then modified the name of the -o to Output.xml to make it easy to identify.
This is a copy of the code I use. Runs optimally with 8 processes
pabot --processes 8 -d results -o Output.xml Tests
Seems that you stumbled on a bug in the prerelease version of robot framework (3.1a2.dev1).
Please install a release version of robot framework. For example 3.0.4.
Just in case anyone happens to stumble upon this issue in the future:
Since I can't use pip, and I tried a good deal of workarounds that eventually made things more unstable, I ended up saving my project and removing everything Python-related from my system, so as to allow me to install everything from scratch. In a Windows 10, 64bit system, I used:
Python 2.7.14
wxPython 2.8.12.1, win64, unicode, for py27
setuptools 40.2.0 (to allow me to use the easy_install command)
Robot Framework 3.0.4
robotremoteserver 1.1
Selenium2Library 3.0.0
and Pabot version 0.45.
I might add that, when installing the Selenium2Library the way I described above, it eventually tries to download some things from the pip repositories - which, if you have a proxy, will cause you trouble. I solved this problem by browsing https://pypi.org/simple/selenium/, manually downloading the 2.53.6 .tar.gz file, then extracting it and running setup.py install on the command line.
PS: Ideally, though, anyone should be able to use proxy settings from the command line (--proxy http://user:password#server:port) to get pip and then use it; however, for some reason, probably related to network security configurations that I didn't want to lose time with, this didn't work in my case.
I'm attempting to set up a new django project, and I've configured TEST_RUNNER in settings.py to be django_nose.NoseTestSuiteRunner.
I chose this test runner because it seems to be the only one I can find that has the following features:
writes xunit xml test report
captures logging/stdout and only displays for failed tests.
However I've heard that nose is unmaintained and I'm having a hard time finding a suitable replacement. The standard test runner doesn't capture logging nor writes xunit as far as I'm able to tell (would love to be proven wrong!)
I run tests like so:
python -m coverage run manage.py test --noinput
python -m coverage report --include="app/*" --show-missing --fail-under=100
python -m coverage xml --include="app/*" -o ./reports/coverage.xml
With this in settings.py:
TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'
And this setup.cfg:
[nosetests]
verbosity=0
with-xunit=1
xunit-file=./reports/xunit.xml
logging-clear-handlers=1
The last two lines are the real juicy bits I can't seem to find in other test runners. nose captures the logging and clears other logging handlers (eg, the handler that dumps on stdout) so the test runs output is much cleaner (you only see logging for tests that failed).
In other non-django projects I typically use nose2 but django-nose2 project appears to be 6 years old and lacking python3 support??
Please let me know which test runner is the "recommended" one (eg, most popular) with django support, thanks.
I have had success with unittest-xml-reporting:
TEST_RUNNER = 'xmlrunner.extra.djangotestrunner.XMLTestRunner'
https://github.com/xmlrunner/unittest-xml-reporting#django-support
The output directory can be configured with the TEST_OUTPUT_DIR setting.
You may still use nose runner:
INSTALLED_APPS += ['django_nose']
TEST_RUNNER = 'django_nose.NoseTestSuiteRunner'
NOSE_ARGS = [
'--with-xunit',
'--xunit-file=nosetests.xml',
'--with-coverage',
'--cover-erase',
'--cover-xml',
'--cover-xml-file=nosecover.xml',
]
So pytest produces some very nice test output. I've unset TEST_RUNNER in settings.py and changed my test script to:
python -m coverage run -m pytest --junitxml=./reports/junit.xml
python -m coverage report --include="app/*" --show-missing --fail-under=100
python -m coverage xml --include="app/*" -o ./reports/coverage.xml
This works, and captures ALL logging output (nose was a little buggy and let one or two logging statements slip through, very strange behavior).
The only thing is that I'm a django novice so I don't know if there are any bad side-effects of not using manage.py test for testing django. Any guidance is appreciated, thanks!
I've installed nose and coverage to my virtual env, but it doesn't work
(venv) ../my_cookbook$ nosetests --with-coverage
nose.plugins.cover: ERROR: Coverage not available: unable to import coverage module
I wondered if it was escaping my venv somehow, so I tried this and it worked!
(venv) ../my_cookbook$ ./venv/bin/nosetests --with-coverage
Then I wanted to see if my path was some how messed up.
(venv) ../my_cookbook$ which nosetests
/home/peter/Projects/my_cookbook/venv/bin/nosetests
(venv) ../my_cookbook$ which coverage
/home/peter/Projects/my_cookbook/venv/bin/coverage
So what is going on here? Somehow the nosetests command is escaping my virtualenv but I don't know how.
Unfortunately, I don't have an explanation why the nose plugin is not picking up coverage, but, executing your tests through coverage should be preferred as opposed to using test runner plugins (nose coverage plugin in your case). Quoting Ned Batchelder (the author of coverage):
using a plugin means you are depending on that plugin's behavior being correct and understandable. In the name of being helpful, plugins will have their own logic that may have been the best idea when they were written, but the test runner and/or coverage.py may have changed in the meantime. The plugins tend not to be as well-maintained as the other components. If you can avoid them, you have one less thing to think about.
In other words, run:
$ coverage run -m nose
and to get the coverage report:
$ coverage report
I just started using Django, and have only used PyTest for a couple of projects, but I love them both.
So I was happy to discover the pytest-django plugin that seems incredibly straight-forward and easy to use.
Per part 5 of the Django tutorial (I've been working through that), I've written a number of tests in mysite/polls/tests.py. These run flawlessly with the built-in test runner.
So, now with pytest and pytest-django installed, when I run py.test from within the project root, or py.test polls I get nothing:
When I explicitly invoke my file with py.test polls/tests.py, I get the colorful expected output:
What have I missed? I've followed the set up to the letter, and the Basic Usage docs of the plugin attest that a simple py.test should automatically find my tests. Why aren't they being found?
Following pytest naming conventions, try renaming your test file to:
test_[some text here].py
For example:
test_polls_unittests.py
Read more about pytest - tests naming conventions here.
I normally run tests for specific django apps, but I was curious and decided to run the entire test suite (which includes django tests) with
./manage.py test
The test suite freezes.
To find out why/where, I ran
./manage.py test -v 2
and it appears that the test stops working at
test_date_length (django.contrib.auth.tests.tokens.TokenGeneratorTest) ...
This behavior happens for both django 1.3 and django 1.4+ (trunk).
Would appreciate any pointers on why this is happening.
After some debugging, I discovered that this problem is a result of a Python (2.7) bug compiled by clang via MacPorts.
A loop that is executed by Python in Django code base during the execution of the TokenGeneratorTest
factor = 0
while True:
factor += 1
if i < 36 ** factor:
factor -= 1
break
hangs on Python 2.7 compiled by clang (via MacPorts).
I recompiled my Python 2.7 with apple-gcc-4.2 and this while loop no longer freezes when given a large i value.
As an elaboration on the previous answer, recompile python using the instructions on http://blog.damacy.net/post/12104768819/compiling-macports-python-on-lion-using-gcc.
I use the Apple Command Line Tools and Homebrew. This is how i fixed this error:
brew uninstall python
brew install --use-llvm python