stdlib: complete the test framework

[amtoine]

waiting for

• stdlib: refactor into a multi-module library #8815
• stdlib test runner: implement setup and teardown commands to unit tests #8776

resolved by

• stdlib test runner: implement setup and teardown commands to unit tests #8776
• Move unit test runner to standard library #8850
• Update testing chapter nushell.github.io#868

Related problem

cc/ @presidento

time to wrap up the testing framework, am i right? 😋

Note
comes from #8815 (comment)

Describe the solution you'd like

• make the test runner a part of std
• maybe use the following structure?

crates/nu-std/lib/
├── testing
│   ├── assert.nu
│   ├── run.nu
│   └── setup.nu
├── dirs.nu
├── ...
└── xml.nu

Describe alternatives you've considered

No response

Additional context and details

No response

[presidento]

I think it is important to be able to load everything from a submodule, I mean something like use asserts * to get every assert command. (Or similarly, use logger *.)

I would rename the assert module to asserts. (It was its original name, too.) And put the run module there with a describing name, like... hm... since Nushell has a run-external command, I would name it run-tests. (Although I like more run external and run tests, but the consistency has more value.)

[amtoine]

I think it is important to be able to load everything from a submodule, I mean something like use asserts * to get every assert command. (Or similarly, use logger *.)

i think it's not possible right now with how the modules are nested 🤔
and it was not possible before as everything was in a single module 😮

if you try to use std dirs, that would give

Error: nu::parser::export_not_found

  × Export not found.
   ╭─[entry #1:1:1]
 1 │ use std dirs
   ·         ──┬─
   ·           ╰── could not find imports
   ╰────

for instance

[presidento]

They had to be in a single module since bb8949f. I am glad that now they can be again in submodules. (Although they cannot be imported directly.) I agree that in current implementation it is not possible, also I think it would be preferable. Because we are going to have a standard library, not a standard book.

I do not want to expand the scope of this issue, you can create another one for discussing how to organize stdlib submodules.

For now I think we have to agree at least in the name of the test runner command.

[amtoine]

They had to be in a single module since bb8949f. I am glad that now they can be again in submodules. (Although they cannot be imported directly.) I agree that in current implementation it is not possible, also I think it would be preferable. Because we are going to have a standard library, not a standard book.

👍

I do not want to expand the scope of this issue, you can create another one for discussing how to organize stdlib submodules.

it's already in the roadmap under "structuring the library" 😉

For now I think we have to agree at least in the name of the test runner command.

run-tests is ok for now 👍
that's a simple mv call and minor find/replace to change this to some other name, so the structure is the main focus 😋

[presidento]

Okay. I'll create a PR after #8776 to move the runner into stdlib, named run-tests, and I'll update the documentation about testing.

[amtoine]

Okay. I'll create a PR after #8776 to move the runner into stdlib, named run-tests, and I'll update the documentation about testing.

coool, looking forward to seing this then 😋

[amtoine]

@presidento
do you think that this issue will be addressed once #8850 lands? 😋

if you want to work more on the test framework, i can add a task to the description above and we can let this open 😉

[presidento]

Almost, just documentation is needed: nushell/nushell.github.io#868
Then we reach the MVP, so this will be addressed IMHO.

[amtoine]

gotcha, that's great 👌

[amtoine]

i think this has been addressed with the PRs above 👍