- Notifications
You must be signed in to change notification settings - Fork 73
Open
Labels
enhancementNew feature or requestNew feature or request
Description
This would be nice-to-have, so I might take it on myself, but I'd be curious what you think about some nicer test output. I still have to form an opinion on how it should look like, but I think the existing one, in the case of compile_failure is relatively noisy and not super helpful. At least it does the most important thing and refer to the file:
Traceback (most recent call last): File "/Users/mn/code/writing-ccompiler/writing-a-c-compiler-tests/test_framework/basic.py", line 586, in test_invalid self.compile_failure(program) File "/Users/mn/code/writing-ccompiler/writing-a-c-compiler-tests/test_framework/basic.py", line 340, in compile_failure with self.assertRaises( AssertionError: Didn't catch error in /Users/mn/code/writing-ccompiler/writing-a-c-compiler-tests/tests/chapter_1/invalid_parse/unclosed_paren.cI think it could improved as follows:
- the assertion error traceback isn't important to the user of the testsuite as it doesn't point to an interesting place. Maybe catching it and repackaging it could be a way to make it less noisy?
- also I personally would find a relative path that contains the more relevant bits more readable. In this case
chapter_1/invalid_parse/unclosed_paren.c. Here I'm assuming the user doesn't have multiple copies of testsuites. Upside of the absolute path is that you can copy it into any other place without having to worry where it is. - I'm not sure if that's too much output, it could be a flag for the testsuite, but I imagine it could also be helpful to print the content of the invalid file?
What do you think about this in general?
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request