Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(clone of PR #316, re-creating in order to fix git history that got messed up after squashing modularization commits during merge of #274)
This PR is a follow-up to PR #274. Following the changes to the overall code structure and API introduced through modularization, I took the opportunity to get started on some refactorings of Alphas unit tests.
Specifically, this PR aims to
Reduce dependencies and narrow down tested code for unit tests
In order to make our unit tests more precise and avoid localized errors failing lots of tests, I removed unnecessary dependencies from most tests. Especially, we don't want to have tests of core components like gronder and solver depend on the complete program preprocessing workflow including parser and rewritings.
Move functional tests to alpha-solver module
Most tests that test rewriting and preprocessing features, as well as all tests that just pass programs into an
Alpha
instance and verify returned answer sets should be considered functional tests rather than unit tests since they test complete features through the complete workflow. These were moved into thealpha-solver
module since the default implementation ofAlpha
resides there.Mark functional and integration tests for further attention
In order to improve build performance and better distinguish between unit-, integration-, functional- and performance-tests, these should be separated into separate tasks in the build (of which some should probably only run in CI) process.
This has not yet been realized yet, but tests that should probably be treated as integration tests or functional tests were marked with appropriate
TODO
s in preparation for that refactoring step. (Issue TBD)