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

Refactored error checking tests. Fixes #71 #72

Merged
merged 1 commit into from
Apr 9, 2017
Merged

Conversation

maksimov
Copy link
Contributor

@maksimov maksimov commented Dec 5, 2016

No description provided.

@maksimov
Copy link
Contributor Author

maksimov commented Dec 5, 2016

Yikes, looks like the OSX build is a bit sick. Cannot start for the whole ten minutes, can't be a good sign.

@zimmski
Copy link
Collaborator

zimmski commented Dec 5, 2016

Give it time https://www.traviscistatus.com/

Copy link
Collaborator

@zimmski zimmski left a comment

Choose a reason for hiding this comment

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

This looks pretty good, I just have some small requests.

Also, it looks like I have overlooked to refactor this test function. Would you mind refactoring the non-error cases into a table-driven pattern too? If not, I would just open an issue for it.

@@ -998,8 +998,38 @@ func TestDiffText(t *testing.T) {
}

func TestDiffDelta(t *testing.T) {

Copy link
Collaborator

Choose a reason for hiding this comment

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

Remove this empty line

@@ -998,8 +998,38 @@ func TestDiffText(t *testing.T) {
}

func TestDiffDelta(t *testing.T) {

type TestCase struct {
Text string
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please add a "Name" field too and use the comments for the test case values. You can pretty much copy the pattern (e.g. for the error messages for the asserts) for that from other test functions.

type TestCase struct {
Text string
Delta string
ErrorMessagePrefix string
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since ErrorMessagePrefix is part of the expected members please add a new line before the field. That is just the style of the other test functions.

{"", "--1", "Negative number in DiffFromDelta: -1"},
{"", "", ""},
} {
_, err := dmp.DiffFromDelta(tc.Text, tc.Delta)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please test the first return argument too, it should be always nil because all cases have an error.

{"", "a", "Invalid diff operation in DiffFromDelta: a"},
{"", "-", "strconv.ParseInt: parsing \"\": invalid syntax"},
{"", "--1", "Negative number in DiffFromDelta: -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 remove the empty case from the list, since it is not an error case. Just put it back below. You can then also remove the condition for the empty ErrorMessagePrefix below

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While I agree with the rest of your comments, I'm struggling with this one. Initially I went without the empty case, but then I saw that it fits the pattern, and a similar case is handled similarly in patch_test.go so I decided to move it in. I think the idea here is that checking for absence of error is also error checking, the other thing is the refactoring to avoid duplication.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree on what you wrote. The absence of an error must be checked, of course. However, the linked test function handles both error and non-error cases, and I just went with your comment "Error checking" which suggested you wanted to verify only negative cases. As I mentioned in my other commit, it seems that I forgot to refactor this function with the table-driven pattern. I would therefore suggest to drop the "Error checking" comment, and try to put the other cases into the table-driven pattern too. What do you think?

@maksimov
Copy link
Contributor Author

maksimov commented Dec 8, 2016

I've looked at refactoring the other cases, but they all seem to have significant amounts of input data which is initialised differently on a case-by-case basis. I felt that refactoring these into the table pattern could make the actual table look very bulky and unpleasant. Please advise.

@zimmski
Copy link
Collaborator

zimmski commented Dec 12, 2016

Yeah, I did not find a good solution either. Have to ponder a bit more but let's merge your PR. It looks really good and its a great improvement! Just one small thing: Please squash the two commits

@maksimov
Copy link
Contributor Author

I'm probably dumb, but I think I've now ended up with four commits instead of two as previously, but at least the changes are now combined into a single commit 1e4b8b1. I don't really know how to go around this.

@maksimov
Copy link
Contributor Author

@zimmski do you want to merge this? or is there anything else i can do to improve it?

@maksimov
Copy link
Contributor Author

@zimmski Ping!

@zimmski
Copy link
Collaborator

zimmski commented Mar 14, 2017

Pong!

@zimmski
Copy link
Collaborator

zimmski commented Mar 14, 2017

This PR still looks good to me. The only thing that is left is squashing the commits together. Take a look at this http://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git

@zimmski
Copy link
Collaborator

zimmski commented Mar 14, 2017

Basically you have to do the following:

  • git rebase --interactive d905c6a268459604358f87a2d10a7a79903a4d26^ which starts a rebase from your first commit onward.
  • Then an editor opens where you can tell Git what you want to happen for reach commit. I suggest you simply use "fixup" for the other commits. Which squashes the commit which is marked with "fixup" into the previous commit.
  • Solve all conflics
  • Force push the branch since you overwrote commits

I could do that myself and upload a new version of the PR with the commit in your name, but I think if you not too familiar with using Git's rebase functionality this would be a good training example. So if you want to let me do it, just tell me, I am also happy to help you out with the rebase. No problem :-)

Code-review changes, update to an incorrectly worded error message
@maksimov
Copy link
Contributor Author

maksimov commented Apr 3, 2017

Finally, all done! Travis also picked up a bug occurring with 1.6.4 which I fixed as well.
Thanks for your help

@maksimov
Copy link
Contributor Author

maksimov commented Apr 8, 2017

Ping @zimmski!

@zimmski
Copy link
Collaborator

zimmski commented Apr 9, 2017

I wished you had put that fix in another commit, but I'll take a look at the change and then merge. Sorry for taking ages. Extremely busy :-(

@zimmski
Copy link
Collaborator

zimmski commented Apr 9, 2017

I am running with Go 1.6.4, I cannot reproduce the problem of https://travis-ci.org/sergi/go-diff/jobs/218036777

@zimmski
Copy link
Collaborator

zimmski commented Apr 9, 2017

However, the change looks good to me.

@zimmski zimmski merged commit 77f9d90 into sergi:master Apr 9, 2017
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.

2 participants