Skip to content

Quickchecking of domains from my bachelor's thesis#86

Merged
vesalvojdani merged 60 commits intomasterfrom
domaintest
Sep 24, 2020
Merged

Quickchecking of domains from my bachelor's thesis#86
vesalvojdani merged 60 commits intomasterfrom
domaintest

Conversation

@sim642
Copy link
Copy Markdown
Member

@sim642 sim642 commented Jun 17, 2020

Closes #84.

Besides testing lattice properties, there are also properties for testing the validity of integer domain operations as abstraction of sets of integers.

Usage

  • Compiling: make domaintest
  • Running: ./goblint.domaintest.
    See --help for other useful flags provided by qcheck, e.g. -v or --long.

Possible improvements

  • Move arbitrary out of Printable.S. This would separate the testing code from actual functionality. And it might be necessary anyway to use AFL for that purpose instead. Could be hard though because of functors.
  • Move domain testing out of main src directory to maybe unittest. The property tests might integrate with OUnit.

sim642 added 30 commits February 8, 2018 17:46
@sim642 sim642 added the testing label Jun 17, 2020
@sim642 sim642 self-assigned this Jun 17, 2020
@michael-schwarz
Copy link
Copy Markdown
Member

If I run this in its current state, it reports hundreds of errors failure (100 tests failed, 34 tests errored, ran 468 tests).
Is this the expected outcome?

* Integers isn't a lattice.
* Lifted isn't an abstraction of IntegerSet.
@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Jun 17, 2020

That was about right. I pushed a change to remove improper domains (Integers, Lifted) from being tested there because they aren't supposed to pass everything anyway. There's still quite the number of failures:

failure (82 tests failed, 7 tests errored, ran 397 tests)

To see which domains and properties fail it's nicer to use ./goblint.domaintest -v | less -r.

The biggest issues are with circular intervals, DefExc and Enums. I haven't looked into them though. Could also have something to do with the ranges of those.

Copy link
Copy Markdown
Member

@vesalvojdani vesalvojdani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good. This will now run domain tests on the CI, but a lot of the domains are commented out. Please create new ticket for that.

@vesalvojdani vesalvojdani merged commit 08316c5 into master Sep 24, 2020
@vesalvojdani vesalvojdani deleted the domaintest branch September 24, 2020 11:02
@michael-schwarz
Copy link
Copy Markdown
Member

michael-schwarz commented Sep 24, 2020

This will now run domain tests on the CI

This runs the test only in the Github CI and not on Travis, right? Any reasons for that?

@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Sep 24, 2020

The selfish reason is that it was easiest to add to GitHub Actions. You can also add it to the Travis scripts if you want.

This also raises the question of whether we need both CI-s running the same tests and maintaining both, each with its own possible oddities.

@michael-schwarz
Copy link
Copy Markdown
Member

whether we need both CI-s running the same tests and maintaining both

No, having only the Github actions would be fine with me. Anyone sees a reason for keeping Travis around? @vesalvojdani @vogler @jerhard ?

@vogler
Copy link
Copy Markdown
Collaborator

vogler commented Sep 24, 2020

Any CI (there's also this dockercloud) should just have to call ./make.sh testci. The stuff around it is for setup and shouldn't change (OCaml version is set by ./make.sh setup).
I think most of the time Github is faster since the caching is done better there, but for the last commit on master 08316c5, Travis was faster.
The advantage of having multiple CIs is that you can just wait for the first to succeed, and if one of them fails and the others don't, you know it's a problem with this CI service. Disadvantage is potential noise in case the CI service is the problem (I remember having to restart some Travis build and then it worked).

@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Sep 24, 2020

On GitHub Actions I added the domain tests as a separate step so they show up nicely as a separate block. Adding it to testci wouldn't give that. Not sure if anyone really cares though.

@vogler
Copy link
Copy Markdown
Collaborator

vogler commented Sep 24, 2020

No strong opinion. Can we keep the files around and disable all but GitHub Actions? I see Travis as an app that can be disabled, but this docker integration seems to be just picked up from the file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Quickchecking of domains

4 participants