oneTimeTearDown()/tearDown() is being called an additional time at the end of execution

[vtereso]

I have been pulling master and had functions that were executing within these hooks and saw what seems to be some unintended behavior. Example file as show below:

testSomething() {
    assertTrue "true" "true"
}

setUp() {
  echo "setup"
}
tearDown() {
  echo "Tear down"
}
oneTimeTearDown() {
  echo "One time tear down"
}
. shunit2

Output:

setup
testSomething
Tear down
One time tear down

Ran 1 test.

OK
Tear down
One time tear down

[vtereso]

Looking into it, I only see warnings being raised if these functions do not exit successfully, but do not see why they would be called at the end of execution. PR for consideration: #113

[cbandy]

These are being called as part of the EXIT trap. Related to #108.

[vtereso]

Right, I wasn't familiarized with the entire topology. Looked things over and there is still a fundamental flaw since the exit code at the end of the script gets caught by the trap on successful runs so the 0 signal triggers _shunit_cleanup and the following block

if command [ ${__shunit_clean} -eq ${SHUNIT_FALSE} ]; then
    # Ensure tear downs are only called once.
    __shunit_clean=${SHUNIT_TRUE}

    tearDown
    command [ $? -eq ${SHUNIT_TRUE} ] \
        || _shunit_warn "tearDown() returned non-zero return code."
    oneTimeTearDown
    command [ $? -eq ${SHUNIT_TRUE} ] \
        || _shunit_warn "oneTimeTearDown() returned non-zero return code."

    command rm -fr "${__shunit_tmpDir}"
  fi

will trigger the tear downs again. I don't know what @kward's perspective is and whether the idea was to have termination always happen from within _shunit_cleanup (migrate in _shunit_generateReport and relative code here for 0 signal) or to remove the trap '_shunit_cleanup EXIT' 0

[jaspalch]

This can be used as sort of a hacky workaround:

tearDown() {
    #need this to suppress tearDown on script EXIT
    [[ "${_shunit_name_}" = 'EXIT' ]] && return 0

[swcline]

I tried adding the above code inside tearDown() but get the following error - is there something else that needs to be enabled or set?

in oneTimeSetUp
in setUp
testOne
validateTestOrdinals_test.sh[34]: shunit_name: parameter not set

the test script:

#! /bin/sh
#assume this test script is in a subdirectory under the shunit directory; a sibling of examples

#Load test helpers.
. ../shunit2_test_helpers

testOne() {
assertTrue 0
}

testTwo() {
assertTrue 0
}

setUp() {
echo "in setUp"
}

tearDown() {
#need this to suppress tearDown on script EXIT
[[ "${shunit_name}" = 'EXIT' ]] && return 0
echo "in tearDown"
}

oneTimeSetUp() {
echo "in oneTimeSetUp"
}

oneTimeTearDown() {
echo "in oneTimeTearDown"
}

#Load and run shUnit2.
. ../shunit2

[swcline]

My workaround is to create a directory in oneTimeSetUp and wrap the tear down code inside a check for that directory inside oneTimeTearDown - second time around, directory is not there, so code is skipped

[kward]

Is this still a problem in the HEAD release?

[ypoluektovich]

Yes.

[Bajger]

Yes, tested on release 2.1.8. My output looks like this:

Calling teardown...

Ran 4 tests.

OK
Calling teardown...
PharoLauncherCommonFunctions.sh: line 45: ./pharo-launcher.sh: No such file or directory

[swcline]

Here is a simple test that exhibits the issue #! /bin/bash # assume this test script is in a subdirectory under the shunit directory; a sibling of examples # Load test helpers. . ../shunit2_test_helpers testOne() { assertTrue 0 } testTwo() { assertTrue 0 } setUp() { echo "in setUp" } tearDown() { echo "in tearDown" } oneTimeSetUp() { #oneTimeTearDown gets called one extra time at exit, to prevent that add and check a guard file #touch "${SHUNIT_TMPDIR}/guard.tmp" echo "in oneTimeSetUp" } oneTimeTearDown() { #oneTimeTearDown gets called one extra time at exit, to prevent that add and check a guard file #if [ -f "${SHUNIT_TMPDIR}/guard.tmp" ]; then echo "in oneTimeTearDown" #fi } # Load and run shUnit2. . ../shunit2

…

On Tue, Nov 23, 2021 at 5:04 AM David Bajger ***@***.***> wrote: Yes, tested on release 2.1.8. My output looks like this: Calling teardown... Ran 4 tests. OK Calling teardown... PharoLauncherCommonFunctions.sh: line 45: ./pharo-launcher.sh: No such file or directory — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#112 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACX7JVGCV3JIOL4VEQB2HLUNNRKTANCNFSM4GXHLOGA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Steve Cline ***@***.*** http://www.clines.org http://www.linkedin.com/in/stevecline "Be right, and then be easy to live with, if possible, but in that order." - Ezra Taft Benson encrypted email to ***@***.***