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

test/encryption: differentiate identical test names #1102

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

alxndrsn
Copy link
Contributor

This should make test results less ambiguous when one of the tests fails.

This should make test results less ambiguous when one of the tests fails.
@alxndrsn alxndrsn marked this pull request as ready for review March 13, 2024 07:37
@alxndrsn alxndrsn requested a review from ktuite March 13, 2024 07:37
Copy link
Member

@ktuite ktuite left a comment

Choose a reason for hiding this comment

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

Just some thoughts on how the test names should change to be more informative!

These specific tests (and exhausting the worker or not) reminded me of something that will likely come up in the blob/s3 situation:

Client Audit attachments, which are stored as Blobs, get processed and put into a separate client_audits table, I think so it's easy to export a csv of all client audit events for a form across submissions. These client audits are processed by a worker, but if someone tries to export the data before the worker has come along, the processing will happen on the fly during the export.

@@ -355,7 +355,7 @@ describe('managed encryption', () => {
result['media/testfile.jpg'].should.equal('hello this is a suffixed file');
}))))));

it('should decrypt client audit log attachments', testService((service, container) =>
it('should decrypt client audit log attachments (1)', testService((service, container) =>
Copy link
Member

Choose a reason for hiding this comment

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

This test looks like it's running exhaust(container) to process the client audits and that they are processed successfully without error. But since they are encrypted, the worker does not actually decrypt them, so the client_audits table has 0 rows.

Maybe a better name for the test is should successfully process encrypted client audit log attachments without decrypting?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for closer reading of this PR!

should successfully process encrypted client audit log

Does it actually process them?! I'd expect entries in the client_audits table, but the test asserts there are none... Would a better title be: should mark encrypted client audit log attachments as processed, but not process them?

Copy link
Member

Choose a reason for hiding this comment

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

Something like that! In lib/worker/submission.attachment.update.js I think it's skipping attachments of encrypted submissions. So it's "processing" the attachment event to check for client audits but actually ignoring them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

should skip encrypted client audit log attachments and mark them as processed?

@@ -376,7 +376,7 @@ describe('managed encryption', () => {
where action='submission.attachment.update' and processed is not null and failures = 0`)
.then((count) => { count.should.equal(4); })))));

it('should decrypt client audit log attachments', testService((service) =>
it('should decrypt client audit log attachments (2)', testService((service) =>
Copy link
Member

Choose a reason for hiding this comment

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

This test is more accurately about decrypting encrypted client audit attachments during export so I think the name can stay the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants