Can you provide a function that runs on failure to clean up shared resources for test cases?

[shutaozhenzhen]

It appears that Ceedling's tearDown does not execute when a test fails, preventing proper cleanup of shared resources and affecting subsequent tests. Is there a function available that runs on failure to clean up shared resources for test cases?

[shutaozhenzhen]

note: My current temporary fix is to move the global state initialization to suiteSetUp

[mkarlesky]

@shutaozhenzhen What kind of shared resources are you working with?

[shutaozhenzhen]

@shutaozhenzhen What kind of shared resources are you working with?

For this issue, it is the initialization of the log module. I previously initialized the log in setUp and released it in tearDown. This leads to the situation where if the execution fails and tearDown is skipped, the log will be reinitialized in the next setUp
I have solved this problem by moving the log initialization to suiteSetUp. And after some consideration, it is actually possible to use global variables to indicate whether initialization is needed

[mkarlesky]

@shutaozhenzhen Logging is always a bit tricky in any testing setup. It's the nature of the beast.

Generally speaking, we advocate for unit testing free of any external dependencies. Files on disk, STDOUT handling, network resources, etc. all start to edge into system testing rather than unit testing. The setUp and tearDown abilities of Ceedling/Unity are intentionally limited as the sorts of struggles you initially discussed are better handled in system testing rather than unit testing.

Logging is often a bit of a gray zone, though. You are not the first or last to run into questions of how to handle logging in unit tests.

If it's helpful to you, here's a strategy I've used in the past (this may not apply in your case, of course):

1. Using macros or a compiled module create a logging interface with a different implementation in testing vs. release. For testing, this interface just collects logging strings into a buffer that can be ignored or tested for string correctness.
2. Reserve testing of the release logging for dedicated unit testing or some kind of system testing.

This sort of structure breaks any logging shared resource dependencies in nearly all or all of your unit tests. Focusing your special handling of logging testing in one place can make maintaining your suite much easier. This approach often also provides easy opportunities for more flexible logging in the future that you may come upon.