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

Refactor tests on modularized code structure #316

Closed
wants to merge 120 commits into from

Conversation

madmike200590
Copy link
Collaborator

(clone of PR #308)

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 the alpha-solver module since the default implementation of Alpha 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 TODOs in preparation for that refactoring step. (Issue TBD)

lorenzleutgeb and others added 30 commits October 27, 2020 13:06
@AntoniusW AntoniusW changed the title Refactor tests on modulaized code structure Refactor tests on modularized code structure Dec 11, 2021
@AntoniusW
Copy link
Collaborator

@madmike200590 Since you closed the other PR due to a "broken history", I have to ask whether the history we have here is the intended one? It seems to contain all commits from the modularization (again). Is rebasing a good (and easily executable) idea for this branch?

@madmike200590
Copy link
Collaborator Author

@madmike200590 Since you closed the other PR due to a "broken history", I have to ask whether the history we have here is the intended one? It seems to contain all commits from the modularization (again). Is rebasing a good (and easily executable) idea for this branch?

Yes, the history here is the intended one. I closed the other PR because I had some issues getting git to start a proper merge locally - in hindsight, that was mostly my own mistake, but I wanted to make sure that the "shifted" (since modules was merged while #308 was open) base of the PR was not to blame.

As for rebasing, yes, that might be elegant - I tried and reverted it since it's unfortunately not easily executable.

The reason for my merging troubles was that we have one squashed commit for PR #274 in master, while we have the individual commits for the same changes plus commits further modifying the same files here. Since the history git would need to know that the changes from here have to be applied on top of what's in master is not available (because it got squashed), I had to do a huge manual merge.

As for merging this PR, that means I'd like to do a simple merge and keep the history as it is here - otherwise we'll have the same problem with every branch that got branched from modules before merging PR #274. I'll investigate if we can still get rid of "WIP" commits by selectively squashing smaller sets of commits.

@codecov
Copy link

codecov bot commented Dec 11, 2021

Codecov Report

Merging #316 (3cea9cc) into master (fd5e5ba) will increase coverage by 0.87%.
The diff coverage is 64.28%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #316      +/-   ##
============================================
+ Coverage     69.51%   70.38%   +0.87%     
- Complexity     2092     2135      +43     
============================================
  Files           182      182              
  Lines          8006     8016      +10     
  Branches       1416     1417       +1     
============================================
+ Hits           5565     5642      +77     
+ Misses         2086     1996      -90     
- Partials        355      378      +23     
Impacted Files Coverage Δ
...kr/alpha/commons/externals/AspStandardLibrary.java 78.26% <ø> (ø)
...mmons/externals/BinaryPredicateInterpretation.java 0.00% <ø> (ø)
...xternals/BindingMethodPredicateInterpretation.java 11.11% <ø> (ø)
...c/tuwien/kr/alpha/commons/externals/Externals.java 8.57% <ø> (ø)
.../commons/externals/IntPredicateInterpretation.java 50.00% <ø> (ø)
...commons/externals/LongPredicateInterpretation.java 0.00% <ø> (ø)
...mmons/externals/MethodPredicateInterpretation.java 15.78% <ø> (ø)
...s/externals/NonBindingPredicateInterpretation.java 33.33% <ø> (ø)
...ons/externals/SuppliedPredicateInterpretation.java 0.00% <ø> (ø)
...ommons/externals/UnaryPredicateInterpretation.java 0.00% <ø> (ø)
... and 46 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd5e5ba...3cea9cc. Read the comment docs.

@@ -75,7 +75,7 @@
/**
* The new default solver employed in Alpha.
*
* Copyright (c) 2016-2021, the Alpha Team.
* Copyright (c) 2016-2020, the Alpha Team.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
* Copyright (c) 2016-2020, the Alpha Team.
* Copyright (c) 2016-2021, the Alpha Team.

Comment on lines +184 to +185
assertEquals(1, (int)newAssignmentsIterator.next());
assertEquals(2, (int)newAssignmentsIterator.next());
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please revert all changes to this file, it re-introduces compiler warnings that were fixed in master. It seems no other changes (besides the re-shuffling of import statements) were made, and the file could be reverted completely.

@@ -125,7 +126,7 @@ public void parseInterval() {
ASPCore2Program parsedProgram = parser.parse("fact(2..5). p(X) :- q(a, 3 .. X).");
IntervalTerm factInterval = (IntervalTerm) parsedProgram.getFacts().get(0).getTerms().get(0);
assertTrue(factInterval.equals(IntervalTerm.getInstance(Terms.newConstant(2), Terms.newConstant(5))));
IntervalTerm bodyInterval = (IntervalTerm) parsedProgram.getRules().get(0).getBody().stream().findFirst().get().getTerms().get(1);
IntervalTerm bodyInterval = (IntervalTerm) ((Literal) parsedProgram.getRules().get(0).getBody().stream().findFirst().get()).getTerms().get(1);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please revert this file, it re-introduces a compiler warning that was fixed already and no other relevant changes seem to have occurred in this file.

@madmike200590
Copy link
Collaborator Author

Closing this PR due to issues with git history (individual commits of #274 got squashed upon merge), replaced by #335

@madmike200590 madmike200590 deleted the modules-refactor-tests branch February 2, 2022 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants