I'm working in PyCharm 3.0.2 using WinPython 2.7.5.3 when running my unit test in debug mode all of them are passing. However if I run them normally I have one that fails - specifically the result of the code below returns an extra unexpected item in the result list.
This is the failed test:
def test4(self):
bz = BezNet()
bz.insert([P(1, 1), P(2, 3)])
bz.insert([P(1, 10), P(2, 30)])
nodes = [n for n in bz.nodes]
self.assertEqual(len(nodes), 4)
edges = [e for e in bz.edges]
self.assertEqual(len(edges), 2)
bbzz = bz.separate()
self.assertEqual(len(bbzz), 2) # assertioin fails (len==3) but ONLY in run mode
This is an excerpt of the part of the class BezNet being tested.
....
def _visit(self, a, nodes, edges):
if a in nodes:
return None
for b in a._out:
edges[a, b] = self._edges[a, b]
self._visit(b, nodes, edges)
nodes.add(a)
def separate(self):
result = []
while len(self._nodes):
nodes = set()
edges = {}
for x in self._nodes:
start = x
break
self._visit(start, nodes, edges)
part = BezNet()
part._nodes = nodes
self._nodes.difference_update(nodes)
part._edges = edges
for e in edges:
del self._edges[e]
result.append(part)
return result
....
The rest of the class is rather large so I won't include it here unless someone thinks it could be at fault in which case I will edit. [I'm not looking for a solution to the bug in my code yet, just how to go about tracking it when the tools are playing up]
My question is what could be happening under the hood to be causing this and what strategies one could use to go about tracing the problem?
In this particular circumstance the Heisenbug was due to the arbitrary ordering when the set type is iterated which happens to be repeatable but different between run and debug modes see this discussion... My bad.
In the end the solution came from copious print statements and waiting for that flash of inspiration of what documentation to double check.