Exceptions when long messages are passed in Assert

[Lübbe Onken]

I have noticed that I get non-debuggable exceptions, probably from TestInsight, when I pass "lengthy" messages in an Assert statement like the following:

Assert.AreEqual(Expected, FFileCollector.Files.Count, 'Files' + FileCollector.Files.ToString);

"ToString" in this case can result in a message with > 10K characters. The Exceptions don't happen when I limit the length of the result string. Empirical data indicates that the limit seems to be around 1800-1900 characters in ToString plus the "Expected X but got Y" + "Files" added by DUnitX itself.

Is there a limit on the length of messages that can be passed? If yes, please handle it properly and document it.

Running under XE2, DUnitX (current from GitHub) and TestInsight 1.1.2.0

[Stefan Glienke]

Where are the exceptions occuring? In the test process or in the IDE? If in the IDE then please use madExcept or a similar tool to get me some more information.

[Lübbe Onken]

The exceptions are occuring in the test process, not in the IDE.

I'm getting closer. It probably doesn't have anything to do with the length of the assert message. Maybe only indirectly because of the time needed to transfer the data?

1. It has to do with multi-threading
2. It somehow has to do with TestInsight

###Multi-threading: I'm using AsyncCalls/AsyncHelper to kick off searches for files/patterns in different paths at the same time. One task per file/pattern. Each task works on its own set of data. Only after all taks are finished, the results are checked. If I comment out the asynccalls and run one job after the other -> no exceptions. I'm adding the unit tests to a class that is running fine for years (which of course doesn't prove anything), because I need to refactor it.

###TestInsight: The exceptions only occur in the test process when I run it from TestInsight. When I run it from the debugger via F9 there are none and the tests just fail/succeed.

When I use the DUnitX console runner instead of TestInsight, there are also no exceptions.

[Lübbe Onken]

There was indeed an error in the multi-threading part. After I fixed this, the tests didn't throw exceptions anymore when running under FixInsight. The interesting thing for me is that they only surfaced, when long strings were passed to FixInsight. I reckon that this somehow increased the possibillity of the error occuring.