`TestSceneEditorTestGameplay` is not isolated from database, and one of
the tests exiting editor when seeked to 60000 milliseconds
(`TestClockTimeTransferIsOneDirectional()`) ended up changing
`EditorTimestamp` to the same value, causing
`TestSaveChangesBeforeGameplayTest()` to fail due to changing initial
state.
To fix, perform a direct deletion of imported beatmaps in realm to avert
this scenario, contrary to the soft-deletion via `BeatmapManager` done
previously.
In an upcoming change, I stumbled upon a test failure mode wherein tests
in `TestSceneScreenNavigation` would die on the following exception:
2023-05-07 17:58:42 [error]: System.ObjectDisposedException: Cannot access a closed Realm.
2023-05-07 17:58:42 [error]: Object name: 'Realms.Realm'.
2023-05-07 17:58:42 [error]: at Realms.Realm.ThrowIfDisposed()
2023-05-07 17:58:42 [error]: at Realms.Realm.All[T]()
2023-05-07 17:58:42 [error]: at osu.Game.Beatmaps.BeatmapManager.<>c__DisplayClass25_0.<QueryBeatmap>b__0(Realm r) in D:\a\osu\osu\osu.Game\Beatmaps\BeatmapManager.cs:line 282
2023-05-07 17:58:42 [error]: at osu.Game.Database.RealmAccess.Run[T](Func`2 action) in D:\a\osu\osu\osu.Game\Database\RealmAccess.cs:line 387
2023-05-07 17:58:42 [error]: at osu.Game.Beatmaps.BeatmapManager.QueryBeatmap(Expression`1 query) in D:\a\osu\osu\osu.Game\Beatmaps\BeatmapManager.cs:line 282
2023-05-07 17:58:42 [error]: at osu.Game.Tests.Visual.OnlinePlay.TestRoomRequestsHandler.<HandleRequest>g__createResponseBeatmaps|6_0(Int32[] beatmapIds, <>c__DisplayClass6_0& ) in D:\a\osu\osu\osu.Game\Tests\Visual\OnlinePlay\TestRoomRequestsHandler.cs:line 174
2023-05-07 17:58:42 [error]: at osu.Game.Tests.Visual.OnlinePlay.TestRoomRequestsHandler.HandleRequest(APIRequest request, APIUser localUser, BeatmapManager beatmapManager) in D:\a\osu\osu\osu.Game\Tests\Visual\OnlinePlay\TestRoomRequestsHandler.cs:line 140
2023-05-07 17:58:42 [error]: at osu.Game.Tests.Visual.TestMultiplayerComponents.<>c__DisplayClass18_0.<load>b__0(APIRequest request) in D:\a\osu\osu\osu.Game.Tests\Visual\TestMultiplayerComponents.cs:line 80
2023-05-07 17:58:42 [error]: at osu.Game.Online.API.DummyAPIAccess.<>c__DisplayClass32_0.<Queue>b__0() in D:\a\osu\osu\osu.Game\Online\API\DummyAPIAccess.cs:line 74
Upon closer inspection, one of the tests in the scene instantiates a
`TestMultiplayerComponents` instance. `TestMultiplayerComponents`
registers a custom request handler onto `DummyAPIAccess`. Normally, this
is not an issue; however, because `TestSceneScreenNavigation` is an
`OsuGameTestScene`, and therefore has its storage recycled after every
test, this leads to the error above in the following scenario:
1. `TestPushMatchSubScreenAndPressBackButtonImmediately()` passes.
2. The test is cleaned up, and the test case's storage is recycled,
including the test case's realm database.
3. In a subsequent test, a web request handled by the dummy API request
handler is fired. The dummy API request handler subsequently attempts
to access a realm that does not exist anymore.
As the usage of `TestMultiplayerComponents` is highly unorthodox in this
particular case, I'm opting for a localised fix which ensures that the
request handler is cleaned up appropriately.
There were no usages of more than one column being provided per row, so
it seemed like unnecessarily complexity. I'm currently trying to reduce
complexity so we can improve the layout of the results screen, which
currently has up to three levels of nested `GridContainer`s.
Of note, I can't add backwards compatibility because the method
signature has not changed in `Ruleset` (only the return type). If we do
want to keep compatibility with other rulesets, we could designate a new
name for the updated method.
`TestSceneHitObjectComposer.TestPlacementFailsWhenClickingButton()` was
attempting to cover the case of the user clicking a toolbox button which
was in front of the playfield, and ensure that the click did not result
in a placement. However, since the paddings in
67f83f246b were added, it is impossible
for a toolbox button to be in front of the playfield in the collapsed
state, which the test was relying on.
The test scenario is still however relevant in the case of the toolbox
being expanded, as in that state the toolbux buttons may very well end
up being in front of the playfield, and they still should not result in
a hitobject being placed. To ensure that this is the case, add a few
extra test steps ensuring that the toolbox is expanded first before
trying to retrieve an overlapping button.
