cleancut / green Goto Github PK
View Code? Open in Web Editor NEWGreen is a clean, colorful, fast python test runner.
License: MIT License
green's Issues
Use containerized travis-ci build.
sudo isn't used in the .travis.yml file. Travis CI has a much faster container based infrastructure that we can use if we're just using PyPI to install dependencies.
Change blue to cyan for skipped tests
The blue color tends to not show up very well under windows CMD:
If changed to cyan:
Diff for output.py
--78: return termstyle.blue(text)
++78: return termstyle.cyan(text)
Options set via config file are disrespected
Options set via a config file are no longer working for me. Here's a simple example:
$ cat ~/.green
verbose = 2
$ green
.....
Ran 5 tests in 0.001s
OK (passes=5)
I observe the same problem with other options in my config file (eg, file_pattern). They aren't being picked up at all.
When I checkout to v1.71, the example above works as expected, but not in v1.80 and beyond.
uncaught exception from testcase - exit without traceback
Python 2.7.10 & 3.4.3
I have a failing test (in fact it is expected at them moment lacking some implementation), yet I get no traceback, nor do any remaining tests run - clean exit after printing a red E, which is quite embarrassing.
$ green lib
........................................E$In fact I get the same clean exit from plain unittest
$ python -m unittest discover
........................................E$Note: even a final new line was not printed!
unittest2 shows a relevant traceback and stops afterwards (no new tests are run).
Actually I am using testtools which depends on unittest2, so it works with that as well:
$ python -m testtools.run discover
Tests running...
======================================================================
ERROR: lib.tool.test_...
----------------------------------------------------------------------
Traceback (most recent call last):
...
File "/usr/lib64/python3.4/argparse.py", line 1728, in parse_args
args, argv = self.parse_known_args(args, namespace)
File "/usr/lib64/python3.4/argparse.py", line 1767, in parse_known_args
self.error(str(err))
File "/usr/lib64/python3.4/argparse.py", line 2386, in error
self.exit(2, _('%(prog)s: error: %(message)s\n') % args)
File "/usr/lib64/python3.4/argparse.py", line 2373, in exit
_sys.exit(status)
SystemExit: 2
nose runs properly, even capturing the uncaught second exception in unittest2 and continuing.
Unfortunately I could not create a minimal reproduction, yet (my attempts so far misteriously worked), but could pinpoint the place where it could be fixed.
Changing this line makes things work (though, this might not be the proper fix):
Line 111 in 2a3b302
try:
test(result)
except:
passIs it possible to run tests using green programmatically?
Description of dotted object in exception listing is missing class
Lets just change it to report the full dotted-name of the test, now that we always have access to it.
[question] nose @raises decorator
Hi there,
I have a lot of code covered by nose tests and I am evaluating migration to another test runner. I agree with your explanations and conclusions.
I have unit tests that import some nose sugar coating:
from nose.tools import raisesand then use it like this:
@raises(MyExceptionThatShouldBeRaised)
def test_number_one():
foo()Do we have some similar syntaxic sugar in green yet?
Redo Output Options
I would rather have fine-grained output options.
We can leave the -v,-vv,-vvv options as shortcuts to a set of the fine-grain options.
Cases we don't currently handle that we want to be able to:
- show the method name AND the docstring
- show only the module name and then trailing dots for the module's tests
- show just the method docstrings (no module or classes)
Tests get different fully-dotted names depending on the discovery-method used.
Test discovery sometimes gives pkg.module.submodule... when some discovery methods are used, and for others it gives submodule...
This is mildly annoying for regular output, but incredibly frustrating when trying to implement output for bash/zsh completion in #7.
This has got to be fixed. I hope I don't have to rewrite all of test discovery.
Get Windows CI passing builds on AppVeyor
Green 1.9.1 - would appear that --allow-stdout is broken
Hi -
Very much like green - thanks for providing it. It would appear that the -a or --allow-stdout option is not working - stdout is still captured with the argument. Have tested with
Green 1.9.1, Python 3.4.3
Green 1.9.1, Python 2.7.9
If I change the value of allow_stdout to True in default_args in config.py:47 - then stdout is not captured - so it would appear that there is some issue in parsing the arguments to green. Haven't dug down to that part of the code yet.
Thanks, Jim
Pip install does not register nose plugin
Hello,
I wanted to give green a try, did 'sudo pip install green', which was sucessful, but 'nosetest --plugins' is not showhing it installed, and my output looks the same.
-f/--filterr to indicate which tests to run
There was a good suggestion to implement some flexible way of narrowing down which test(s) you want to run in conjunction with auto-discovery of tests.
Support external concurrent requirements
Many test environments require extra tooling for concurrently accessing external requirements. We need support for this in subprocess mode. For example, each subprocess may need to set up its own database for tests to access.
Since 97569e1, setUpClass is called once per test
Since 97569e1 setUpClass, tearDownClass setUpModule and tearDownModule get called once per unit test. This is due to running each suite's component individually, as the subprocess mode does.
According to the unittest documentation the order and number of times setUpClass and tearDownClass are called isn't strictly-speaking defined. It just so happens that by convention on unittest's own single-threaded mode that they only get called once, since the tests run in order. No guarantee is made about what happens when tests are run in a randomised order or in parallel.
Personally, I use those methods to do "expensive" set up and tear down where I know I can maintain the invariant between tests in setUp and tearDown. As such, the current behaviour makes my tests run a lot slower.
I would submit that the correct behaviour is to detect where tests are setting those methods and only divide up suites to the level where any of those methods are defined. So, for instance, if setUpClass was defined on a TestCase, then the entire TestCase should run in serial, but could be parallelized amongst other tests.
Here's some output to show the problem and a testcase:
from testtools import TestCase
import sys
class TestSetUpClass(TestCase):
"""Test set up class."""
@classmethod
def setUpClass(cls):
sys.stderr.write("setUpClass\n")
def test_one(self):
"""One"""
sys.stderr.write("method one on two called\n")
pass
def test_two(self):
"""Two"""
sys.stderr.write("method two on two called\n")
pass
def test_three(self):
"""Three"""
sys.stderr.write("method three on two called\n")
pass
Green 1.11.0, Coverage 3.7.1, Python 2.7.9
test.test_two.test_set_up_class
TestSetUpClass
OnesetUpClass
method one on two called
setUpClass
method three on two called
. One
. Three
TwosetUpClass
method two on two called
. Two
Ran 3 tests in 0.108s
OK (passes=3)
Improve Green's own Unit Tests
Areas that could be improved:
- Use only one style of docstring
- Leverage helper functions and
textwrap.dedent()to reduce the amount of boilerplate code in tests where we write external test files to load and run. - Use newer testing facilities like
addCleanupand context handlers.
Support "failfast" like unittest
(Split into its own issue from #5 so it can be addressed separately.)
A feature that is present in unittest (when tests are invoked via python -m unittest project.test) that would be really nice to have:
-f, --failfast Stop the test run on the first error or failure.
Config file support
It would be nice to support a .green config file.
subunit support
I've just started playing with Green and it works really well so far. However, I'd like to use it in automated tools, and I've had good success with subunit for this (reporting up to buildbot, for example).
Supporting subunit via a plugin or directly would be great!
Alternatively, some sort of structured output option (junit XML? json?) would be nice instead (or as well).
Consider creating 'Parameterized tests'
Parameterized tests are the only one feature that i miss in green.
@params(1, 2, 3)
def test_nums(num):
assert num < 4
or
@params((1, 2), (2, 3), (4, 5))
def test_less_than(self, a, b):
assert a < b
http://nose2.readthedocs.org/en/latest/params.html
https://github.com/nose-devs/nose2/blob/master/nose2/tools/params.py
Make green work with nose_parameterized
Import Errors shouldn't crash "green --completions"
In the context of providing an autocompletion list, it makes much more sense for green to ignore import errors than raise them and crash.
Bad import causes no tests
When testing the following file, green does not find any tests.
#! /usr/bin/env python
import unittest
import xml.etree.ElementTree.Element
class TestElement(unittest.TestCase):
def test_foo(self):
ElementPython unittest's results:
$ python -m test_foo.py
/usr/bin/python: Error while finding spec for 'test_foo.py' (<class 'ImportError'>: No module named 'xml.etree.ElementTree.Element'; 'xml.etree.ElementTree' is not a package)
Green's results:
$ green -d test_foo.py
2014-08-22 16:29:20 DEBUG Attempting to load target 'test_foo.py' with file_pattern 'test*.py'
2014-08-22 16:29:20 DEBUG Found 0 tests for target 'test_foo.py'
2014-08-22 16:29:20 DEBUG No test loading attempts succeeded. Created an empty test suite.
Ran 0 tests in 0.000s
No Tests Found
Upon removal of the import line, green finds the test and rightly fails it:
#! /usr/bin/env python
import unittest
class TestElement(unittest.TestCase):
def test_foo(self):
Element$ green -d test_foo.py
2014-08-22 16:29:37 DEBUG Attempting to load target 'test_foo.py' with file_pattern 'test*.py'
2014-08-22 16:29:37 DEBUG Load method: FILE - test_foo.py
2014-08-22 16:29:37 DEBUG Found 1 test for target 'test_foo.py'
E
Error in test_foo.TestElement.test_foo
File "/usr/local/lib/python3.4/unittest/case.py", line 57, in testPartExecutor
yield
File "/usr/local/lib/python3.4/unittest/case.py", line 574, in run
testMethod()
File "/home/rolobio/tmp/test_foo.py", line 7, in test_foo
Element
NameError: name 'Element' is not defined
Ran 1 test in 0.001s
FAILED (errors=1)
possible problem with virtualenv
I'm using py.test for my project. It works nicely from within a virtualenv.
(env) (precise)tad@localhost:/share/husl-numpy$ which python
/home/tad/Downloads/share/husl-numpy/env/bin/python
(env) (precise)tad@localhost:/share/husl-numpy$ which py.test
/home/tad/Downloads/share/husl-numpy/env/bin/py.test
(env) (precise)tad@localhost:/share/husl-numpy$ python -c "import numpy; print(numpy.__version__)"
1.9.2
Note that numpy is importable. Let's run the tests.
(env) (precise)tad@localhost:/share/husl-numpy$ py.test test.py
========================================================================= test session starts ==========================================================================
platform linux -- Python 3.4.3 -- py-1.4.30 -- pytest-2.7.2
rootdir: /home/tad/Downloads/share/husl-numpy, inifile:
collected 33 items
test.py .................................
====================================================================== 33 passed in 0.93 seconds =======================================================================
Yay! It works. Now, here's where I've put green:
(env) (precise)tad@localhost:/share/husl-numpy$ which green
/home/tad/Downloads/share/husl-numpy/env/bin/green
Let's run the tests with green:
(env) (precise)tad@localhost:/share/husl-numpy$ green test.py
Traceback (most recent call last):
File "/usr/local/bin/green", line 9, in <module>
load_entry_point('green==2.0.0', 'console_scripts', 'green')()
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/cmdline.py", line 79, in main
result = run(test_suite, stream, args) # pragma: no cover
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/runner.py", line 92, in run
targets = [(target, manager.Queue()) for target in toParallelTargets(suite, args.targets)]
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 57, in toParallelTargets
proto_test_list = toProtoTestList(suite)
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 42, in toProtoTestList
toProtoTestList(i, test_list, doing_completions)
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 42, in toProtoTestList
toProtoTestList(i, test_list, doing_completions)
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 36, in toProtoTestList
getattr(suite, exception_method)()
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 398, in testFailure
raise ImportError(message)
ImportError: Failed to import test:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/site-packages/green-2.0.0-py3.4.egg/green/loader.py", line 390, in loadTarget
tests = loader.loadTestsFromName(dotted_path)
File "/usr/local/lib/python3.4/unittest/loader.py", line 105, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File "/home/tad/Downloads/share/husl-numpy/test.py", line 2, in <module>
import numpy as np
ImportError: No module named 'numpy'
What might I be doing wrong? Thanks.
Handle tracebacks more nicely
- Highlight the most pertinent part of a traceback
- Cut out useless parts of the traceback
Depends on #14 and avoiding unittest's mangling of tracebacks.
Support AppVeyor's PowerShell
Running green in AppVeyor CI does not color results.
However, I think this may be an AppVeyor issue, as I can run green in Windows PowerShell myself and get at least some form of coloring (other issues, such as IT permissions here at work) are preventing me from really testing green + PowerShell thoroughly.
I figured I'd record this issue here even if it's out of your control.
Django compatibility
The Django test runner does all sorts of magic to set up a test database. For green to work with Django, it would have to hook into all that voodoo somehow.
Here's a minimal django project you can use for tests: https://github.com/hjwp/Minimal-Django-project-with-model-test
to run green, use:
DJANGO_SETTINGS_MODULE=myproj.settings green
Can all options in ~/.green be overridden on the command line?
I've got this in ~/.green:
verbose = 2
pattern = *_tests.py
And I'm not having any luck overriding those settings on the command line.
bash-/zsh-completion integration should redirect stderr to /dev/null as well
bash-/zsh-completion integration should redirect stderr to /dev/null as well
Consider creating a decorator that would enable marking bare functions using asserts to be run as a TestCase
Maybe it would be possible to create a decorator which wrapped a bare function and assert and generated a standard unittest class/method out of it. It would require importing the decorator and decorating the function, obviously. Maybe it would look something like this:
from green import testme
@testme
def myfunc():
assert foo == bar, "foo = bar"
Maybe that could return a wrapped version of the function that would be semantically equivalent to:
import unittest
class TestMyfunc(unittest.TestCase):
def test_myfunc(self):
# XXX Call myfunc() and translate its behavior into unittest XXX
-vv doesn't find a docstring description if the docstring begins with `\n`
-vv needs to look past initial whitespace to find a docstring line.
Capture stdout (and stderr?)
Right now, any output to stdout/stderr is mixed into the console output at the current cursor spot, messing with our nice output. Lets handle it in a better way.
hjwp's feedback:
by default py.test captures all stdout/stderr by default, and then only shows you the output from tests that failed. I think nose does something similar... it's definitely something that's sometimes useful, but sometimes not, so I would pick a sensible default but allow the user to override it and get back to "normal" stdout behaviour...
Verbosity levels when running green with django
Is green's fine verbosity an option when running green as the default test runner for django?
I tried but I got django's default v3 level, where showing you how it's setting up the test database is as verbose as it gets.
improve the pytest section
would be nice to mention that apparently pytest has all the features of green and more or maybe comment on what is missing.
[question] setup.py integration
I'd like a way to integrate with setup.py more finely than what is currently possible (to my understanding at least).
Here is the long story
I found the way to integrate with setup.py using this code:
test_suite='green.test',
tests_require=['coverage', 'green'],but has you can see in my example I want to use coverage to produce reports.
What I did when using nose
in setup.py
test_suite='nose.collector',
tests_require=['nose', 'nosexcover'],and in setup.cfg
[nosetests]
detailed-errors=1
with-doctest=1
verbose=True
with-xunit=True
with-xcoverage=True
[aliases]
test = nosetests --detailed-errors --with-doctest --cover-package=mypackagebut using green I cannot (did not find the way to) provide an alias and thus cannot force the production of a correct .coverage directory
Current situation & usage
At the same time running python setup.py test with test_suite='nose.collector' will generate a directory named like this: .coverage.1_7173 but the appended number will change at every run and the generated files will reference temporary files that are long gone before you can run coverage html
My solution for the moment is to no use test_suite='nose.collector' and provide a simple shell script like this:
runtests.sh
#!/bin/bash
# run the green test runner (pip install --upgrade green)
green -r <mypackagenamehere>
# then generate the coverage report (pip install --upgrade coverage)
coverage html
# then open coverage_html_report/index.html to review the resultsAdd support for Windows CMD
Add support for windows CMD by using colorama (https://pypi.python.org/pypi/colorama) in addition to termcolor.
Don't print \r if we're not connected to a terminal
\r does nothing if stdout is connected to a pipe or file. This means that you'll get duplicated lines, which probably isn't what you want.
Support "catch" like unittest
Some features that are present in unittest (when tests are invoked via python -m unittest project.test) that I would consider really nice to have:
- "-c"/"--catch": Control-C during the test run waits for the current test to end and then reports all the results so far. A second control-C raises the normal KeyboardInterrupt exception.
- "-f"/"--failfast": Stop the test run on the first error or failure.
Edit: Balanced some parens, etc.
Automate testing installed versions of green
Green should be tested after being installed to ensure that it actually works after installation. Because working in a clone of the repo is not really useful if the installation is broken. Perhaps this is a good place to use tox
Does green support different file naming patterns?
At various points in loader.py, it looks like green intends to support the idea of a file_pattern. But I don't see any command-line options to control this behavior. Also, I don't think that the value of file_pattern is actually being passed through the call stack down to the underlying discover() function. Perhaps I'm overlooking something.
Anyway, green looks like a great project and I'm eager to try it out (frustrated with nose, pytest, and unittest). But on my team we follow a *_tests.py naming convention, so I've been unable to get out of the starting gate.
Consider using drone.io
drone.io is a competitor to Travis. We should evaluate whether it would be good to use in addition to or instead of Travis (if at all).
Typo in line 14 of cmdline.py
"covarage_version" should be "coverage_version". If coverage isn't installed, this will cause the command to error out with a NameError:
NameError: global name 'coverage_version' is not defined
Command-line completion for tests
Command-line completion for test names passed to the test runner, whether module name ("project.test.test_module_a") or test case ("project.test.test_module_a.TestCaseA") or test itself ("project.test.test_module_a.TestCaseA.test_run1").
TypeError: __init__() takes at most 5 arguments (6 given) in subprocess.py
I'm getting the following traceback on pypy3
Traceback (most recent call last):
File "/home/travis/build/polysquare/polysquare-ci-scripts/setup.py", line 44, in <module>
include_package_data=True)
File "/opt/python/pypy3-2.4.0/lib-python/3/distutils/core.py", line 148, in setup
dist.run_commands()
File "/opt/python/pypy3-2.4.0/lib-python/3/distutils/dist.py", line 917, in run_commands
self.run_command(cmd)
File "/opt/python/pypy3-2.4.0/lib-python/3/distutils/dist.py", line 936, in run_command
cmd_obj.run()
File "/home/travis/virtualenv/pypy3-2.4.0/site-packages/setuptools_green/__init__.py", line 34, in run
sys.exit(green.cmdline.main())
File "/home/travis/virtualenv/pypy3-2.4.0/site-packages/green/cmdline.py", line 87, in main
result = run(test_suite, stream, args) # pragma: no cover
File "/home/travis/virtualenv/pypy3-2.4.0/site-packages/green/runner.py", line 52, in run
pool = LoggingDaemonlessPool(processes=args.subprocesses or None)
File "/home/travis/virtualenv/pypy3-2.4.0/site-packages/green/subprocess.py", line 98, in __init__
initargs, maxtasksperchild, context)
TypeError: __init__() takes at most 5 arguments (6 given)
Option to disable reporting test's stdout
It might be nice for some folks who just have crap being output during their tests to just ignore it entirely. Like this poor guy:
https://groups.google.com/forum/#!topic/nose-users/0lbfW-segJM
Multiple Targets
It would be very helpful if Green supported multiple test targets.
Some example syntax:
green test.tests1 test.testsgreen -v --run-coverage test.tests1 test.tests2
Consider adding an output mode that lists dots delineated by modules
Consider adding an output mode (maybe as -v and shift current -v to -vv and current -vv to -vvvv?) where the body of the output looks like pytests's default output.
green/test/test_cmdline.py ........
green/test/test_loader.py .............
green/test/test_output.py ...........
green/test/test_result.py .........................
green/test/test_runner.py ..........
green/test/test_subprocess.py ......
green/test/test_version.py ...
Automate testing installing green
The 1.0 release was broken because there's no automated testing of installing green.
Error in green.runner.N/A.poolRunner
Firstly, thanks for creating this project. I quite enjoy being able to add a little bit of colour to the command line!
Something changed in green between version 1.9.4 and 1.10.0. Before all my tests ran as expected. Output from v1.9.4:
test_colour
Test_Colour
. test_3hex_colour
. test_6hex_colour
. test_colour_bad_Tuple_value
. test_colour_bad_hex_chars
. test_colour_bad_hex_string_length
. test_colour_bad_list_legnth
. test_colour_bad_list_value
. test_colour_bad_tuple_legnth
. test_colour_blue
. test_colour_green
. test_colour_hex
. test_colour_hex_black
. test_colour_list
. test_colour_not_hex_string
. test_colour_red
. test_colour_repr
. test_colour_rgb
. test_colour_rgb_nomralized_black
. test_colour_rgb_normalized_white
. test_colour_str
. test_colour_tuple
x test_colour_vs_color
. test_default_colour
Test_Contrast
. test_contrast_black_black
. test_contrast_from_colour
. test_contrast_white_black
. test_contrast_white_white
Test_Luminance
. test_luminance_as_colour_property
. test_luminance_black
. test_luminance_colour_provided
. test_luminance_white_hex
. test_luminance_white_tuple
test_palette
Test_Palette
. test_palette_length
. test_palette_repr
. test_palette_str
test_setup
Test_Setup
. test_version
. test_we_live
Ran 37 tests in 0.009s
OK (expected_failures=1, passes=36)
However, with v1.10.0, none of the tests pass, and it seems to be an issue with green. Here is the output:
test_colour
Test_Colour
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
Test_Contrast
E poolRunner
E poolRunner
E poolRunner
E poolRunner
Test_Luminance
E poolRunner
E poolRunner
E poolRunner
E poolRunner
E poolRunner
test_palette
Test_Palette
E poolRunner
E poolRunner
E poolRunner
test_setup
Test_Setup
E poolRunner
E poolRunner
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Error in green.runner.N/A.poolRunner
File "C:\Python34\lib\site-packages\green\subprocess.py", line 236, in poolRunner
test.run(result)
AttributeError: 'NoneType' object has no attribute 'run'
Ran 37 tests in 0.420s
FAILED (errors=37)
I'm running Python 3.4.2 on Windows 7. The tests are from colourettu.
Seems like Green runs the same tests multiple times
I have a project that I've been fiddling with. I was trying to decide between the following two project structures:
Structure A (the original structure):
+ ProjectFoler
+ dist
+ doc
+ main_package
- __init__.py
- module1.py
- module2.py
+ tests
- __init__.py
- test_module1.py
- test_module2.py
- .travis.yml
- other stuff like dev_requirements.txt, appveyor.yml, setup.py, etc.
Structure B (what I tried moving to):
+ ProjectFoler
+ dist
+ doc
+ main_package
- __init__.py
- module1.py
- module2.py
+ tests <-- note that this is *not* under the package directory
- __init__.py
- test_module1.py
- test_module2.py
- .travis.yml
- other stuff like dev_requirements.txt, appveyor.yml, setup.py, etc.
Before making the change from A to B, nosetests and green worked just fine. My project currently has 23 tests.
After switching to structure B, nosetests worked just fine, while green ran 46 tests - exactly 2x the number of tests there are. Running green in verbose showed that it was still running tests from ProjectFolder\main_package\tests in addition to the tests found in ProjectFoler\tests
So I decided to switch back to structure A. Again, nosetests run 23 tests correctly, but this time green ran 69 tests - 3x! Running in verbose shows that green runs:
- tests from
ProjectFolder\main_package\tests - tests from
ProjectFolder\tests - tests from
ProjectFolder\main_package\testsagain
Does green save anything? Is there a file I should delete? I've already tried deleting __pycache__ in all folders.
I'm trying to recreate the issue with a simpler project, but have so far been unsuccessful. I'll continue to try and get exact steps to reproduce the issue.
Edit 1
Oh, I forgot relevant information:
- Green version 1.9.4 (1.10 and above gives me different errors and doesn't run)
- Python 3.4.3, 64bit
- Windows 7 Professional
- Running python via WinPython 1.1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.