I have/had several tests that took very long to run.

I have no figured out that between 50% and 80% of the time, went into concatenating/formatting the message for "AssertEqual" (and related).
Yes, some of my tests now run in less than 20% of the original time.

That is
- Any concatenation my code does before calling AssertEqual
- The call to ComparisonMsg in AssertEqual

So I started overloading AssertEqual

class procedure TFastTestCase.AssertEquals(const AMessage: string; Expected, Actual: integer);
begin
  if Expected = Actual then exit;
  inherited AssertEquals(AMessage, Expected, Actual);
end;

class procedure TFastTestCase.AssertEquals(const AMessage: string;
  const AFormatArgs: array of const; Expected, Actual: integer);
begin
  if Expected = Actual then exit;
  inherited AssertEquals(Format(AMessage, AFormatArgs), Expected, Actual);
end;

* Yes, I am aware that skips counting the amount of calls. (needs "Inc(AssertCount)" in case of early exit)
* The 2nd version eliminates any call to format in my own code.


I wonder if it is worth adding such changes to the official testcase.

------------------

Or maybe it is just the way I write tests?

E.g. I have a test, that computes lists, it then does

  for i := 0 to count do
    AssertEquals(format('...', [...]), AExp[i], ATestRes[i]);

Additionally those lists are tested in a loop, iterating through big amounts of control parameters for each test-list to be generated.

So I do end up with millions and millions of calls to AssertEqual.
And the same amount of calls to Format and ComparisonMsg, doing string processing.

Some of the time savings happen (and are significant) even when the test runs WITHOUT heaptrc. But, using heaptrc in tests, is something that I commonly do, and string processing often involves mem re-allocs.


_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to