Skip to content
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

#2180 - Assessment Workflow Enqueuer Scheduler - Start Assessment - E2E tests #2314

Merged

Conversation

andrewsignori-aot
Copy link
Collaborator

@andrewsignori-aot andrewsignori-aot commented Sep 19, 2023

  • Create a few E2E tests for the new schedler.

    • Should queue an assessment when an active application has only the original assessment and it is in 'Submitted' state. (119 ms)
    • Should queue the oldest pending reassessment when an active application has one completed original assessment and multiple submitted reassessments queued. (145 ms)
    • Should not queue a 'Submitted' assessment if the another assessment has its status as 'Queued' (99 ms)
    • Should not queue a 'Submitted' assessment if the another assessment has its status as 'In progress' (101 ms)
    • Should not queue a 'Submitted' assessment if currentAssessment and currentProcessingAssessment are the same already. (96 ms)
  • Created a method to centralize the mock name creation and allow retrieve the mock to execute tests like toBeCalledWith.

startApplicationAssessmentQueueMock = app.get(
    getQueueProviderName(QueueNames.StartApplicationAssessment),
);
expect(startApplicationAssessmentQueueMock.add).toBeCalledWith(queueData);

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@github-actions
Copy link

Backend Unit Tests Coverage Report

Totals Coverage
Statements: 17.56% ( 2198 / 12520 )
Methods: 8.09% ( 128 / 1583 )
Lines: 20.32% ( 1928 / 9486 )
Branches: 9.79% ( 142 / 1451 )

@github-actions
Copy link

E2E Workflow Workers Coverage Report

Totals Coverage
Statements: 46.73% ( 300 / 642 )
Methods: 40% ( 32 / 80 )
Lines: 51.02% ( 251 / 492 )
Branches: 24.29% ( 17 / 70 )

@github-actions
Copy link

E2E Queue Consumers Coverage Report

Totals Coverage
Statements: 74.31% ( 483 / 650 )
Methods: 66.67% ( 54 / 81 )
Lines: 76.4% ( 424 / 555 )
Branches: 35.71% ( 5 / 14 )

@github-actions
Copy link

E2E SIMS API Coverage Report

Totals Coverage
Statements: 54.48% ( 3995 / 7333 )
Methods: 51.31% ( 488 / 951 )
Lines: 59.3% ( 3245 / 5472 )
Branches: 28.79% ( 262 / 910 )

// Arrange

// Application submitted with original assessment.
const application = await createDefaultApplication();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to understand the purpose of the new method? won't it be able to achieve by saveFakeApplicationDisbursements ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is just a centralization inside the same TC file. There are positive and negative scenarios using the same method which makes it better to assume that, when there is a negative test it would be more accurate because the positive is already using the same method.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These test cases are also targeting student assessments, not disbursements. Can you please point out the benefit of using the saveFakeApplicationDisbursements?
@andrepestana-aot FYI

* the provided student assessment.
*/
const createDefaultApplication = async (
assessmentStatus?: StudentAssessmentStatus,
Copy link
Contributor

@ann-aot ann-aot Sep 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

options?: with partial<>?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a simple helper method inside a TC file itself and not a shared factory. Should we follow the above-mentioned suggestion for such method?

Copy link
Contributor

@ann-aot ann-aot Sep 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong feeling, I am good with both, unless the options are big

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a local method and it is not intended to be shared and the comments state its purpose.
If there is not a strong feeling I will keep the method as it is and state again, I never saw a reason for local methods to follow the patterns used on factories, options yes, we use it all around, "options?: with partial<>" is something to be enforced from factories. Hope that it is ok.

application,
auditUser,
});
oldestAssessment.triggerType = AssessmentTriggerType.OfferingChange;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

[
StudentAssessmentStatus.Queued,
StudentAssessmentStatus.InProgress,
].forEach((status) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

Copy link
Contributor

@ann-aot ann-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM @andrewsignori-aot 👍 just a minor comment and a question

Copy link
Collaborator

@andrepestana-aot andrepestana-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good but I agree with Ann on #2314 (review)
Please take a look. Thanks.

Copy link
Collaborator

@guru-aot guru-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice work @andrewsignori-aot

Copy link
Contributor

@ann-aot ann-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @andrewsignori-aot 👍

Copy link
Collaborator

@andrepestana-aot andrepestana-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

[
StudentAssessmentStatus.Queued,
StudentAssessmentStatus.InProgress,
].forEach((status) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍


// Application submitted with original assessment.
const application = await createDefaultApplication(status);
const submittedAssessment = createFakeStudentAssessment({
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we not update application.currentAssessment = submittedAssessment ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That operation happens inside the factory already used in the method createDefaultApplication.

});
});

it(`Should not queue a '${StudentAssessmentStatus.Submitted}' assessment if currentAssessment and currentProcessingAssessment are the same already.`, async () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering how currentAssessment and currentProcessing assessment could be same when assessment status is submitted?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the real world, they would not have it. This condition is to force the specific SQL condition. That is what the below comment is stating.
"// Force currentAssessment and currentProcessingAssessment to be the same to test the SQL condition."

@dheepak-aot
Copy link
Collaborator

Great work. One clarification and one minor question.

Copy link
Collaborator

@sh16011993 sh16011993 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice Work @andrewsignori-aot 👍

Copy link
Collaborator

@dheepak-aot dheepak-aot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

@andrewsignori-aot andrewsignori-aot changed the title #2180 - Assessment Workflow Enqueuer Scheduler - Start Assessment- E2E tests #2180 - Assessment Workflow Enqueuer Scheduler - Start Assessment - E2E tests Sep 20, 2023
@andrewsignori-aot andrewsignori-aot merged commit 17cf172 into main Sep 20, 2023
@andrewsignori-aot andrewsignori-aot deleted the feature/#2180-assessment-workflow-enqueuer-e2es branch September 20, 2023 17:25
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:41 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:43 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:43 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:43 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:43 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:45 — with GitHub Actions Inactive
@andrewsignori-aot andrewsignori-aot temporarily deployed to DEV September 20, 2023 17:45 — with GitHub Actions Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants