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

binary-search: add json test data #349

Merged
merged 1 commit into from
Aug 30, 2016
Merged

binary-search: add json test data #349

merged 1 commit into from
Aug 30, 2016

Conversation

junedev
Copy link
Member

@junedev junedev commented Aug 18, 2016

Following the instructions proposed by @IanWhitney in #230, I created the missing json file with the test data for binary-search. Once this is merged https://github.com/exercism/todo/issues/73 can be closed.

There are two open issues regarding the exercise:
#234 - Following (and agreeing with) the majority there I did not include checking for sorted input. I also included a respective comment in the json file. The issue can be closed once the new test data is propagated through the tracks.
#244 - I included a comment with the summary of what was discussed there but the issue seems only partly addressed by this as there are additional ideas on how/where to address the issue.

},
{
"description": "finds a value in the middle of an array of odd length",
"array": [1, 3, 5, 8, 13, 34, 34, 55, 89, 144, 233, 377, 634],
Copy link
Contributor

Choose a reason for hiding this comment

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

Should there be 2 34's here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, this test will fail if someone just starts at the beginning of the array and returns the index on the first occurrence of the value that should be searched.

Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds like it should be a separate test case.

  • 'find value in the middle of an array of odd length'
  • 'find correct value for duplicated element'

Copy link
Contributor

Choose a reason for hiding this comment

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

Also you probably need test cases for when the 'correct' duplicated element is the first element as well so you can't fake it by reversing the list or taking the highest index or some other similar workaround.

Copy link
Contributor

Choose a reason for hiding this comment

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

(I suggest that none of the test arrays should have duplicate elements.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I am a bit confused here @Insti . First you explained how to add more test cases that check the binary search is done somewhat correctly, then you said in brackets (?) that we should not do this.

Maybe you can clarify and explain a bit why you would not add these kind of tests.
My thinking was that since most languages don't easily allow counting the number of times the array is accessed this would be an easy chance to avoid that some implementations that do no binary search at all pass all the test.
You are definitely right on the separate test case(s) though.

Copy link
Contributor

@Insti Insti Aug 19, 2016

Choose a reason for hiding this comment

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

If there are duplicate elements, the minimal case is: [ 1, 1 ] Is the correct answer 0 or 1?
(If 0, why is rounding up wrong and rounding down right?)

Testing implementation details can be tricky.

IF you do want to test implementation, then test it directly and assert that the algorithm is being implemented correctly by doing something like adding a 'depth' parameter, or asking for the array result after a certain number of iterations.

The simplest thing to do is make sure the test arrays are sorted and only contain unique values, and rely on the reviewers to call out incorrect algorithms. This is the method used in many other exercises. (And would be my preferred method.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for taking the time to explain. I nobody else votes in favour of keeping it, I will change it to use only unique values. I might not have a chance to update the PR before the weekend. But maybe other points will come up and I can change it all together next week.

Copy link
Member

Choose a reason for hiding this comment

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

That's a really great observation, @Insti - I second the change to use only unique values.

Copy link
Member Author

Choose a reason for hiding this comment

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

PR is updated to use only unique values

@Insti
Copy link
Contributor

Insti commented Aug 21, 2016

There probably should be a test for an even length array.
Did you base this file on existing tests from one of the tracks that already implement the problem?

@junedev
Copy link
Member Author

junedev commented Aug 21, 2016

Unfortunately the test sets in the different tracks were very divers for this problem and I couldn't find a single one that was just right to use it directly for the json file. So I build up the content with inspiration/parts from different tracks.
Sorry for missing the even length part, I was pretty sure I included it already. PR updated accordingly.

@Insti
Copy link
Contributor

Insti commented Aug 21, 2016

No problem @junedev, all your work on this is much appreciated!

@petertseng
Copy link
Member

We good with these? I think the only potential additions I would have are

  • searching for a value smaller than the array's smallest value
  • searching for a value larger than the array's largest value

These seem like separate cases than the existing, so could be useful. If you agree, add them and I think that will be that. If you think they aren't (and can explain to me) I think I'd take what's here as is.

@junedev
Copy link
Member Author

junedev commented Aug 24, 2016

@petertseng I like the additional test cases. I will update the PR accordingly. - Done.

@ErikSchierboom
Copy link
Member

@petertseng Is this ready to be merged?

@petertseng
Copy link
Member

I say yes!

@ErikSchierboom ErikSchierboom merged commit 176a61a into exercism:master Aug 30, 2016
@ErikSchierboom
Copy link
Member

Merged! 🎉

@junedev junedev deleted the binary_search_json_data branch August 30, 2016 17:48
emcoding pushed a commit that referenced this pull request Nov 19, 2018
Add a Gitter chat badge to README.md
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.

5 participants