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
If a tear down function is provided, and the associated test function executes a munit assertion like munit_assert_init(1, ==, 2), then the tear down function is not executed.
This might be a problem if some resources were allocated (e.g. temporary directories) which always need to be released.
Also, in case the test program is compiled with MUNIT_NO_FORK, then even non-persistent resources (like memory allocated by a setup function) could be leaked.
The text was updated successfully, but these errors were encountered:
I've been fighting with my unit tests for a week before I realized this. This is really problematic in some cases. In my case, the code tested needs to fork a process and open pipes or sockets to it. The tear down function is taking care of cleaning up that process, closing connections, etc. so any failure in a test creates an orphan process with connections left open and makes the subsequent test hang.
It would be really good to ensure that the tear down function is called no matter the result.
+1 on this. I didn't lose a week but I did lose a couple hours because of this.
I merged this PR with my local copy and it looks like it fixed the problem for me: #50
If a tear down function is provided, and the associated test function executes a munit assertion like
munit_assert_init(1, ==, 2)
, then the tear down function is not executed.This might be a problem if some resources were allocated (e.g. temporary directories) which always need to be released.
Also, in case the test program is compiled with
MUNIT_NO_FORK
, then even non-persistent resources (like memory allocated by a setup function) could be leaked.The text was updated successfully, but these errors were encountered: