-
Notifications
You must be signed in to change notification settings - Fork 781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract tests out of queue into its own testQueue #1260
Conversation
Stephen Yeung seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. |
src/core/processing-queue.js
Outdated
const start = now(); | ||
config.depth = ( config.depth || 0 ) + 1; | ||
|
||
while ( config.queue.length && !config.blocking ) { | ||
const elapsedTime = now() - start; | ||
|
||
if ( !defined.setTimeout || config.updateRate <= 0 || elapsedTime < config.updateRate ) { | ||
if ( priorityCount > 0 ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this code unneeded? What was its original purpose? Can you explain why we don't need it now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the original code, priorityCount's main purpose is to prioritize tests that was flagged to be executed first. The priorityCount was also incremented/decremented in advance()
originally because if a tests needed to be inserted to the queue, it will be inserted after the tasks(which gets added to front of the queue) and after the already prioritized tests.
This is not necessary anymore since the task is in it's own queue, so we do not need to deal with the priortyCount when dealing with the tasks. (Only needed for the testQueue in the new implementation)
src/core/processing-queue.js
Outdated
function addToTaskQueue( tasksArray ) { | ||
for ( let i = 0; i < tasksArray.length; i++ ) { | ||
const taskItem = tasksArray[ i ]; | ||
config.queue.push( taskItem ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this whole function can be simplified to:
config.queue.push(...tasksArray)
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it certainly can. Will update that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed the changes yet, but I'm curious (as it isn't clear from the PR description) as to what the goal is with this change?
We're introducing another field into QUnit.config
, but I'm not clear on what the benefit of doing so is for consumers. Is there a use case you have in mind for it?
I don’t think the intent is really related to exposing another queue, just trying to simply the queueing logic. In the long run, having separate queues for the list of tasks for a single test and the pending tests will make it easier to add more logic around test to test advancing (e.g. so that measurements can be done to prevent memory leaks and/or identify per-test code coverage), but that is definitely not the goal of this PR itself. This PR is only about simplifying the queuing logic (having a single queue where some items are prepended and others are appended is really confusing). |
If you’d prefer to avoid adding a new property on QUnit.config I think we can most likely do that. @step2yeung - Can you confirm? |
Thanks for clarifying @rwjblue! |
Yeah, my concern is primarily around adding a new public property. If we can keep |
@trentmwillis Thanks for the feedback! I modified it such that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking really good to me, thanks for working on this cleanup @step2yeung!
@trentmwillis - Have any time for a follow-up review?
src/test.js
Outdated
@@ -205,7 +205,7 @@ Test.prototype = { | |||
|
|||
if ( hookName === "after" && | |||
hookOwner.unskippedTestsRun !== numberOfUnskippedTests( hookOwner ) - 1 && | |||
config.queue.length > 2 ) { | |||
( config.queue.length > 0 || ProcessingQueue.taskCount() > 2 ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really related to this PR since it was pre-exixting, but this took me a little while to figure out (specifically, why is > 2
important), it may warrant an inline comment...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed...should've done that last time I refactored this code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! Sorry for being slow to review. Overall, the implementation seems pretty good. Mainly have some suggestions around comments/clarification for future travelers.
src/core/processing-queue.js
Outdated
@@ -21,69 +20,91 @@ import { | |||
|
|||
let priorityCount = 0; | |||
let unitSampler; | |||
const taskQueue = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to have a comment describing what a task
is within the taskQueue
. Something to the effect of:
This is queue of functions that are tasks within a single test. After tests and removed from config.queue they are expanded into a set of tasks in this queue.
src/core/processing-queue.js
Outdated
* Adds a function to the ProcessingQueue for execution. | ||
* @param {Function|Array} callback | ||
* @param {Boolean} priority | ||
* Adds a tests to the TestQueue for execution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Should be singular, test
.
src/test.js
Outdated
@@ -205,7 +205,7 @@ Test.prototype = { | |||
|
|||
if ( hookName === "after" && | |||
hookOwner.unskippedTestsRun !== numberOfUnskippedTests( hookOwner ) - 1 && | |||
config.queue.length > 2 ) { | |||
( config.queue.length > 0 || ProcessingQueue.taskCount() > 2 ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed...should've done that last time I refactored this code
src/core/processing-queue.js
Outdated
* @param {Function|Array} callback | ||
* @param {Boolean} priority | ||
* Adds a tests to the TestQueue for execution. | ||
* @param {Array} testTasksArray |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could be wrong, but isn't this always going to be a function now? We pass the runTest
function into here, and then later shift
them off and then pass the expanded array to addToTaskQueue
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct! I renamed this to testTasksFunc
const elapsedTime = now() - start; | ||
|
||
if ( !defined.setTimeout || config.updateRate <= 0 || elapsedTime < config.updateRate ) { | ||
if ( priorityCount > 0 ) { | ||
priorityCount--; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we need to reintroduce this priorityCount
decrement somewhere so that if a high priority test is added after the run starts, it should be placed in the right spot. I doubt we have a proper test for this, so we could always add that back with a test in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a TODO for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks a bunch!
This PR separates the content of
Qunit.config.queue
which contains both tests (runTest function) and its tasks(each function added to the queue by runTest) into two separate queue: queue and testQueue.Previously the queue was serving two purposes:
This PR also goes along the lines of the first comment by
platinumazure
in this PR: #1124The idea of this change is to clean up and simplify the queue logic to make it easier to reason about. The change separates the processing of tests and its tasks, giving a clear indication when all the tasks of a tests are complete, and when the next test can begin.
Before:
After: