if _setUp() fails in useFixture(fixture) then TypeError is raised

Bug #1469759 reported by Jakub Libosvar on 2015-06-29
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
testtools
High
Julian Edwards

Bug Description

This bug seems like a regression caused by https://github.com/testing-cabal/fixtures/pull/11/files

When we raise an exception in _setUp() method, cleanups are called properly. But later then useFixtures() uses getDetails() that use internal _details, which were already set to None by calling _remove_state() in cleanUp() method.

Seems like useFixtures() doesn't count on that cleanUp() was already called above fixture object.

  File "neutron/tests/functional/test_tools.py", line 67, in test_error_after_root_setup
    fix = self.parent.useFixture(fixture)
  File "/usr/lib/python2.7/site-packages/testtools/testcase.py", line 670, in useFixture
    gather_details(fixture.getDetails(), self.getDetails())
  File "/usr/lib/python2.7/site-packages/fixtures/fixture.py", line 169, in getDetails
    result = dict(self._details)
TypeError: 'NoneType' object is not iterable

Robert Collins (lifeless) wrote :

This isn't a regression. It was poor (invalid) API use by testtools, which this now highlights.

I'm retargeting the bug to testtools, which is where we need to fix this. But it only shows up as a cascade failure - it won't cause tests to spuriously pass, or to spuriously fail.

affects: python-fixtures → testtools
Changed in testtools:
status: New → Triaged
importance: Undecided → High
milestone: none → next
assignee: nobody → Robert Collins (lifeless)
Robert Collins (lifeless) wrote :

(For clarity - that code could never return details on any hermetic fixture - they would have cleaned up already. Any fixture that wasn't hermetic would leak at least until gc, perhaps longer.

Jonathan Lange (jml) on 2015-11-13
Changed in testtools:
milestone: 1.8.1 → none
Jonathan Lange (jml) wrote :

I didn't check 'next' milestone before releasing. Filed #1516087 for adding notes to the release documentation / automation.

Julian Edwards (julian-edwards) wrote :

I'd like to help fix this. Can someone explain where testtools is using the wrong fixtures API?
Cheers

Robert Collins (lifeless) wrote :

testtools assumes fixture details are readable after setUp fails. It should instead pull the details out of the failure.

Julian Edwards (julian-edwards) wrote :

If the details were already gathered previously, that whole section of code where the failure occurs is obsolete, right? (the inner try/except/else in useFixture().)

I'll put up a PR in a bit.

Julian Edwards (julian-edwards) wrote :
Changed in testtools:
assignee: Robert Collins (lifeless) → Julian Edwards (julian-edwards)
status: Triaged → In Progress
Julian Edwards (julian-edwards) wrote :

Fixed ages go but not sure if released?

Changed in testtools:
status: In Progress → Fix Committed
Jelmer Vernooij (jelmer) on 2020-03-14
Changed in testtools:
milestone: none → next
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers