-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
More Parse tests for double, single and Half #50394
Conversation
Tagging subscribers to this area: @tannergooding, @pgovind Issue DetailsFixes a part of #48119 (specifically point 5 in that issue: More nuanced floating point numbers that involve trailing zeros, rounding and precision concerns.)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect so, but it's worth asking: do these tests impact build/test times noticeably? It's a lot of scenarios being tested.
return new string(charArray); | ||
} | ||
|
||
[Fact] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I often advise against having Assert
inside a loop as the test will then just fail at the first occurrence instead of showing how many cases are affected. This might be a good candidate for using [ClassData]
to dynamically test all of the loaded scenarios. You could then have the data in a convenient structure too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will consider this on my next pass through here. I actually tried putting the data from ibm-fpgen.txt into a static class to call with ClassData
like you suggest, but VS turned out to be so sluggish once the file got big that it was impossible to work on that file. I'm wondering if design time build in VS was the culprit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha - I bet. You could also just have a class that reads the data from the text file and loads it into a well-formed structure though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could do
[Theory]
[MemberData(nameof(ParsePattern_TestData))]
with
public static IEnumerable<object[]> ParsePattern_TestData()
{
string path = Directory.GetCurrentDirectory();
using (FileStream file = new FileStream(Path.Combine(path, "NumericsTestData", "ibm-fpgen.txt"), FileMode.Open))
{
// logic
yield return doubleBytes;
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I too was trying to suggest something like that where the data remains in a text file (not intended to be opened in Visual Studio), but that was loaded into a class/member instead of parsed as part of the test itself. It's OK with me to have that done in a follow-up PR though.
I had the same thought too. As it turns out, it only takes ~1s to execute all 3 tests. |
@@ -272,6 +272,9 @@ | |||
<Compile Include="$(CommonTestPath)System\Runtime\Serialization\Formatters\BinaryFormatterHelpers.cs" | |||
Link="Common\System\Runtime\Serialization\Formatters\BinaryFormatterHelpers.cs" /> | |||
</ItemGroup> | |||
<ItemGroup> | |||
<None Include="NumericsTestData\ibm-fpgen.txt" CopyToOutputDirectory="Always" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we ok with checking in test data like this? Or ss there an existing way to add test data like I'm doing here? I don't see a "CommonTestData" or something similar in the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we generally use https:/dotnet/runtime-assets for larger data. As its a test only change, we can remove it next preview if need be
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on how large the test data is? If it's less than 500KB I would say, check it in. If larger I would recommend to check it into https:/dotnet/runtime-assets. Note that this isn't reversible as the BLOB will stay in the git history of the repo forever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah perfect, the 500kb guideline was what I was looking for. Thanks! Will push this to runtime-assets first then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's less a guideline but more a recommendation from my side. It also depends on how git versions the file as it treats text files vs binary blobs differently.
180ac83
to
a2d686d
Compare
At some point, @pgovind, I saw you had a commit that used |
Indeed. With [MemberData], I had the following problem: [MemberData(nameof(MethodThatYieldedData))]
public void DoubleParseTest () { actual test }
[MemberData(nameof(MethodThatYieldedData))]
public void SingleParseTest () { actual test }
[MemberData(nameof(MethodThatYieldedData))]
public void HalfParseTest () { actual test }
public static void MethodThatYieldedData
{
Code that opens the input file and yields data
} The tests would fail because all 3 *ParseTest methods would try to open the file and only 1 of them would succeed. The other 2 would fail because the file was already open. So I just moved everything to a single test for now. On my next pass through here, I will split them out to 3 different tests. |
Ah, gotcha; thanks. You'd probably need to move the file parsing into the test class constructor then, which is treated as a setup method and should only execute once. |
Just adding a note for myself that this PR should go in as 2 pieces of work:
|
6fd2bec
to
23d6469
Compare
23d6469
to
1be977d
Compare
@@ -282,6 +282,7 @@ | |||
</ItemGroup> | |||
<ItemGroup> | |||
<PackageReference Include="Moq" Version="$(MoqVersion)" /> | |||
<PackageReference Include="System.Runtime.Numerics.TestData" Version="$(SystemRuntimeNumericsTestDataVersion)" GeneratePathProperty="true"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity, what does the GeneratePathProperty
do? @safern
Alright, I updated this branch to use the assets produced by https:/dotnet/runtime-assets/pull/143/files. There were no other changes here, so I'm just going to re-use the prior approvals I already had. Just calling it out for @jeffhandley and @tannergooding. I'll merge if CI is green. I don't expect any new comments, but there are any, I'll address it in a follow up PR. |
Hello @pgovind! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
@@ -214,5 +214,9 @@ | |||
<Uri>https:/dotnet/hotreload-utils</Uri> | |||
<Sha>25b814e010cd4796cedfbcce72a274c26928f496</Sha> | |||
</Dependency> | |||
<Dependency Name="System.Runtime.Numerics.TestData" Version="6.0.0-beta.21314.1"> | |||
<Uri>https:/dotnet/runtime-assets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to let you know, this broke dependency flow as you were missing the </Uri>
element. I'm fixing this in #54511.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry my bad. Thanks for fixing it!
This test is failing on big-endian systems, see #54818 for a fix. Thanks! |
Fixes a part of #48119 (specifically point 5 in that issue: More nuanced floating point numbers that involve trailing zeros, rounding and precision concerns.)