Add durations to pytest in CI.

[JoeZiminski]

Windows tests for python 3.13 are taking a very long time to run, #631. This PR prints the time taken for every test to dig further int othis.

The issue really started after this PR which is just a pre-commit auto update. Will try downgrading these.

[JoeZiminski]

Oh, somehow I didn't realise, all tests are much slower on python 3.13.

1. try python 3.12
2. note that the TUI tests are all very slow

[JoeZiminski]

Times from the tests on Windows (slowest OS) 3.9 are below.

• Tui tests take 16 minutes
• The transfer tests (even local filesystem) all take some time, they are maybe 1 second each but there are a lot of them.
• Each transfer is an rclone (including subprocess) call which is known to be slow on windows. I'm not sure much can be done about this.
• Also, Google drive tests take 9 minutes

Total test time is 44 minutes.

I think some obvious areas for improvement are:

1. find a way to reduce TUI tests e.g. session level fixture if possible
2. have a quick look at file system tests, but I think the limiting step is rclone / subprocess
3. look at why google drive set up takes so long

I think 2) and 3) might be unavoidable, with the only way to reduce this reducing the scope of what's tested. I'd rather have them tested somewhere, the options being:

• test fully each time (maybe we could get tests down to ~35 minutes on windows by optimising TUI tests)
• split the tests into full vs light runs, and figure out the most effective way to decide whent to run full vs. light . @adamltyson makes a good point that tests that don't run automatically and frequently (e.g. a main branch test that runs once every week) are often missed. Here I think the best solutions are

1. light tests on draft, full tests on ready-for-review
2. full tests only on merge to main, this would probably end up being quite annoying as bugs will slip through PR review.
3. There might be a way to press a button to trigger full tests on GitHub CI, and only allow merge once full tests have run. This would also be annoying.

I think (1) is best, if most development is occuring on draft PRs and we can get these down to < 10 minutes (still quite long) then that shouldn't hammer the CI too badly. Better to accidentally run the full test suite when you don't really need to rather than not run it when you should.

ds-tests.xlsx

[JoeZiminski]

Same issue for python 3.12, will cancel tests as they are obviously taking much longer. Trying to revert the pre-commit PR though I can't see how that would cause this

[JoeZiminski]

Changing the pre-commit did not help, of course. Try reverting to the PR before this happened.

[JoeZiminski]

For good measure, try going back to 04233d5 #592. Testing only on linux, previously these tests were very close in time.

[JoeZiminski]

Current hypothesis is that some dependency updated when the tests started taking longer, and it only affected python 3.9+ but not python 3.9

[JoeZiminski]

Okay great that was it, a fancylog update included subprocess calls, didn't clock at the time these will be slow. Also try removing codecov just to see if that has much of an affect on test times, as I read it could.