Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control of Assertion Level when running tests #527

Open
stevelinton opened this issue Jan 22, 2016 · 5 comments
Open

Control of Assertion Level when running tests #527

stevelinton opened this issue Jan 22, 2016 · 5 comments
Assignees
Labels
gapsagedays2016 Issues and PRs that arose at https://www.gapdays.de/gap-sage-days2016 kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: tests issues or PRs related to tests

Comments

@stevelinton
Copy link
Contributor

It would be nice to be able to set the assertion level via an option in Test and TestDirectory. Level 0 makes it a more reasonable benchmark and lower levels might help tests run faster (for instance in continuous integration or git bisect).

It is also theoretically possible to have a bug that only shows up at lower assertion levels (when an assertion has side-effects that the code actually depends on).

This arises from issue #524

@olexandr-konovalov olexandr-konovalov added gapsagedays2016 Issues and PRs that arose at https://www.gapdays.de/gap-sage-days2016 topic: tests issues or PRs related to tests labels Jan 22, 2016
@fingolfin
Copy link
Member

Fully agreed.

And somewhat orthogonal to this: I can remember several instances where I tried to manually debug a test failure, then couldn't reproduce it -- and only after some time realized that I forgot to increment the assertion level, which was needed to reproduce the bug.
So, perhaps we can print the used assertion level when we start running the tests? E.g. "Running tests at assertion level 2"

@frankluebeck
Copy link
Member

The change of the assertion level and printing of GAP stones and resetting of the main random source are not done by Test but by the START_TEST and STOP_TEST functions.

I never understood why the assertion level is changed by these functions at all. Shouldn't the frequent tests for correct functionality and runtime regressions be made in the state which most GAP users will use?

If one would remove the change of the assertion level from these functions one could still easily run all tests with higher assertion level (i.e., change the level and then run all tests) occasionally.

@stevelinton
Copy link
Contributor Author

I have a very vague memory of this being added, and of someone having a reason, but it was probably last century and I don't recall exactly why it was done or by whom. Possibly to detect broken code IN Assert statements.

Anyway I support Frank's proposal.

@olexandr-konovalov olexandr-konovalov added this to the GAP 4.9.0 milestone Mar 11, 2017
@olexandr-konovalov olexandr-konovalov self-assigned this Mar 16, 2017
@fingolfin fingolfin added the kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements label May 9, 2017
@fingolfin
Copy link
Member

One reason why one might want to run the tests at a high assertion level is because this way, one may catch more bugs by running the tests -- bugs which might not be easily noticed w/o an assertion catching them.

@fingolfin
Copy link
Member

While this would be nice to have, I don't think it's mandatory for 4.9.0, hence I just removed the milestone. Perhaps we can try to get this into 4.10.0.

@olexandr-konovalov olexandr-konovalov added this to the GAP 4.10.0 milestone Nov 8, 2017
@fingolfin fingolfin modified the milestones: GAP 4.10.0, GAP 4.11 Sep 28, 2018
@fingolfin fingolfin removed this from the GAP 4.11 milestone Mar 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gapsagedays2016 Issues and PRs that arose at https://www.gapdays.de/gap-sage-days2016 kind: enhancement Label for issues suggesting enhancements; and for pull requests implementing enhancements topic: tests issues or PRs related to tests
Projects
None yet
Development

No branches or pull requests

4 participants