Add before_script option
Closed this issue · 6 comments
It's certainly possible that people want to install more than a blank processwire installation before running the tests. So a option like the before_script
in travis-ci would probably be nice.
It is a question if this is necessary, because you can do this in setUp/tearDown
which testing frameworks provide.
I cannot do a composer -n require lostkobrakai/migrations
from within a setup block of the testing framework. Also running the full test suite with superuser rights is also not the best option if e.g. only a single command might need them.
This make me think if the separation of environment setup from test suite is the right way to do it. Because instead of this tool I could make function which would be included in the setUp
method of test suite class. But I think yes, the separation is good way. I see it is better if the test is as simple as it could be and focus just on testing.
So, you are right. Commands like this belongs to environment setup, not to tests itself. The before_script
will be definitely useful.
I'm thinking now how to implement this. There are some things to consider. The Tense tool is multi-platform, so the before_script
option must support multi-platform scripts as well. Should I support list of commands or just single command (full script could be in an external file)?
Let's consider only single command is supported. It could look like composer require ...
which is trouble-free, but what if I have an external script file which I want to run? On linux it is script.sh
but on windows it is script.bat
so the commands will be different sh script.sh
vs .\script
.
A solution could be to have a config option for each platform like:
before_script:
linux: sh script.sh
osx: sh script.sh
win: .\script
With this I have to implement platform detection and run a corresponding command for it. I'm not sure if this is the best solution.
Do you see a better solution for this?
I would not care about the os specifics. If the user does want to use a .sh file it's his decision and his responsibility to make sure this kind of script is supported on the used platforms. If it really does need to be platform independent it's probably easier to use a scripting language, which is not os specific, e.g. php script.php
.
Yes, you are right. I've considered the options and your proposal looks the best.