/test

@MrJithil there are two kinds of tests in Node:

• There are tests that run on every PR automatically, you can see them under "checks".
• There is a more extensive CI process which only collaborators can trigger due to risk potential.

I've gone ahead and added a label to this PR to automatically trigger CI :)

Thanks @benjamingr

request-ci will not launch or test this benchmark, or I am wrong? @benjamingr

Oh yeah, I'll start a benchmark run @Mesteery

Edit: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1091/

There are some benchmark tests in CI. I don't know how the coverage for them is though.

Edit: Here https://github.com/nodejs/node/blob/master/test/benchmark/test-benchmark-assert.js

@Mesteery apparently the CI does test benchmarks, I didn't know that and @Trott showed me

CI: https://ci.nodejs.org/job/node-test-pull-request/42245/

There are some benchmark tests in CI. I don't know how the coverage for them is though.

The coverage is minimal. Each benchmark file runs exactly one condition and that's it. The purpose is to make sure there aren't benchmarks that are completely broken and can't run at all. That used to happen.

CI: https://ci.nodejs.org/job/node-test-pull-request/42259/

CI: https://ci.nodejs.org/job/node-test-pull-request/42302/

CI: https://ci.nodejs.org/job/node-test-pull-request/42304/

/request-ci

CI: https://ci.nodejs.org/job/node-test-pull-request/42335/

- Loading data for nodejs/node/pull/41741
✔  Done loading data for nodejs/node/pull/41741
----------------------------------- PR info ------------------------------------
Title      benchmark: remove input param manipulation (#41741)
   ⚠  Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch     MrJithil:todo-task-4 -> nodejs:master
Labels     assert, test, benchmark, needs-ci
Commits    1
 - benchmark: avoid input param manipulation
Committers 1
 - MrJithil 
PR-URL: https://github.com/nodejs/node/pull/41741
Reviewed-By: Benjamin Gruenbaum 
Reviewed-By: Mohammed Keyvanzadeh 
Reviewed-By: Mestery 
Reviewed-By: Luigi Pinca 
Reviewed-By: Colin Ihrig 
Reviewed-By: Mary Marchini 
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/41741
Reviewed-By: Benjamin Gruenbaum 
Reviewed-By: Mohammed Keyvanzadeh 
Reviewed-By: Mestery 
Reviewed-By: Luigi Pinca 
Reviewed-By: Colin Ihrig 
Reviewed-By: Mary Marchini 
--------------------------------------------------------------------------------
   ℹ  This PR was created on Sat, 29 Jan 2022 05:53:10 GMT
   ✔  Approvals: 6
   ✔  - Benjamin Gruenbaum (@benjamingr): https://github.com/nodejs/node/pull/41741#pullrequestreview-866902469
   ✔  - Mohammed Keyvanzadeh (@VoltrexMaster): https://github.com/nodejs/node/pull/41741#pullrequestreview-866928878
   ✔  - Mestery (@Mesteery): https://github.com/nodejs/node/pull/41741#pullrequestreview-866932788
   ✔  - Luigi Pinca (@lpinca): https://github.com/nodejs/node/pull/41741#pullrequestreview-867009867
   ✔  - Colin Ihrig (@cjihrig) (TSC): https://github.com/nodejs/node/pull/41741#pullrequestreview-867200235
   ✔  - Mary Marchini (@mmarchini) (TSC): https://github.com/nodejs/node/pull/41741#pullrequestreview-867225186
   ✖  GitHub CI is still running
   ℹ  Last Full PR CI on 2022-02-03T17:32:44Z: https://ci.nodejs.org/job/node-test-pull-request/42335/
   ℹ  Last Benchmark CI on 2022-01-31T10:28:30Z: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1091/
- Querying data for job/node-test-pull-request/42335/
   ✔  Last Jenkins CI successful
--------------------------------------------------------------------------------
   ✔  Aborted `git node land` session in /home/runner/work/node/node/.ncu

I don't understand why one of the jobs is still marked as running on GitHub, while the same job is successful on Jenkins.

Help wanted on this

Landed in 217acb9

I just noticed this and it seems like my comment was misunderstood :).

Any variable coming from the tests definition should be taken one by one instead of being changed inside of the method as the definition is printed as it is. If the method uses something else, the definition does not fit anymore.

n should be the number of runs. The reason for this was that it was not possible to define the defintion to keep the benchmark below a runtime threshold.