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: https://github.com/kward/shunit2/pull/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 https://github.com/kward/shunit2/issues/112#issuecomment-976359094, 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 @.***

[cezanne]

I had the same problem. The following modification resolved my issue.

diff --git a/shunit2 b/shunit2
index 57a45da..ead9de6 100755
--- a/shunit2
+++ b/shunit2
@@ -1367,6 +1367,7 @@ _shunit_execSuite
 if ! oneTimeTearDown; then
   _shunit_fatal "oneTimeTearDown() returned non-zero return code."
 fi
+__shunit_clean=${SHUNIT_TRUE}
 
 # Generate a report summary.
 _shunit_generateReport