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.

Sign up for GitHub

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

Jump to bottom

Fix some non-determinism in tests #18675

Merged
merged 1 commit into from
Oct 31, 2019
Merged

Fix some non-determinism in tests #18675

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion test/EFCore.Specification.Tests/Query/GroupByQueryTestBase.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -258,7 +258,7 @@ public virtual Task GroupBy_aggregate_projecting_conditional_expression(bool isA
ss => ss.Set<Order>().GroupBy(o => o.OrderDate).Select(
g =>
new { g.Key, SomeValue = g.Count() == 0 ? 1 : g.Sum(o => o.OrderID % 2 == 0 ? 1 : 0) / g.Count() }),
e => e.SomeValue);
Copy link
Member

Choose a reason for hiding this comment

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

@maumar may have better idea on what should be element sorter here. May be combination of Key + SomeValue could be unique and gives us stable ordering.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, that could also work. I'm not sure I understand when we want to assert order and when we don't care - in this test AFAICT ordering doesn't seem to be important (but no problem to add).

Copy link
Member

Choose a reason for hiding this comment

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

If there is no element sorter we do contains match if expected result appear in actual results. It has slight case of incorrect result when there are duplication. So @maumar added element sorters. When element sorter is specified, both results (expected/actual) are sorted using that and then element by element match. So you want unique deterministic ordering in element sorter. We also have built-in element sorters for our entityTypes so you don't have to specify always.

Copy link
Contributor

Choose a reason for hiding this comment

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

in case of anonymous types i usually order by tuple of the properties:
e => (e.Key, e.SomeValue), if that's still not deterministic then removing elementSorter is fine

Copy link
Member Author

Choose a reason for hiding this comment

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

Looks good, the tuple makes the test pass on PG, thanks!

e => (e.Key, e.SomeValue));
}

[ConditionalTheory]
Expand Down Expand Up @@ -1948,8 +1948,10 @@ public virtual Task GroupBy_with_order_by_skip_and_another_order_by(bool isAsync
isAsync,
ss => ss.Set<Order>()
.OrderBy(o => o.CustomerID)
.ThenBy(o => o.OrderID)
.Skip(80)
.OrderBy(o => o.CustomerID)
.ThenBy(o => o.OrderID)
smitpatel marked this conversation as resolved.
Show resolved Hide resolved
.GroupBy(o => o.CustomerID)
.Select(g => g.Sum(o => o.OrderID))
);
Expand Down
2 changes: 1 addition & 1 deletion test/EFCore.SqlServer.FunctionalTests/Query/GroupByQuerySqlServerTest.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2110,7 +2110,7 @@ SELECT SUM([t].[OrderID])
FROM (
SELECT [o].[OrderID], [o].[CustomerID], [o].[EmployeeID], [o].[OrderDate]
FROM [Orders] AS [o]
ORDER BY [o].[CustomerID]
ORDER BY [o].[CustomerID], [o].[OrderID]
OFFSET @__p_0 ROWS
) AS [t]
GROUP BY [t].[CustomerID]");
Expand Down