You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to parameterize some data in my tests, but I can't, because when I add source shunit2 to the bottom of my test suite, shunit2 interprets my parameter as a filename and tries to run tests in it.
It appears that this section of the code contains the assumption I'm breaking:
# determine the operating mode
if [ $# -eq 0 ]; then
__shunit_script=${__SHUNIT_PARENT}
__shunit_mode=${__SHUNIT_MODE_SOURCED}
else
__shunit_script=$1
[ -r "${__shunit_script}" ] || \
_shunit_fatal "unable to read from ${__shunit_script}"
__shunit_mode=${__SHUNIT_MODE_STANDALONE}
fi
Which is happening here?
We intentionally don't allow passing shell parameters to test scripts in order to simplify things.
Nobody ever tried this before, so I'm the lucky one who has run into this problem.
Something else.
If you haven't made a conscious choice to disallow passing shell parameters to test scripts, then I might try fixing this.
Thanks.
The text was updated successfully, but these errors were encountered:
I want to parameterize some data in my tests, but I can't, because when I add
source shunit2
to the bottom of my test suite, shunit2 interprets my parameter as a filename and tries to run tests in it.It appears that this section of the code contains the assumption I'm breaking:
Which is happening here?
If you haven't made a conscious choice to disallow passing shell parameters to test scripts, then I might try fixing this.
Thanks.
The text was updated successfully, but these errors were encountered: