ThrowTheSwitch / Unity

Simple Unit Testing for C
ThrowTheSwitch.org
MIT License
4.12k stars 984 forks source link

Avoid running the setup for some specific tests #716

Closed parmi93 closed 9 months ago

parmi93 commented 9 months ago
TEST_GROUP(tracelog_manager);

TEST_SETUP(tracelog_manager)
{
    trg_init();
}

TEST_TEAR_DOWN(tracelog_manager)
{
    trg_uninit();
}

TEST(tracelog_manager, check_status_before_and_after_successful_initialization)
{
    trg_status_t status = trg_status();
    TEST_ASSERT_EQUAL_INT(TRG_UNINITIALIZED, status);

    status = trg_init();
    TEST_ASSERT_EQUAL_INT(TRG_INITIALIZED, status);

    status = trg_status();
    TEST_ASSERT_EQUAL_INT(TRG_INITIALIZED, status);
}

TEST(tracelog_manager, check_status_after_not_successful_initialization)
{
    //Do something to make the initialization fail

    trg_status_t status = trg_init();
    TEST_ASSERT_EQUAL_INT(TRG_INIT_FAILED, status);

    status = trg_status();
    TEST_ASSERT_EQUAL_INT(TRG_INIT_FAILED, status);
}

TEST(tracelog_manager, check_status_after_successful_uninitialization)
{
    trg_status_t status = trg_uninit();
    TEST_ASSERT_EQUAL_INT(TRG_UNINITIALIZED, status);

    status = trg_status();
    TEST_ASSERT_EQUAL_INT(TRG_UNINITIALIZED, status);
}

Is there a way to tell Unity not to run TEST_SETUP for the check_status_before_and_after_successful_initialization and check_status_after_not_successful_initialization tests?

I have considered some workarounds, such as moving these tests directly into the TEST_SETUP, but I don't like the idea because it doesn't increase the total test counter, furthermore the TEST_SETUP is designed to execute a set-up and not to execute tests.

Another workaround I considered is to call trg_uninit() before running this specific tests, in an attempt to bring the tracelog_manager library back to its "initial state", but even in this case I don't like the idea because I'm changing the internal state of the library, and I'm not testing the production code properly.

Letme commented 9 months ago

If you just want to waiver off the failed tests temporary, you can use https://github.com/melexis/warnings-plugin . That way you can allow 2 failures, but the tests will still run, which also means if you use exact number of warnings will tell you when your tests were fixed.

Not sure what root cause would be and why dont you maybe split those tests into a separate file and exclude running them from build system. Much easier than having C code toggle these decisions imo.

mvandervoord commented 9 months ago

One option might be to create a new TEST_GROUP for those two tests? The purpose of the TEST_GROUP macro is to lump tests together that have similar needs... In this case, your first two tests have different needs than the others?

Mark

On Mon, Feb 5, 2024 at 8:40 AM Crt Mori @.***> wrote:

If you just want to waiver off the failed tests temporary, you can use https://github.com/melexis/warnings-plugin . That way you can allow 2 failures, but the tests will still run, which also means if you use exact number of warnings will tell you when your tests were fixed.

Not sure what root cause would be and why dont you maybe split those tests into a separate file and exclude running them from build system. Much easier than having C code toggle these decisions imo.

— Reply to this email directly, view it on GitHub https://github.com/ThrowTheSwitch/Unity/issues/716#issuecomment-1927036599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEA7ZES3CMMQVX23WYLJDYSDONPAVCNFSM6AAAAABC2CEOV6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRXGAZTMNJZHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

parmi93 commented 9 months ago

I don't know why I didn't think of it, creating a new group for these specific tests is a good idea (it's the first time I've attempted to use a unit testing framework).

Many thanks =)