* Allow retrieving exit code from command execution
This will be helpful to derive error categories in case
an executable provides context-specific error codes.
* make sure that we always have a non 0 exit code for errors
* Add capabilities for checks if a file has been written
With the current file system mock we cannot assert if
a file has been written. E.g. we cannot distiguish between
files added to the virtual file system before the test and files
explicitly written. In contrast to that we can check for deleted
files.
With the change here we get a func HasWritteFile(name).
[Q] Wouln't it be possible to check based on the file content
if a file has been written (the new file should have another
content as the file registered before).
[A] We should not assert some file content here since the
produced file content can be created by another "class" which
is unit tested somewhere else. With that approach we would test
the producer here again.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
This change refactors the npm pkg and npmExecuteScripts implementations
to be reusable for future steps, e.g., npmExecuteLint.
In addition, it fixes few small bugs related to unit test execution on
Windows and the fileUtils mocking implementation.
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
ExecMockRunner and ShellMockRunner both needs an environment. "Extending"
here leads to "subclasses" for both cases. That is more long-winded since
it could be.
I don't understand why there should be a two dimensional array.
When dealing with envs we have normally a list containing entries like
[]string{"DEBUG=true", "HOME=/home/me"}
Having two dimensional env arrays would mean to have several alternate
environment in the tests at the same time. Don't think there is a need
for that.
