Closed miha-plesko closed 7 years ago
@gberginc I've opened the first PR. Please note that PRs here are at the lowest priority possible until August 15 so feel free not to review until then.
To answer your question regarding bool
vs error
: it's about informing the user what the error was (where did the mismatch occur). If we only support bool
then the compare function has no means of passing the error message to the checker.
In PRs that follow, we actually only make use of the error
compare function in order to be able to provide accurate error message in case of mismatch. But I left support for bool
just in case we need it in the future. That being said, would it be better to drop support for bool
since we currently don't use it?
When you put it like this, I guess it makes sense. You could probably also construct the error message at a place where the checker is called like you do here, but I don't know if there could be other errors that might be interesting.
In case you think returning bool
would be useful in the future, you can leave it, otherwise I agree with the removal.
I've removed support for bool
functions, we're good to go.
Thanks @miha-plesko. Please update #46 now as well.
Currently, DirEquals/TarGzEquals checkers are only able to check whether directory structure and file content is EXACTLY the same as expected. This brings a problem when we can't tell EXACLTY what the content will be, e.g. because Capstan prepends --env prefix to bootcommands in random order.
With this commit we extend DirEquals/TarGzEquals so that it now accepts map of expectations that can either contain expected string (EXACT match) or lambda function (more extensible match).
To reuse same logic for DirEquals and TarGzEquals checkers we quickly recaftor the code by introducing loadDir() and loadTarGz() auxilary functions.