Skip to content

Enforce unique result in list-fix-paths #687

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -25,9 +25,12 @@
import org.metafacture.framework.annotations.In;
import org.metafacture.framework.annotations.Out;
import org.metafacture.framework.helpers.DefaultStreamPipe;
import org.metafacture.mangling.DuplicateObjectFilter;
import org.metafacture.mangling.StreamFlattener;
import org.metafacture.triples.AbstractTripleSort.Compare;
import org.metafacture.triples.StreamToTriples;
import org.metafacture.triples.TripleFilter;
import org.metafacture.triples.TripleSort;

import java.io.IOException;

Expand All @@ -37,7 +40,7 @@
*
* @author Tobias Bülte
*/
@Description("Finds all paths that have values that match the given pattern. Allows for regex. These paths can be used in a Fix to address fields.")
@Description("Finds all paths that have values that match the given pattern. Allows for regex. These paths can be used in a Fix to address fields.") // checkstyle-disable-line ClassDataAbstractionCoupling
@In(StreamReceiver.class)
@Out(String.class)
@FluxCommand("find-fix-paths")
Expand Down Expand Up @@ -67,11 +70,15 @@ public FindFixPaths(final String objectPattern) {
protected void onSetReceiver() {
final TripleFilter tripleFilter = new TripleFilter();
tripleFilter.setObjectPattern(objectPattern);
final TripleSort tripleSort = new TripleSort();
tripleSort.setBy(Compare.PREDICATE);
fix
.setReceiver(new StreamFlattener())
.setReceiver(new StreamToTriples())
.setReceiver(tripleFilter)
.setReceiver(tripleSort)
.setReceiver(new ObjectTemplate<>("${p}\t|\t${o}"))
.setReceiver(new DuplicateObjectFilter<>())
.setReceiver(getReceiver());
}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -52,14 +52,22 @@ public void testShouldFindPaths() {

private void processRecord() {
finder.setReceiver(receiver);
finder.startRecord("");
finder.startRecord("1");
finder.literal("a", "An ETL test");
finder.literal("b", "");
finder.literal("b", "Dummi");
finder.literal("b", "Dog");
finder.literal("c", "");
finder.literal("c", "ETL what?");
finder.endRecord();
finder.startRecord("2");
finder.literal("a", "An another test");
finder.literal("b", "");
finder.literal("b", "Dummi");
finder.literal("b", "Dog");
finder.literal("c", "");
finder.literal("c", "ETL what?");
finder.endRecord();
finder.closeStream();
}

Expand All @@ -72,7 +80,6 @@ private void verify(final String... result) throws MockitoAssertionError {
}
ordered.verify(receiver, Mockito.times(2)).closeStream();
ordered.verifyNoMoreInteractions();
Mockito.verifyNoMoreInteractions(receiver);
Copy link
Member

Choose a reason for hiding this comment

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

The difference between ordered.verifyNoMoreInteractions() and Mockito.verifyNoMoreInteractions() is explained here. For instance, if someone were to change the test pattern to .*, or worse, change the implementation to this effect, the test would still pass without this check.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, thanks! So the first checks that we get no more interactions at this point, while the second checks that we get no more interactions overall? But then do we actually need the first? The order itself is verified by the ordered.verify() calls, right? And Mockito.verifyNoMoreInteractions() should catch any additional interactions?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I think that's correct. The violations detected by ordered.verifyNoMoreInteractions() should always be a subset of those detected by Mockito.verifyNoMoreInteractions().

The only justification I have for keeping both is that we perform the checks in the order of most specific to least specific. And there might be cases where we expressly want only the former, and not the latter. But I agree that it's not strictly necessary in this case.

There are also historical reasons for introducing the checks in this combination, where a preexisting test would have failed with Mockito.verifyNoMoreInteractions() while still passing with ordered.verifyNoMoreInteractions() (see #341 for details, specifically 78811b7 and e4c6fe5).

In conclusion, I don't mind keeping both, but I wouldn't necessarily object to removing ordered.verifyNoMoreInteractions(), provided that Mockito.verifyNoMoreInteractions() is being used instead.

}
catch (final MockitoAssertionError e) {
System.out.println(Mockito.mockingDetails(receiver).printInvocations());
Expand Down