Change:
setTimeout(() => { result.dispose(); resolveCodeBlockRendering(document.createElement('code')); <del> setTimeout(resolve, 50); }, 50); </del> <ins> setTimeout(resolve, 10); }, 10); </ins> }); });

Discussion:
This is a continuation of A unit test shouldn't take longer than 50ms. An easy way to "speed up" setTimeout and friends is -utility To reproduce these numbers run open the file and remove the first non-json lines run[x] 51ms, MarkdownRenderer Code block renderer asyncRenderCallback should not be invoked if result is immediately disposed [x] 104ms, MarkdownRenderer Code block renderer asyncRenderCallback should not be invoked if dispose is called before code block is rendered [x] 55ms, ExtHostAuthentication Can get multiple sessions (with different scopes) in one extension [x] 55ms, ExtHostAuthentication Can get multiple sessions (from different providers) in one extension [x] 60ms, ExtHostAuthentication clearSessionPreference - true [x] 72ms, ExtHostAuthentication silently getting session should return a session (if any) regardless of preference - [x] 93ms, Editor Controller issue : Greater than 1000+ multi cursor typing replacement text appears inverted, lines begin to drop off selection [x] 51ms, Notebook Find Update find matches basics 3 [x] 53ms, Notebook Find Update find matches basics [x] 51ms, Notebook Find Update find matches,
Thanks - for fixing tests in UserDataAutoSyncService
Made IndexedDB tests faster but not fast enough to finish within less than 50ms. Because the bottle neck is IndexedDB. Any write transaction in IndexedDB is taking ~20ms and couple of tests need at least 2-3 write transactions. Hence checking off IndexedDB tests Before ! After !
I think tests like that which still take a long time should be renamed to
Okay. Only couple of tests are taking around 80ms. But since the cut off is 50ms, I see I do not have option other than changing them to integration tests. So changed it.
Any reason I was assigned back?
Sorry, my bad
fyi - list starts now at and I have re-assigned some folks
It seems you overwrote the checkboxes
These are new checkboxes, everything slower than 125ms - I copied the list from the collapsed section
Sorry that I am confused. Following tests are fixed before and they were checked off. tests were fixed before and tests are moved to integration tests .

You can see the updated results when I run locally: tests are not taking more than 125ms and tests do not exist. <img width="1134" alt="image" src="https://user-"I am not sure if I am missing anything here Anyway, I have made tests much faster
Its also weird that I do not see any collapsed sections in my browser <img width="976" alt="image" src="https://user-"
I read through and couldn't find any of my tests. I think this is a case of "wrong Alex".
A bunch of tests that were using fake timers, like the one, got faster after
Some observations after having looked into mine: in some of my slow tests I tend to do many assertions in a single test as opposed to doing 1 assertion per kind, as such I now split these tests up into smaller chunks but this will obviously not reduce overall execution times in some tests I was able to squeeze out a bit more by doing instead of awaiting promises one by one I attribute slowness in my tests mainly to the fact that: I access the disk (because I actually want to test APIs or native behaviour) I access a native library such as SQLite I was trying out the fake timers thing, but obviously that does not help a lot for disk access or native libraries. Bottom line: if we want unit tests to finish in range then I think we need to pull out all unit tests that test disk or native libraries into a new suite that is either integration tests or can be controlled by some flags. I am not a big fan of integration tests mainly for the reason that I cannot run them as nice as I can with our test runner support (I brought this up in our standup to Thoughts?
One thing we noticed is that quite some tests use the . Those will surely benefit from an InMem-provider <img width="944" alt="Screenshot 2022-06-09 at 15 21 59" src="https://user-"
This would also be less of a problem if we were able to run tests in parallel, as slow tests are usually not computationally-blocking slow tests. Mocha does have a flag that runs all tests in parallel, which may cause breakages. Vitest/jest allows explicitly marking tests as parallel-capable via . Maybe we could do something similar.
I second this.

I agree we need to test the , but that's a single test suite in itself. Every other component should be unit tested with a which doesn't use any IO. If it's required that they do, I argue that is the very definition of integration test.
fyi - I reran the data extraction and updated the main comment here
Working on a couple of things with more adoption of figured out that we run a for every to ensure data is flushed to disk which makes writing slower and figured out a way to disable this for most tests except the ones that want to test writing specifically adopted scheme for some of my tests and even found a bug in our in-memory fs-provider Before: After:
Maybe after my PR landed, the list could be regenerated.
May be its better to switch to use fake timers by default for all tests?
Mine will be addressed by moving to integration via I found new ones in notebook land, adding I have asked to support our selfhost test extension showing test decorators in files because one papercut I have is that I can no longer use the selfhost test extension in those test files.
we should action these as part of this issue: <img width="837" alt="image" src="https://user-"
Excellent في الجمعة، ١٢ يناير ٢٠٢٤، ٣:٢٧ ص Matt Bierner