If you run an “embedded/components/sauce/test_tomatos” test, PlatformIO willĬheck folders for the unity_config.h in the following order: Let’s take a look at the Pizza Project from the Test HierarchyĮxample. The unity_config.h is missed, PlatformIO will walk through the test hierarchy It looks for a custom unity_config.h in a current test folder. PlatformIO’s Unity test runner comes with an already defined UNITY_INCLUDE_CONFIG_H Via C defines, you can pass most of these options to the build_flags. #include "unity.h" #include "file_to_test.h" void setUp ( void ) Īll of Unity’s configuration options are #defines. When you’re done, your test file will look something like this: Please remember to add each test to the main function. Important that each function gets its own RUN_TEST call. This is what will actually trigger each of those test functions to run, so it is This function will call UNITY_BEGIN(), then RUN_TEST ( setup() / loop() for Arduino, app_main() forĮspressif IoT Development Framework). Test functions take no arguments and return nothing.Īll test accounting is handled internally in Unity.įinally, at the bottom of your test file, you will write a main() function You don’t HAVE to name them this way, but it makes it clear what functions are testsįor other developers. Test functions follow the convention of starting with the word test_ or spec_. The majority of the file will be a series of test functions. You may leave either or both of these blank if you have no need for them. The tearDown function can contain anything you would like to run after each test.īoth functions accept no arguments and return nothing. The setUp function can contain anything you would like to run before each test. Next, a test file will include a setUp() and tearDown() function. The test file should include unity.h and the header Most often you will create a single test file for each C/C++Ĭomponent that you want to test.
0 Comments
Leave a Reply. |