Closed FilipJanitor closed 6 years ago
This makes sense. We could have this in a test utils function. Also we should also add one for checking the left side too for if there are parsing errors.
That is the question we mentioned in #431 too - what should actually be tested when we expect failure. Simply check if failure occured? Do we want to check for specific failure? Because if not, we can use the hack I used in CommandLineUtilsTest - simply wrap the result in some structure and by this we can reuse the test function even for failing tests.
I think all errors we check should ensure the error occurs on a particular line/column at least using ParseError
. This will help us a lot as otherwise we may miss big issues where error messages aren't being displayed when they should be. We need to try being as precise as possible.
There's one problem with this. The testParseSuccess
function I've added is now in a parser test utils module. If an error occurs with a parser it outputs the code that was being parsed and the error message.
We need to know where the error actually occurred. Currently it just says it occurred in the module where testParseSuccess
exists. We need it to instead specify the testing module instead.
E.g
100.50988678f - TrivialError (SourcePos {sourceName = "", sourceLine = Pos 1, sourceColumn = Pos 1} :| []) (Just (Tokens ('1' :| ""))) (fromList [Tokens ('f' :| "")])
CallStack (from HasCallStack):
error, called at test/tests\TestUtil\ParserTestUtil.hs:12:20 in main:TestUtil.ParserTestUtil
This is good in that it gives us the error but without looking it up we don't know which specific test caused this. I wonder if we can get the whole stack trace.
Some tests contain a lot of duplicated code.
This might be possibly rewritten to something like