Skip to content

Conversation

@daxian-dbw
Copy link
Member

@daxian-dbw daxian-dbw commented Dec 6, 2017

PR Summary

Close #5627
Update a flaky test that fails intermittently in our CI builds:

[-] Validate running time ' NotNullFunc -Value $byteArray ' 88ms
   Expected {35} to be less than {22}
   at line: 343 in /Users/travis/build/PowerShell/PowerShell/test/powershell/engine/Basic/ValidateAttributes.Tests.ps1
   343:             (Measure-Command $ScriptBlock).Milliseconds | Should BeLessThan $expected

The tests were added along with the fix for the issue #5417. The tests are to validate that we don't check each element of a value-type collection argument.
This fix is to increase the upper bound of the expected time to 200ms, which is still way less than the time it would take before the fix -- more than 2000ms for a byte collection of 28mb in size.

PR Checklist

Note: Please mark anything not applicable to this PR NA.

@daxian-dbw daxian-dbw changed the title Update flaky test Update a flaky test that fails intermittently in CI Dec 6, 2017
Copy link

@anmenaga anmenaga left a comment

Choose a reason for hiding this comment

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

Leave a comment

## The crossgen'ed 'S.M.A.dll' is about 28mb in size, and it would take over 2000ms if we check
## each byte of the array, list or collection. We use 200ms as the upper bound value in tests to
## prove that we don't check each byte.
$UpperBoundTime = 200
Copy link

@anmenaga anmenaga Dec 6, 2017

Choose a reason for hiding this comment

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

Previous implementation used some MandatoryFunc to establish a reasonable baseline with adding some extra time to that.
Can $UpperBoundTime use similar runtime-calculated baseline (and adding something on top of that) rather than a constant?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess I can add back the baseline and add 200 ms to it

Copy link
Collaborator

@JamesWTruher JamesWTruher left a comment

Choose a reason for hiding this comment

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

200ms seems reasonable

@daxian-dbw
Copy link
Member Author

@anmenaga You comment has been addressed. Can you please take another look?

@daxian-dbw
Copy link
Member Author

Thanks all for the review! Since the flaky test could fail in other PR CI runs at any time, I will merge this PR without waiting for 24 hours.

@daxian-dbw daxian-dbw merged commit cc12542 into PowerShell:master Dec 6, 2017
@daxian-dbw daxian-dbw deleted the fixtest branch December 6, 2017 20:46
TravisEz13 pushed a commit to TravisEz13/PowerShell that referenced this pull request Dec 7, 2017
@TravisEz13 TravisEz13 added this to the 6.0.0-RC.2 milestone Dec 8, 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.

Tests for ValidateNotNull, ValidateNotNullOrEmpty are timing sensitive and unreliable.

5 participants