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

Add testing infrastructure to the standard library #1300

Closed
matthew-healy opened this issue May 12, 2023 · 2 comments · Fixed by #1914
Closed

Add testing infrastructure to the standard library #1300

matthew-healy opened this issue May 12, 2023 · 2 comments · Fixed by #1914
Labels
area:stdlib question Further information is requested type: feature request

Comments

@matthew-healy
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Currently there's no recommended/built-in way to write tests for Nickel code. It's not particularly hard to do (see the simple testing infra in tests/integration/pass/lib/assert.ncl for an example), but it seems like something enough projects will want that it's worth considering it for inclusion in the stdlib.

Describe the solution you'd like

It's probably sufficient to have some simple assertion primitives (in the form of contracts, I guess). It might be nice to spike out some ideas for more opinionated test structures, but I guess there'd be a higher bar there for inclusion in the stdlib.

Describe alternatives you've considered

The main alternative is to provide testing infrastructure in its own library. I'm not against this in principle, but given we don't have a simple way of importing Nickel packages yet (and we're unlikely to have one in the near future) I think it makes sense to at least add something official to the stdlib.

@vkleen
Copy link
Member

vkleen commented May 12, 2023

A minimal step towards this could be putting Assert and check from tests/integration/pass/lib/assert.ncl into a stdlib namespace, e.g. std.tests. That seems to be all the Nickel specific functionality we have needed for a while; later we could maybe add some automation into the CLI to make it simpler to hook up.

@matthew-healy
Copy link
Contributor Author

Yeah, I agree that could be a reasonable first step. Though since stdlib releases are currently tightly coupled to language releases I wonder if we should explore the design space here a little more before making a final decision.

@yannham yannham added the question Further information is requested label Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:stdlib question Further information is requested type: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants