feat(learn): add section for dynamically generating test cases

[JakobJingleheimer]

Description

Validation

Related Issues

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npm run format to ensure the code follows the style guide.
• I have run npm run test to check if all tests are passing.
• I have run npx turbo build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Feb 2, 2025 2:05pm

[AugustinMauroy]

I'm not fan of the provided example because it's based on experimental api.

maybe do same things as this test (do with jest). But I mean based on hand written variable
https://github.com/nodejs/nodejs.org/blob/main/apps/site/util/__tests__/detectOS.test.mjs

[JakobJingleheimer]

Hmm, I think that example isn't quite as good. The one I have is unknowable.

I'm happy to just switch the assertion (and far less work 😅)

EDIT: ohhh! Wait, is the experimental API you're concerned about globSync? (Rather than assert.partialDeepStrictEqual)

[AugustinMauroy]

EDIT: ohhh! Wait, is the experimental API you're concerned about globSync? (Rather than assert.partialDeepStrictEqual)

Yup and and using a variable is easier because the reader can copy past and run.

[JakobJingleheimer]

using a variable is easier because the reader can copy past and run

A variable for what?

[AugustinMauroy]

A variable for what?

import { isBiscuit } from "factory";

const valid_tests_case = [
  "cookies",
  "speculoos"
];

test("isBiscuit", (t) => {
   for() {
   // loop for dynamic test 
   t.test(`${e} - should be true`)
   }
});

in this case it's use Biscuit because it's fun

But here it's test user agent

[ovflowd]

Feel free to merge whenever the PR becomes ready.

[JakobJingleheimer]

Hmm, I've given this some more thought, and I think the experimental API used is okay because it does not affect the main issue of the article. Thoughts on that?

How about both options? The user-agent one is simple, and the glob is advanced; I know I frequently see docs cover a simple example but not an advanced one, which leaves an advanced user on their own to figure out something complicated (which is very frustrating).

[AugustinMauroy]

LGTM ! maybe open an issue after this pr merged to explore the possibility of making one article per use case, as this one is starting to get long.

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟠 89	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 99	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 99	🟢 100	🟢 96	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 92	🔗

[github-actions]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	87.1% (736/845)	72.13% (233/323)	86.33% (139/161)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
185	0 💤	0 ❌	0 🔥	5.691s ⏱️