At some point during the leaderboard data refactor, this test scene
became completely unusable. This change rewrites it to use
`SoloGameplayLeaderboardProvider` to be able to witness the user score
being resorted and advancing through the leaderboard.
I'd have preferred a `get; init;` property but tests were also attached
at the hip to the public bindable. Without some extra composition this
is the best that I can do.
The sorting logic is now exercised in
`TestSceneSoloGameplayLeaderboardProvider`. Trying to work around
it with local test classes would mean that the test would be covering
test code, i.e. complete nonsense and having a green test for the sake
of having a green test.
Intends to close https://github.com/ppy/osu/issues/32859.
The difference between this and https://github.com/ppy/osu/pull/32942 is
that this PR takes the approach of completely moving the score sorting
behaviour to `IGameplayLeaderboardProvider` implementations.
This is going to be helpful for further work - to be precise, I am
looking to add a leaderboard position indicator in the bottom right of
multiplayer player to match stable, and having the position in the
provider will make the implementation of that *much* easier.
This is a prerequisite for supporting skinning of leaderboards.
- New `IGameplayLeaderboardProvider` and `IGameplayLeaderboardScore`
interfaces are introduced. They are strictly concerned with supplying
leaderboard data.
- Logic of managing display, which was previously jammed into the
inheritance hierarchy of `GameplayLeaderboard`, is now moved into
`IGameplayLeaderboardProvider` implementations. Solo play,
multiplayer, and multiplayer spectator get their own implementation of
the interface.
- The inheritance hierarchy of `GameplayLeaderboard` and per-player
overriding of the implementation of the gameplay leaderboard is gone.
Only one drawable class (renamed to `DrawableGameplayLeaderboard`) is
allowed to display the leaderboards, across all modes of play.
If `createRandomScore()` happened to randomly pick the highest total
score when called with `friend` as the sole argument, that particular
score would not be pink.
`GetScoreByUsername()` would arbitrarily pick the first score for the
user, so in this particular case where a friend had the number 1 score,
the test would wrongly fail.
Fix by checking whether any of the 3 added friend scores have received
the pink colour. Because there is more than 1 friend score in the test,
doing so ensures that at least one of those should eventually become
pink (because, obviously, you can't have two scores at number 1).
Allows to clearly see what the failure is:
TearDown : System.TimeoutException : "friend score is pink" timed out: Expected: some item equal to "#FF549A"
But was: < "#FFFFFF", "#7FCC33", "#444444" >
The #7FCC33 colour is used for the first score on the leaderboard.