<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am So., 2. Sep. 2018 um 20:05 Uhr schrieb Rodrigo Stevaux <<a href="mailto:roehst@gmail.com">roehst@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Omer, thanks for the reply. The tests you run are for regression testing, that is, non-functional aspects, is my understanding right? [...]</div></blockquote><div><br></div><div>Quite the opposite, the usual steps are:</div><div><br></div><div>   * A bug is reported.</div><div>   * A regression test is added to GHC's test suite, reproducing the bug (<a href="https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding">https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding</a>).</div><div>   * The bug is fixed.</div><div><br></div><div>This way it is made sure that the bug doesn't come back later. Do this for a few decades, and you have a very comprehensive test suite for functional aspects. :-) The reasoning behind this: Blindly adding tests is wasted effort most of time, because this way you often test things which only very rarely break: Bugs OTOH hint you very concretely at problematic/tricky/complicated parts of your SW.</div><div><br></div><div>Catching increases in runtime/memory consumption is a slightly different story, because you have to come up with "typical" scenarios to make useful comparisons. You can have synthetic scenarios for very specific parts of the compiler, too, like pattern matching with tons of constructors, or using gigantic literals, or type checking deeply nested tricky things, etc., but I am not sure if such things are usually called "regression tests".</div><div><br></div><div>Cheers,</div><div>   S.</div><div><br></div><div><br></div></div></div></div>