Skip to content

tests: fail on warnings and minor refactor#1986

Closed
MattSturgeon wants to merge 1 commit intonix-community:mainfrom
MattSturgeon:test_module
Closed

tests: fail on warnings and minor refactor#1986
MattSturgeon wants to merge 1 commit intonix-community:mainfrom
MattSturgeon:test_module

Conversation

@MattSturgeon
Copy link
Copy Markdown
Member

  • tests: fail on warnings
  • tests: make dontRun a config option

This PR refactors things so that warnings and assertions are explicitly checked by the test functions.

The biggest benefit is that it will now be more obvious when tests produce warnings.

Additional benefits include:

  • Handle assertions in a derivation, instead of during eval
  • tests.dontRun is now a module option, simplifying the implementation

In the future we can add additional tests.* options, such as "expect" options, assertion/warning whitelists, etc.

Marked as a draft because I'm too tired to test this and ensure it is in a good working state, but code reviews are still welcome!

module
./_module.nix
../modules/top-level
] ++ lib.optional (args ? dontRun) { tests.dontRun = lib.mkDefault dontRun; };
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be simpler to drop the dontTest attr in moduleList. If we keep the function arg/attr then we need to pass it in to the module config here using mkDefault.

@traxys is dropping the attr/fn-arg a breaking change? I assume yes, but probably not an important one?

It'd be nice to have dontRun only be a module option (other than in mkTestDerivationFromNvim)

Comment on lines +110 to +127
errors = pkgs.runCommand name { inherit name assertions warnings; } ''
echo "Issues found evaluating $name":
if [ -n "$assertions" ]; then
echo "Unexpected assertions:"
for it in "$assertions"; do
echo "- $it"
done
echo
fi
if [ -n "$warnings" ]; then
echo "Unexpected warnings:"
for it in "$warnings"; do
echo "- $it"
done
echo
fi
exit 1
'';
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be done on a per-module basis or on a per moduleList basis?

If the latter, how should we handle some modules having errors and others needing to be build/run?

Assertions failed previously, but now they are handled within a
test-derivation.

Warnings were printed previously, now they will fail the test.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant