Correct directory diffing test and algorithm #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Two steps: 1. TestDiffDirectories did not check if the expected only return value was correct; the intention was there to do so (judging by the comment "change in order"), but my eye for detail failed me. 2. Reversing the directory comparison in the test revealed bugs in the comparison code -- in general, it should skip any directory that is not a directory in the comparator. To make this easier, the code now keeps track of the expected files it saw. That means the check for whether an actual file has an expected counterpart only has two cases, yes or no (rather that trying to account for whether it's a directory and so on). If a directory was skipped while scanning the expected files, it won't be in the actual files anyway. Signed-off-by: Michael Bridgen <mikeb@weave.works>
|
Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Two steps:
TestDiffDirectories did not check if the expected only return value
was correct; the intention was there to do so (judging by the
comment "change in order"), but my eye for detail failed me.
Reversing the directory comparison in the test revealed bugs in the
comparison code -- in general, it should skip any directory that is
not a directory in the comparator.
To make this easier, the code now keeps track of the expected files it
saw. That means the check for whether an actual file has an expected
counterpart only has two cases, yes or no (rather that trying to
account for whether it's a directory and so on). If a directory was
skipped while scanning the expected files, it won't be in the actual
files anyway.