library tests are slow

Bug #1695766 reported by Be
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Wishlist
Unassigned

Bug Description

All tests that inherit from LibraryTest are much slower than other tests. Initializing a TrackCollection calls SchemaManager::upgradeToSchemaVersion, which goes through each database schema upgrade for every library test. It would be faster if library tests started with a fresh database with an up-to-date schema without having to go through all the upgrade steps. Our free Travis and AppVeyor builds frequently run out of time, so making the tests faster could help prevent them from timing out.

Be (be.ing)
Changed in mixxx:
importance: Undecided → Low
Revision history for this message
Be (be.ing) wrote :

Command for running tests that do not touch the database:
mixxx-test --gtest_filter=-AutoDJ*:CoverArt*:CrateStorage*:*DAO*:*Library*:Schema*:SearchQuery*

This reduces the test execution time on my laptop from several minutes to 20 seconds.

Revision history for this message
Be (be.ing) wrote :

This is a common reason why Travis times out. Let's work to improve our build + test time.

Changed in mixxx:
importance: Low → High
milestone: none → 2.1.0
Revision history for this message
Be (be.ing) wrote :

Uwe, do you want to take care of this? It will be beneficial no matter what CI systems we use.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

By dumping the current DB schema into an SQL file we would be able to create new databases much faster. The only challenge is to keep this file in-sync with the corresponding incremental upgrade file.

1st step: Create SQL schema file manually and use it for BOTH the application and tests. I don't like to introduce special code paths in MixxxDb that are only used during tests, so let's go all the way. We need to have this in place anyway once we need to do a major database migration. The filename should include the version number as metdaata, which allows us to keep track of those immutable schema files.

2nd step: Create SQL schema file automatically when adding a new database version (preferrably) or at least verify it!

Ok, I'll take care of this.

Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
status: New → In Progress
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Request: SchemaManagerTest should start with a fresh DB and not use the checked-in version.

Hopefully that test alone isn't too slow?

Revision history for this message
Be (be.ing) wrote :

Maybe a Git commit hook could be used to automatically update the reference SQLite file when the schema file changes?

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Revision history for this message
Be (be.ing) wrote :

Moving this back to low priority since https://github.com/mixxxdj/mixxx/pull/1458 made Travis build with multiple threads so it doesn't regularly time out anymore.

Changed in mixxx:
importance: High → Low
Changed in mixxx:
milestone: 2.1.0 → 2.2.0
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

An even simpler solution with a quick win:
https://github.com/mixxxdj/mixxx/pull/1644

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

The in-memory improvement has been merged. I don't plan any further improvements, although I started a PoC (see above).

Changed in mixxx:
assignee: Uwe Klotz (uklotzde) → nobody
status: In Progress → Confirmed
milestone: 2.2.0 → none
importance: Low → Wishlist
Changed in mixxx:
status: Confirmed → Fix Committed
milestone: none → 2.1.1
assignee: nobody → Uwe Klotz (uklotzde)
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8879

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.