testing

[nrdxp]

One of the big selling points of a system like atom should be sane testing interfaces. Further, the code has reached a point that thorough testing is warranted to avoid constant breakage during feature development. Without a solid CI system to ensure the integrity of core features from here, feature development will be unecessarily painful.

The test directory should be converted to an atom, which is composed from a remote, known-good checkout of the composer logic, so we can still call tests on the live repository if/when the system breaks.

If we break any of the core assumptions with a careless copy, we could easily break things.

Things that still need to be tested:

• the dir argument of compose should remain a path through the fixed point, or we loose lazy copying. We need a test for this to ensure changesets don't break it
• thorough scope test, including attempts to break out of a module
• the APIs of the functions compose depends on need to be thoroughly vetted and tested, as a special priority
• all standard library functions should have sensible tests for known error conditions, edge-cases and args that should pass
• any other, yet to be documented, core feature or condition that must remain invariant for the system to remain consistent should be added to this list if/when discovered

[blaggacao]

Maybe just a test.nix or test directory in the module root which is a private test module for the user?

Yes, test(.nix|_\w+\.nix) ?

[nrdxp]

for the sake of simplicity, I was thinking we could have just a regular module (a directory named test) with a mod.nix in it. That way the semantic is exactly the same, instead of having an entirely different pattern for tests (which would be somewhat confusing)

So tests are again, just a module, but for the sake of the parser they have a special name: test (basically the equivanet #[cfg(test)] in a rust module)

Tracking code coverage would be fairly trivial from there. For every module member, there would be an equivalent attribute in the test module for that attribute. All you have to do take the difference of the main module to the test module to get the current code coverage percentage.

[ic4-y]

I like the idea of a directory for tests, yes. And the rest sounds nice, too. At first sight of course. 😁