Fails immediately, reporting that the unexpected and actual values are not equal to one another
failSame [MESSAGE] EXPECTED ACTUAL
Fails immediately, reporting that the expected and actual values are the same
failNotSame [message] EXPECTED ACTUAL
Fails inmediately, reporting that the expected and actual values are not the same
failFound [message] CONTENT
Fails immediately, reporting that the content was found
failNotFound [message] CONTENT
Fails the test immediately, reporting that the content was not found
Setup/Teardown
Command
Description
oneTimeSetUp
Setup common environment
oneTimeTearDown
Clean up the environment after all tests
setUp
Reset the environment before each test
tearDown
Clean up the environment after each test
Skipping
Command
Description
startSkipping
Forces the remaining assert and fail functions to be “skipped”
endSkipping
Returns calls to the assert and fail functions to their default behavior, i.e. they will be called
isSkipping
Returns the current state of skipping. It can be compared against ${SHUNIT_TRUE} or ${SHUNIT_FALSE} if desired
Suites
Command
Description
suite
If this function exists, it will be called when shunit2 is sourced
IIf not, shUnit2 will search the parent script for all functions beginning with the word test, and they will be added dynamically to the test suite
suite_addTest name
This function adds a function named name to the list of tests scheduled for execution as part of this test suite
This function should only be called from within the suite() function
Advanced
Constants
Predefined
Constant
Value
SHUNIT_TRUE
Standard shell true value (the integer value 0)
SHUNIT_FALSE
Standard shell false value (the integer value 1)
SHUNIT_ERROR
The integer value 2
SHUNIT_TMPDIR
Path to temporary directory that will be automatically cleaned up upon exit of shUnit2
SHUNIT_VERSION
The version of shUnit2 you are running
User defined
Constant
Value
SHUNIT_CMD_EXPR
Override which expr command is used. By default expr is used, except on BSD systems where gexpr is used
SHUNIT_COLOR
Enable colorized output. Options are ‘auto’, ‘always’, or ‘none’, with ‘auto’ being the default
SHUNIT_PARENT
The filename of the shell script containing the tests. This is needed specifically for Zsh support
SHUNIT_TEST_PREFIX
Define this variable to add a prefix in front of each test name that is output in the test report
Error handling
The constants values SHUNIT_TRUE, SHUNIT_FALSE, and SHUNIT_ERROR are returned from nearly every function to indicate the success or failure of the function
The variable flags_error is filled with a detailed error message if any function returns with a SHUNIT_ERROR value
usage() { [ ! -z "$1" ] && echo$1 cat <<EOF Print all IPs in a CIDR range, similar to the Ubuntu prips utility. This script assumes that the Red Hat version of ipcalc is available. Usage: $0 <cidr> [-h] Example: $0 192.168.0.3/28 EOF exit 1 } [ -h == "$1" ] && usage [ ! -z "$2" ] && usage 'You may only pass one CIDR' [ -z "$cidr" ] && usage 'You must pass a CIDR' echo$cidr | egrep -q "^(?:[0-9]+\.){3}[0-9]+/[0-9]+$" || \ usage "$cidr is not a valid CIDR"
# range is bounded by network (-n) & broadcast (-b) addresses. lo=$(ipcalc -n $cidr | cut -f2 -d=) hi=$(ipcalc -b $cidr | cut -f2 -d=)
IFS=. read a b c d <<< "$lo" IFS=. read e f g h <<< "$hi"
# test cases test_minus_h() { first_line=$(. ./prips.sh -h | head -1) assertEquals "Print all IPs in a CIDR range, similar to the Ubuntu \ prips utility.""$first_line" }
test_missing_args() { first_line=$(. ./prips.sh | head -1) assertEquals 'You must pass a CIDR'"$first_line" }
test_too_many_args() { first_line=$(. ./prips.sh 192.168.0.2/28 192.168.0.2/30 | head -1) assertEquals 'You may only pass one CIDR'"$first_line" }
test_bad_input() { first_line=$(. ./prips.sh bad_input | head -1) assertEquals 'bad_input is not a valid CIDR'"$first_line" }
# no virtual environment again $ python3 >>> import flask ModuleNotFoundError: No module named 'flask'
Storing a Virtual Environment configuration
Get the installed packages list and pipe it into the requirements.txt file.
1
pip freeze > requirements.txt
Restoring a Virtual Environment
The virtual environment system encourages you to keep track of the modules you’re using in a requirements.txt file within your project directory. You can process requirements.txt with pip to handle automated installs of all dependencies: