Opened 15 years ago
Closed 15 years ago
#15689 closed (fixed)
test --failfast doesn't stop on errors in _pre_setup()
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Testing framework | Version: | 1.2 |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
--failfast stops on the first failure, but doesn't stop on the first error.
I think it should.
Change History (4)
comment:1 by , 15 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
comment:3 by , 15 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
| Summary: | test --failfast doesn't stop on errors → test --failfast doesn't stop on errors in _pre_setup() |
Sorry, I mis-reported. I've updated the title, though Trac won't let me edit the description (maybe I wasn't signed in before).
The real problem was that if TestCase._pre_setup() raises an exception, all tests are still run but reported as errors.
I did notice that exceptions raised by TestCase.setUp() *will* exit on the first error with --failfast.
So far, _pre_setup() is the only place I've observed this problem with failfast.
FWIW, the way that I discovered this was by having a multi-database configuration that worked on 1.2.3 but apparently wasn't compatible with the introduction of the TEST_DEPENDENCIES setting in 1.2.4.
Demonstration: Drop this in your app's tests.py and run tests:
class SimpleTest(TestCase):
def _pre_setup(self):
super(SimpleTest, self)._pre_setup()
raise Exception("oh nooo")
def test_aaa_ok(self):
pass
def test_bbb_ok(self):
pass
def test_ccc_nameerror(self):
return foo
def test_ddd_zerodivisionerror(self):
return 3 / 0
def test_eee_failing(self):
self.assertEqual(1, 2)
def test_zzz_ok(self):
pass
I see 6 errors reported, even with --failfast:
$ django-admin.py test --failfast testapp ... snip ... Ran 0 tests in 0.001s FAILED (errors=6) Destroying test database 'default'...
comment:4 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Re-closing. I just tested upgrading to Django 1.3 and it has apparently fixed this problem already.
It does in my experience:
(This is with roughly 1.3 level.)