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

Bug #1469759 reported by Jakub Libosvar
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
testtools
Fix Released
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

Revision history for this message
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)
Revision history for this message
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)
Changed in testtools:
milestone: 1.8.1 → none
Revision history for this message
Jonathan Lange (jml) wrote :

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

Revision history for this message
Julian Edwards (julian-edwards) wrote :

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

Revision history for this message
Robert Collins (lifeless) wrote :

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

Revision history for this message
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.

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

Fixed ages go but not sure if released?

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.