Are you planning to update this test?

@C47D
Why is it need to be updated?

It doesn't test anything (I'm looking at master), you're asserting 0 is equal to 0.

void test_dropdown_set_text_and_symbol(void)
{
  TEST_ASSERT_EQUAL(0, 0);
}

Oh, it remained there by accident. I've just removed it.

It should be nice to add tests for fixed bugs, first we need to add a test that replicates the bug (this test should fail), then we make the bug fix, then the test should pass.

I agree, it'd be the ideal case. However, IMO before adding very special test cases it'd be better to add some simple tests for the simple features first.

To get started with we can even set up a a very simple goal: have at least a basic "render" test for every widget.
What do you think?

I agree, but what do you mean by render test?

I've been seeing some talks about how to test Qt projects, and I was thinking on using the same approach here. They don't tend to use screen captures.

I was thinking about #2522 when I made the previous comment. What arc properties controls the drawing direction of the arc, we could replicate the user issue with their code snippet and assert the expected propertie values. But I don't know how LVGL do that.

A lot of things can be tested by setting and getting properties. And IMO it should be the main approach when writing tests.

However comparing some screenshots will easily test a lot of things at once. E.g. widget creation, setting something, drawing, styles, position, size, etc.

Did a test for 2522, just to test the new test improvements, I got the value of expected_start_angle after running the test and letting it fail. But I don't understand why the value is 36, am I missing something?

Before the fix, lv_arc_get_angle_end returned 45.

#if LV_BUILD_TEST
#include "../lvgl.h"

#include "unity/unity.h"

void test_bugfix_for_2522(void);

void test_bugfix_for_2522(void)
{
    uint16_t expected_start_angle = 36;
    uint16_t expected_end_angle = 90;
    int16_t expected_value = 40;

    lv_obj_t *arcBlack;
    arcBlack = lv_arc_create(lv_scr_act());

    lv_arc_set_mode(arcBlack, LV_ARC_MODE_REVERSE);

    lv_arc_set_bg_angles(arcBlack, 0, 90);

    /* lv_arc_set_value calls value_update, where the fix is done */
    lv_arc_set_value(arcBlack, expected_value);

    TEST_ASSERT_EQUAL_UINT16(expected_start_angle, lv_arc_get_angle_start(arcBlack));
    TEST_ASSERT_EQUAL_UINT16(expected_end_angle, lv_arc_get_angle_end(arcBlack));
    TEST_ASSERT_EQUAL_INT16(expected_value, lv_arc_get_value(arcBlack));
}

#endif

I find this article very useful to assign names to test, maybe you find it interesting https://www.codurance.com/publications/2014/12/13/naming-test-classes-and-methods

@kisvegabor have you felt the need to add mocking capability to the test suite?

I've worked a bit with a framework named fff and CMock (also from ThrowTheSwitch). We could add asserts to be sure there are some function calls, with specific parameters and mocking return values.

For first I think we can test many things without mocking, but later it'll be surely required to make more isolated and specific tests.

If CMock has all the required features probably it should be added as it works well with Unity.

Do you have any priority list for adding tests? I've seen some interesting bugs in the calendar widget.

Also, one question, when the checkbox state is disabled and the user clicks on it, should it's event handler be called? I guess it shouldn't, but I'm not sure about that.

@C47D
Have you encountered the same bug as the one I have reported recently for the calendar widget?

Hi, no, but I was wondering if we can replicate it using unit tests.

Do you have any priority list for adding tests?

It's not a strong opinion but I think adding tests to the widgets is a good start because users have direct connection with them. So we test what is directly used, and we can find contributors easier to such tangible topic.

If the question is which widgets should be first, it doesn't really matter. If we get started with it all widgets should have test soon.