It’ll be a true pleasure to embrace this tool next
Just as it was to embrace Haumea.
For people who wonder what is this good for?
My (current) condensed conclusion would be: it takes a snapshot of your (e.g.) NixOS resolved value lattice * and helps you make important parts of your configuration an invariant.
Please educate me if I got this wrong.
* Why are we commonly still reasoning about config data in terms of NixOS? It’s just the beginning.
I don’t get it. What does this?
A tool for snapshot testing.
Means you have a list of tests, which are just function calls or values and a name.
You do not specify the result, as you do with traditional tests, but do a first run, and trust the results, the tool will persist those for you and on later runs it will compare to persisted values.
What is the snapshot part of this testing?
You do not specify the result, as you do with traditional tests, but do a first run, and trust the results, the tool will persist those for you and on later runs it will compare to persisted values.
@NobbZ
Is this not just cached testing instead?
The snapshots live in the tests/_snapshots directory of the repo
I wasn’t able to find what cached testing is, could you elaborate on that?
I also found this strategy being called approval tests, is that what you are looking for?
I think I am just completely confused about what the software does in general, I am going to go look at the repo in more depth.
I think @NobbZ explained it pretty well. Look up “snapshot testing” on google, it’s a pretty common terminology in software. You should also look up “snapshot testing vs unit testing”.
I was able to write a test on a complex output datastructure (several hundred LoC) that would have otherwise taken hours to craft in just about 15 mins.
That’s an absolutely awesome capability!
I guess this is similar to golden testing, as well? If you want another term to look up.
TIL about golden testing, namaka is indeed very much the same.
namaka v0.1.1 was just released which adds a lot of the missing documentation, including a quick start guide, and a section to (briefly) explain what snapshot testing is.
This update also adds templates that hopefully makes it easier to get started with namaka
nix flake init -t github:nix-community/namaka
# or
nix flake init -t github:nix-community/namaka#minimal
Features
- load: accept
src
- cli: allow running commands other than
nix flake check
Changes
- load: deprecate
flake
anddir
Fixes
- load: fix json format when values are implicitly casted
- canonicalize path before running
nix flake check
namaka v0.2.0 has been released with support for configuration and some quality of life changes!
Breaking Changes
-
namaka review
now runsnix eval .#checks
by default instead ofnix flake check
. You can override this behavior by editingnamaka.toml
or using the--cmd
flag. - When provided a directory, namaka now changes the working directory to it, instead of modifying the
nix
commands it runs. This can make a difference if you specify both the directory and--cmd
.
Features
- Local configuration with
namaka.toml
-
namaka clean
to remove unused and pending snapshots - Add
subflake
template for using namaka in a subflake
Improvements
-
namaka review
now runs faster by default, since the default command has been changed tonix eval .#checks
.