Unittest error message failure context lazy creation

Hi all, while using `unittest` I see the pattern of creating an error message with the test context for the case that some `assert...` methods fails (to get a good error message). On the lines: class Test...(unittest.TestCase): longMessage = True def test_(self): ... for a, b, c ... in zip(A, B, C, ..): * call the function under test and get the result msg = "Some headline: {}{} ...".format(a, b, c,..) self.assert...( ,msg) The `msg` is just used in case the assert fails but its creation takes time and adds up. What is the best practice/pattern you use here? Or, are there ideas to have a lazy mechanism to avoid that creation and just infer them in the case the assert failed? Thanks in advance! --francis

On Sat, Aug 26, 2017 at 08:25:41PM +0200, francismb wrote:
I think the best practice here is: The Rules of Optimization are simple. Rule 1: Don’t do it. Rule 2 (for experts only): Don’t do it yet. -- Michael A. Jackson, "Principles of Program Design" Personally, I doubt that the time creating the error message will be anything more than an insignificant fraction of the total time. Perhaps as much as 0.1% of the total time? But I've just plucked that number out of thin air, so it's probably wrong. If you want to profile unittest and see just how much time is spent creating error messages for tests which pass, go right ahead and I'll be happy to be proven wrong. Until somebody actually profiles the tests, and demonstrates that delaying creating of the error messages has the potential to speed up unit testing by, oh, at least 5%, I'm sticking with "don't do it yet". -- Steve

Hi Chris, Hi Steven,
I already follow that rules and measure first ;-) and yes may be I have had to formulate the question in a more general way: What is the current status quo for lazy evaluation in the language or the current ideas to avoid this type of cases? Why should one calculate something that is in not going to be needed? Is there a possibility to "mark somehow" a calculation + context to tell the interpreter: "not now" ? the only thing that comes in mind to me is to create some class that captures it and later on the `__str__` method does the calculation for that case, but of course it makes the situation just more complex. Thanks for your feedback! --francis

On Sat, Aug 26, 2017 at 08:25:41PM +0200, francismb wrote:
I think the best practice here is: The Rules of Optimization are simple. Rule 1: Don’t do it. Rule 2 (for experts only): Don’t do it yet. -- Michael A. Jackson, "Principles of Program Design" Personally, I doubt that the time creating the error message will be anything more than an insignificant fraction of the total time. Perhaps as much as 0.1% of the total time? But I've just plucked that number out of thin air, so it's probably wrong. If you want to profile unittest and see just how much time is spent creating error messages for tests which pass, go right ahead and I'll be happy to be proven wrong. Until somebody actually profiles the tests, and demonstrates that delaying creating of the error messages has the potential to speed up unit testing by, oh, at least 5%, I'm sticking with "don't do it yet". -- Steve

Hi Chris, Hi Steven,
I already follow that rules and measure first ;-) and yes may be I have had to formulate the question in a more general way: What is the current status quo for lazy evaluation in the language or the current ideas to avoid this type of cases? Why should one calculate something that is in not going to be needed? Is there a possibility to "mark somehow" a calculation + context to tell the interpreter: "not now" ? the only thing that comes in mind to me is to create some class that captures it and later on the `__str__` method does the calculation for that case, but of course it makes the situation just more complex. Thanks for your feedback! --francis
participants (3)
-
Chris Angelico
-
francismb
-
Steven D'Aprano