tweag/nickel
1
1
Fork 0
mirror of https://github.com/tweag/nickel.git synced 2024-09-11 11:47:03 +03:00
Code Issues Projects Releases Wiki Activity
6015c8c0cb
nickel/core/tests
History
Yann Hamdaoui 6ffa6ac0a1
Fix the order of argument in (.) (#1752) 
* Fix order of arguments for curried dot operator

* Add std.record.get to stdlib

* Update release note with breaking changes for (.)

Co-authored-by: jneem <joeneeman@gmail.com>

* Remove snapshot test for std.record.get

Unfortunately, the output of the error message shows a closure address
(in practice, a memory address), which makes it non-determinstic and
thus unfit for a snpashot test.

Instead, it's been replaced with an integration test, which
Unfortunately won't allow to detect a deterioriation in error reporting,
but at least ensure that the contract of `std.record.get` works as
expected.

---------

Co-authored-by: jneem <joeneeman@gmail.com>
2024-01-09 10:11:48 +00:00
..
examples Rename and move workspace crates (#1399) 2023-06-26 16:58:40 +00:00
integration Fix the order of argument in (.) (#1752) 2024-01-09 10:11:48 +00:00
manual Add --error-format flag to serialize err diagnostics (#1740) 2023-12-19 15:36:57 +00:00
README.md Rename and move workspace crates (#1399) 2023-06-26 16:58:40 +00:00

README.md

A quick note on how tests are structured

This directory has three subdirectories, each containing a different kind of test. Each directory contains a main module implementing a test runner for that particular type of test. The tests themselves are then written as Nickel source files, annotated with toml headers which describe the expected behaviour of the program.

  • integration contains general purpose integration tests,
  • examples contains a runner for samples in the repository's top-level examples directory.

Why are the tests split into separate crates?

By default, cargo encourages developers to put integration test files directly in the tests directory. Doing so means that a different test crate (and associated binary) is built for each file.

There is both a compile-time and a runtime cost to doing this, as (1) multiple different binaries must be built to run all tests and (2) while cargo can run multiple tests in parallel, it runs multiple binaries sequentially.

By instead having larger crates which contain multiple tests each we save on compilation time, as well as being able to take advantage of parallelisation to a greater degree.

See this blog post for more information.

Where are the snapshot tests?

Our current implementation of snapshot tests relies on the Nickel interpreter binary. Because of this they were moved to the nickel-lang-cli CLI crate when it was split out from the core nickel-lang-core crate. Eventually, it would be nice to reintegrate snapshot tests for error messages into nickel-lang-core.