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: #5555 - move to node test runner #440

Merged

Conversation

SamSalvatico
Copy link
Contributor

Checklist

Moving the tests from tap to the node test runner, based on what requested in the following issue
Fastify #5555

@SamSalvatico SamSalvatico marked this pull request as ready for review January 17, 2025 18:18
@SamSalvatico
Copy link
Contributor Author

I did not move all the tests yet, only the ones under commonjs and typescript esm
Just to understand if you like how I’ve moved the tests and to avoid modifying too many files in the same PR, I’ll make the next changes in a subsequent PR

test/commonjs/autohooks-basic.js Outdated Show resolved Hide resolved
test/commonjs/error.js Outdated Show resolved Hide resolved
test/typescript-esm/forceESM.ts Outdated Show resolved Hide resolved
@jean-michelet
Copy link
Contributor

Thanks for your PR.

I’ll make the next changes in a subsequent PR

This plugin is a bit tricky regarding testing, we might discover later then the changes are difficult to apply.
So imho, this PR should demonstrate if we can do it or not.
Plus, refactoring tests is generally very risky, as we don't have feedback about how the changes have affected the project so we might need some more reviews.

@SamSalvatico
Copy link
Contributor Author

Thanks for your PR.

I’ll make the next changes in a subsequent PR

This plugin is a bit tricky regarding testing, we might discover later then the changes are difficult to apply. So imho, this PR should demonstrate if we can do it or not. Plus, refactoring tests is generally very risky, as we don't have feedback about how the changes have affected the project so we might need some more reviews.

Got it! So would you prefer that I try to update all the tests in this PR?

@jean-michelet
Copy link
Contributor

So would you prefer that I try to update all the tests in this PR

I think it's a good idea, you might want some more reviews before going forward.

@jean-michelet
Copy link
Contributor

@climba03003 @Fdawgs wdyt?

@dancastillo
Copy link
Member

since t.assert.plan was not added until node v22 wondering if we should use tspl or something similar, wdyt? @mcollina @gurgunday

@climba03003
Copy link
Member

I think it's a good idea, you might want some more reviews before going forward.

I believe we can do incremental one, but it should be green before land.

since t.assert.plan was not added until node v22 wondering if we should use tspl or something similar, wdyt?

If you were mentioning t.plan, it exists since 20.15.0.

@SamSalvatico
Copy link
Contributor Author

I should have changed all the tests from tap to node test runner (at least searching for tap there are no occurences 😁 )

scripts/unit.js Outdated
Copy link
Contributor Author

@SamSalvatico SamSalvatico Jan 20, 2025

Choose a reason for hiding this comment

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

I am having some problems running tests using patterns, because windows is not managing them automatically
Before, when using tap, I think it was using the glob on which the library depends

I tried using the glob library by myself, but it failed.
The last idea I have is trying with fast-glob, but if it doesn't work I have to ask: do you have any clue about this?

Copy link
Contributor

@jean-michelet jean-michelet Jan 21, 2025

Choose a reason for hiding this comment

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

I tried using the glob library by myself, but it failed.

The link you are sharing is not a failure, this test suite has been cancelled because the Node 20 on latest MacOS failed: https://github.com/fastify/fastify-autoload/actions/runs/12870529340/job/35882162556

"Exceeded timeout of 30000 ms for a test.

This is a timeout failure we had for a long time with Jest, I am not even sure we fixed it since.

Copy link
Member

Choose a reason for hiding this comment

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

@jean-michelet
Copy link
Contributor

I will perform a more precise review during the day before accepting, but looks good.

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

@jean-michelet
Copy link
Contributor

Could be a good idea to use a LLM to check this diff, to be sure we didn't miss anything.

@jean-michelet
Copy link
Contributor

@jsumners

Curious about the laugh emoji, I had a good experience with LLM catching omissions while refactoring.
Pretty bad at understanding complex context, but this case appear legit to me.

@jsumners
Copy link
Member

@jsumners

Curious about the laugh emoji, I had a good experience with LLM catching omissions while refactoring. Pretty bad at understanding complex context, but this case appear legit to me.

I have zero confidence those things will provide anything useful, particularly in this context.

@jean-michelet
Copy link
Contributor

jean-michelet commented Jan 24, 2025

I have zero confidence those things will provide anything useful

Strong opinion if you think this about programming more broadly (I do not suggest using it for Fastify projects in general).

@climba03003
Do you think we can merge?

@jean-michelet
Copy link
Contributor

My bad, forget my previous comment.

scripts/unit.js Outdated Show resolved Hide resolved
scripts/unit.js Outdated
...globSync('test/module/*.js'),
]

const args = ['node', '--test', ...testFiles]
Copy link
Contributor

Choose a reason for hiding this comment

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

We should use borp here @jsumners?

Copy link
Member

Choose a reason for hiding this comment

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

This project already has a scripts/ directory and uses them for running tests. I assume it's due to the way the module works. I don't really know; I don't pay much attention to this module. So I'm not overly concerned about using borp here. If it simplifies things, go for it.

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 moved the tests to borp as done in avvio
I used the same patterns as used in the master branch with tap

Copy link
Contributor

@jean-michelet jean-michelet Jan 26, 2025

Choose a reason for hiding this comment

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

I am worry the coverage is not checked anymore, can you please try with -C --check-coverage on your machine? What happen if you remove one of these tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

coverage readded, removing some of them the coverage goes down

Copy link
Contributor

Choose a reason for hiding this comment

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

removing some of them the coverage goes down

Did the tests fail? If coverage is not 100% covered, it should be red.

Copy link
Contributor

Choose a reason for hiding this comment

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

Don't know if we should use the flag --check-coverage?

Copy link
Contributor

Choose a reason for hiding this comment

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

It does look ok, but I never used borp so...

coverage

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've added the check, now if the coverage goes down it fails
Screenshot 2025-01-28 at 08 56 30

@Fdawgs Fdawgs requested a review from Copilot January 29, 2025 14:01

Choose a reason for hiding this comment

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

Copilot reviewed 20 out of 35 changed files in this pull request and generated no comments.

Files not reviewed (15)
  • .taprc: Language not supported
  • package.json: Language not supported
  • scripts/unit.js: Evaluated as low risk
  • test/commonjs/autohooks-disabled.js: Evaluated as low risk
  • scripts/unit-typescript-tsm.js: Evaluated as low risk
  • scripts/unit-typescript-esm.js: Evaluated as low risk
  • test/commonjs/autohooks-basic.js: Evaluated as low risk
  • test/commonjs/autohooks-cascade.js: Evaluated as low risk
  • .borp.yaml: Evaluated as low risk
  • test/commonjs/options.js: Evaluated as low risk
  • test/commonjs/non-plugin.js: Evaluated as low risk
  • test/commonjs/index-package.js: Evaluated as low risk
  • test/commonjs/deep.js: Evaluated as low risk
  • test/commonjs/graph-dependency.js: Evaluated as low risk
  • test/commonjs/autohooks-overwrite.js: Evaluated as low risk
Comments suppressed due to low confidence (2)

test/commonjs/cyclic.js:7

  • The description for the test suite should be 'Node test suite for cyclic dependency'.
describe('Node test suite for babel-node', function () {

test/commonjs/dependency.js:20

  • Declare the variable 'res' within each 'it' block to avoid potential issues with variable scope and reuse.
const res = await app.inject({ url: '/plugin-a' })
Copy link
Contributor

@jean-michelet jean-michelet left a comment

Choose a reason for hiding this comment

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

Sorry, but we have integrated support for Node 23 native type stripping.
Can you fix the conflicts plz, than I will merge your PR.

.borp.yaml Outdated Show resolved Hide resolved
@SamSalvatico
Copy link
Contributor Author

Sorry, but we have integrated support for Node 23 native type stripping. Can you fix the conflicts plz, than I will merge your PR.

done, tested locally with 22 and 23

@jean-michelet jean-michelet merged commit e4ae352 into fastify:master Jan 31, 2025
11 checks passed
@jean-michelet
Copy link
Contributor

Good job @SamSalvatico!

Thanx for your time.

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.

6 participants