Core: Revamp processing order to enable proper aborting of test runs #1124
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: This is a follow up to #1121.
The Problem
Bear with me a moment, while I explain what this PR is doing. In the current system, when you add a test, it is queued up as a single function, named
run
. Thus, when a test suite begins running, the queue generally looks something like this (not real code, just for illustration purposes):When we begin processing the queue, each of those individual
run
functions is replaced by a series of sub-functions. These functions, however, wind up at the back of the queue. Thus, after processing the first item you get:This is not intuitive. It also means that by the time we actually begin processing tests we have a massive queue of anonymous and
runHook
functions. This makes it very difficult to determine where one test ends and another begins by looking at the queue.Previously, this knowledge was not very important, but with the coming CLI and specifically the
--watch
option, we need to be able to tell where tests start/end in the queue so that we can properly abort the test run while still allowing the test to cleanup after itself.The Solution
So, what this PR does is change the processing order such that as each test is processed, it is added to the front of the queue so that it is processed immediately. In other words, the original queue above would become the following after processing the first test:
This means that further tests will remain as a self-contained
run
function until the current test is finished executing.This makes it easy to tell where the current test ends and the next one begins. It also means that the queue will remain relatively compact, instead of expanding every single test ahead of time.
This PR also revamps some of the behavior in the system that was previously, implicitly relying on the fact that all tests were expanded before processing any of them (specifically, how we handled hooks for tests). Overall, I think this makes the processing behavior much more understandable and less dynamic, while also enabling a better CLI experience.
Thanks for taking the time to read and review this!