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

test: remove test repetition #1874

Closed
wants to merge 1 commit into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented Jun 2, 2015

The value of j is never used and the value of offset
is never changed. So the loops execute the same tests
multiple times without apparent explanation. (Perhaps it was
originally some kind of crude benchmarking?)

@Fishrock123 Fishrock123 added the test Issues and PRs related to the tests. label Jun 2, 2015
@silverwind
Copy link
Contributor

This iteration seems somewhat intentional, given this change: e014643

cc: @trevnorris

@trevnorris
Copy link
Contributor

I can only infer the intention of this test, as the commit messages tell us nothing. That is, to ensure that writing to a buffer slice many times does not cause it to overrun the internal bounds of the buffer.

/cc @bnoordhuis Have any recollection of why the test was written this way?

@bnoordhuis
Copy link
Member

No specific recollection but I think the general idea is like you say, to shake out subtle memory corruption bugs. Updating the test doesn't bother me but neither does not updating the test.

@jbergstroem
Copy link
Member

FWIW: on armv7 it only seems to take 1.6s with the potentially unnecessary repetition.

@silverwind
Copy link
Contributor

Guess this is a case of 'if it aint broke don't fix it'. The argument about the unused variable is also invalid, as it is used to run the loop itself 😉

@silverwind silverwind closed this Jun 4, 2015
@dcousens
Copy link

dcousens commented Jun 4, 2015

Can we maybe add a comment to the code to explain this then?

@silverwind
Copy link
Contributor

@dcousens Pull Request welcome, no one would object that.

@trevnorris
Copy link
Contributor

I've gone over this in detail, along with the commit where it was originally implemented. I'm fairly confident what these tests were supposed to be doing aren't done correctly.

Since buffer slice operates like array slice it won't throw but instead coerce the bounds values. So need to check if the slice can be taken beyond the bounds of the allocated buffer, and if writing to that slice can write into the parent buffer. Additional tests have been added to check for some of these cases because they have happened. Despite the tests in question here. Demonstrating it didn't accomplish what it was originally intended to do.

Feel free to merge this. Because as they currently stand the reason for how they were implemented is confusing. I'll open another PR with additional tests that I believe were the original intent.

@trevnorris trevnorris reopened this Jun 4, 2015
@Trott
Copy link
Member Author

Trott commented Jun 13, 2015

@trevnorris Are you comfortable enough with this to give it an official LGTM? If so, I'd like to merge it.

@trevnorris
Copy link
Contributor

Go right ahead. LGTM.

The value of `j` is never used and the value of `offset`
is never changed. So the loops executes the same tests
multiple times without apparent explanation. (Perhaps it was
originally some kind of crude benchmarking?)
@Trott
Copy link
Member Author

Trott commented Jun 14, 2015

Jenkins CI for this change: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/838/

Trott added a commit to Trott/io.js that referenced this pull request Jun 14, 2015
Remove loops executing the same tests multiple times.

PR-URL: nodejs#1874
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@Trott
Copy link
Member Author

Trott commented Jun 14, 2015

Merged in 88d7904

@Trott Trott closed this Jun 14, 2015
@rvagg rvagg mentioned this pull request Jun 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants