Ensure order of search history entries in tests

[XiangRongLin]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

• Ensure order of search history entries in tests

Fixes the following issue(s)

• Fixes CI pipeline maybe flaky (HistoryRecordManagerTest#deleteSearchHistory) #7553

Due diligence

• I read the contribution guidelines.

❗ squash merge

[litetex]

LGTM, however the same problem might also happen here:

NewPipe/app/src/androidTest/java/org/schabi/newpipe/local/history/HistoryRecordManagerTest.kt

Line 147 in 4a7cfd1

SearchHistoryEntry(OffsetDateTime.now().minusSeconds(7), 2, "AC"),

Could you fix it also there?
A constant would be great 😄

[XiangRongLin]

however the same problem might also happen here:

How would it also happen there? every line has the .minusSeconds(x)

[litetex]

@XiangRongLin

The problem here is that the value can't be controlled by the test.
OffsetDateTime.now() is not a constant, if there is e.g. a leap second or system clock update between the two lines in

NewPipe/app/src/androidTest/java/org/schabi/newpipe/local/history/HistoryRecordManagerTest.kt

Lines 147 to 148 in 4a7cfd1

	SearchHistoryEntry(OffsetDateTime.now().minusSeconds(7), 2, "AC"),
	SearchHistoryEntry(OffsetDateTime.now().minusSeconds(6), 0, "ABC"),

the test might fail.

I'm strongly in favor of implementing a hard-coded/current time independent timestamp like

OffsetDateTime.of(LocalDateTime.of(2000, 1, 1, 1, 1), ZoneOffset.UTC)

and then use that one for the tests.

[litetex]

There seems to be something wrong with the test on Emulator API 29:
https://github.com/TeamNewPipe/NewPipe/actions/runs/1724908322/attempts/2
https://github.com/TeamNewPipe/NewPipe/actions/runs/1724908322/attempts/1

org.schabi.newpipe.local.history.HistoryRecordManagerTest > onSearched[test(AVD) - 10] FAILED 
	org.junit.runners.model.TestTimedOutException: test timed out after 1 seconds
	at org.assertj.core.internal.Strings.instance(Strings.java:118)

not sure what's causing that but according to https://stackoverflow.com/questions/17016011/junit-test-times-out-despite-executing-quickly and

it has has be an InterruptedException inside

NewPipe/app/src/androidTest/java/org/schabi/newpipe/local/history/HistoryRecordManagerTest.kt

Lines 44 to 53 in 3c21be8

	manager.onSearched(0, "Hello").test().await().assertValue(1)
	// For some reason the Flowable returned by getAll() never completes, so we can't assert
	// that the number of Lists it returns is exactly 1, we can only check if the first List is
	// correct. Why on earth has a Flowable been used instead of a Single for getAll()?!?
	val entities = database.searchHistoryDAO().all.blockingFirst()
	assertThat(entities).hasSize(1)
	assertThat(entities[0].id).isEqualTo(1)
	assertThat(entities[0].serviceId).isEqualTo(0)
	assertThat(entities[0].search).isEqualTo("Hello")

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[litetex]

The above error now also occurs on other branches, e.g. the dev-Branch.

Above error should be fixed with a6515d5.
There seems to be a performance problem with GH actions which causes the Android API 29 test do not run fast enough (needs more than 1s) on the VM which causes the above problems.

The internal was - for a unknown reason - changed from 10s to 1s inside 7d6688f#diff-52b3c5a209220512cb671827511b090b467afb544abcd94da776e7273072ffc0R24

[litetex]

LGTM