c012f2f4ed
- [x] refactor lib into separate files, similar to NixOS/nixpkgs/lib. - [x] refactor ci to automatically generate derivations from flake outputs - [x] remove cluttered indirection statements throughout the codebase - [x] refactor hosts to allow for upcoming integration tests - [x] improve ambiguity in the existing docs - [x] add [BORS](https://bors.tech) support - [x] add initial integration test - [x] write tests documentation - [x] test lib - [x] improve version string generation, and do so automatically for pkgs/flake.nix sources Clean up the codebase as best we can in preparation for #152 and add tests. From now on, all PRs will be merged with BORS. |
||
|---|---|---|
| .. | ||
| testPathsToImportedAttrs | ||
| 0004-nixos-testing-Add-support-for-specialArgs.patch | ||
| default.nix | ||
| lib.nix | ||
| README.md | ||
Testing
Testing is always an important aspect of any software development project, and NixOS offers some incredibly powerful tools to write tests for your configuration, and, optionally, run them in CI.
Lib Tests
You can easily write tests for your own library functions in the
tests/lib.nix file and they will be run on every nix flake check or
during a CI run.
Unit Tests
Unit tests are can be created from regular derivations, and they can do almost anything you can imagine. By convention, it is best to test your packages during their check phase. All packages and their tests will be built during CI.
Integration Tests
You can write integration tests for one or more NixOS VMs that can, optionally, be networked together, and yes, it's as awesome as it sounds!
Be sure to use the mkTest function, in the tests/default.nix
which wraps the official testing-python function to ensure
that the system is setup exactly as it is for a bare DevOS system. There are
already great resources for learning how to use these tests effectively,
including the official docs, a fantastic blog post,
and the examples in nixpkgs.