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

Feature/increase test coverage #204

Merged
merged 6 commits into from
Mar 11, 2021

Conversation

Vunovati
Copy link
Contributor

@Vunovati Vunovati commented Mar 9, 2021

Fix #202 Increase the test coverage for the plugin.

The coverage is:

----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |    98.85 |    93.27 |      100 |    98.83 |                   |
 index.js |    98.85 |    93.27 |      100 |    98.83 |       272,277,278 |
----------|----------|----------|----------|----------|-------------------|

Previously it was:

----------|----------|----------|----------|----------|-------------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files |    96.56 |    90.29 |      100 |    96.51 |                   |
 index.js |    96.56 |    90.29 |      100 |    96.51 |... 83,480,481,496 |
----------|----------|----------|----------|----------|-------------------|

To test the scenarios where temporary files are stored to disk, we needed to be able to predict what the temporary file
name would be. Previously the temp file id was generated by hexoid, but now I needed to make the id generation strategy injectable. This way, I can simulate the scenario where the temp file cannot be changed or where the temp file is missing.

Checklist

@mcollina
Copy link
Member

mcollina commented Mar 9, 2021


await fastify.listen(0)

const tempFilePath = path.join(os.tmpdir(), fileId + 0 + path.extname(filePath))
Copy link
Contributor

Choose a reason for hiding this comment

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

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 the suggestion. I used tap's tmpdir in the next commit.

- use node-tap's testdir as a replacement for os.tmpdir
- inject tmpdir in saveRequestFiles
- do not inject toID in saveRequestFiles
@@ -181,6 +181,88 @@ test('should error if it is not multipart', { skip: process.platform === 'win32'
})
})

test('should error if handler is not a function', { skip: process.platform === 'win32' }, function (t) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you know why these two tests wouldn't work on windows? Also, is there a reason why you're adding tests to this legacy folder? The name suggests these are old tests, I'm assuming new tests should be written outside of this folder perhaps.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I assume it is connected to already existing issue where tests are failing on windows for the legacy api #110.
As per readme the legacy api is not compatible with windows.

The legacy use cases also take part in the test coverage computation. I assume the folder is named legacy to group the tests for the legacy callback api. In this test we are covering the error that happens in the function handleLegacyMultipartApi.

Copy link
Contributor

Choose a reason for hiding this comment

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

Understood, I didn't know there was a legacy API, this explains it.

}
})

test('should not throw on request files cleanup error', { skip: process.platform === 'win32' }, async function (t) {
Copy link
Contributor

Choose a reason for hiding this comment

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

same question for this test. it doesn't seem to be doing anything that wouldn't work on windows

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reason for having this test skip the Windows platform is different.

I think the test is flaky on Windows. It failed on our windows CI with node 12.x but it ran successfully on a Windows 10 laptop with node 12.x. (I can't prove that, you'll have to trust me :) )
My theory is that this could be similar to the Timing Caveat on windows described in node-tap documentation where removal of the tempdir is asynchronous. tapjs/tapjs#677

In the test we are using rimraf which has a known issue that could be causing this: isaacs/rimraf#72

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense, thanks for clarifying.

Copy link
Member

Choose a reason for hiding this comment

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

you can remove rimraf. recursive folder removal is now part of Node.js. See https://nodejs.org/api/fs.html#fs_fs_rmdirsync_path_options and others.

Copy link
Contributor

Choose a reason for hiding this comment

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

This module still supports Node 10 though

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, recursive is not supported in Node 10.

@simoneb
Copy link
Contributor

simoneb commented Mar 10, 2021

The 3 remaining uncovered lines are something that can't be tested or do you think you can cover them too?

@Vunovati
Copy link
Contributor Author

The 3 remaining uncovered lines are something that can't be tested or do you think you can cover them too?

I was unable to reproduce the case where those three lines would be used.

Screenshot 2021-03-10 at 11 55 43

This functionality was created in #44

The unit test for the functionality was created but those three lines are not covered with that test.
What I tried was appending N streams to the FormData with either varying sizes or varying and push delays.
Still the three lines remained untouched.

I am not comfortable enough with the untested use cases to say that we can safely remove these lines. That's why I left them uncovered.

@simoneb
Copy link
Contributor

simoneb commented Mar 10, 2021

Fair enough. You can open this PR up for review

@Vunovati Vunovati marked this pull request as ready for review March 11, 2021 08:15
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

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.

increase code coverage
3 participants