{"id":38499042,"url":"https://github.com/rdkcentral/ut-core","last_synced_at":"2026-01-17T05:57:42.308Z","repository":{"id":176960734,"uuid":"610375677","full_name":"rdkcentral/ut-core","owner":"rdkcentral","description":"Unit Test - Core Framework","archived":false,"fork":false,"pushed_at":"2025-12-05T11:52:26.000Z","size":696,"stargazers_count":4,"open_issues_count":21,"forks_count":2,"subscribers_count":7,"default_branch":"develop","last_synced_at":"2025-12-08T21:40:47.512Z","etag":null,"topics":["c","framework","testing"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rdkcentral.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":"NOTICE","maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-03-06T16:41:52.000Z","updated_at":"2025-12-05T11:52:14.000Z","dependencies_parsed_at":"2024-01-03T00:08:00.943Z","dependency_job_id":"a241fe77-2ba9-4118-ab5a-6a8218da832a","html_url":"https://github.com/rdkcentral/ut-core","commit_stats":null,"previous_names":["rdkcentral/ut-core"],"tags_count":33,"template":false,"template_full_name":null,"purl":"pkg:github/rdkcentral/ut-core","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Fut-core","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Fut-core/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Fut-core/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Fut-core/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rdkcentral","download_url":"https://codeload.github.com/rdkcentral/ut-core/tar.gz/refs/heads/develop","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rdkcentral%2Fut-core/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28501351,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T04:31:57.058Z","status":"ssl_error","status_checked_at":"2026-01-17T04:31:45.816Z","response_time":85,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c","framework","testing"],"created_at":"2026-01-17T05:57:42.220Z","updated_at":"2026-01-17T05:57:42.279Z","avatar_url":"https://github.com/rdkcentral.png","language":"C","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Unit Testing - Hal Testing Suite\n\n| Date (DD/MM/YY)  | Comment | Document Version |\n|--------|---------|---------|\n| 19/02/25 | Updated link for Groups in UT Core | 2.1.0 |\n| 24/12/24 | Updated usage of Weak Library | 2.0.3 |\n| 07/11/24 | Updated How to use Autogenerate script url | 2.0.2|\n| 19/06/24 | Extended LD_LIBRARY_PATH | 2.0.1|\n| 02/01/24 | Added Release Notes | 2.0.0|\n| 06/10/23 | Initial release| 1.2.0|\n| 23/02/23 | Reviewed \u0026 Updated| 1.1.0|\n| 30/09/22 | Initial release| 1.0.0|\n\n## Scope\n\nTo develop a L1, L2 testing suite to support vendor deliverables. This combines API Documentation, Specifications and Tests, delivered without infrastructure and RDK framework requirements.\n\nPlease refer to the release notes here :- [RELEASE.md](./RELEASE.md), for information on latest releases.\n\n## HAL Scope\n\nEach of the HALS will use the hal `UT-Core` framework, it will provide all the configuration required to support building and running a common testing environment.\n\nEach HAL component definition, will have individual cadence, specific documentation, and tagged testing suites to support them. All code is shared in the `rdkcentral` git hub.\n\n- [Test Framework URL - GitHub](https://github.com/search?q=org%3Ardkcentral+hal\u0026type=repositories)\n\nThe naming convention chosen will allow for future convergence of the RDK-B/RDK-V/RDK-X stack into a single component based definition.\n\nIdeal Naming convention as follows:-\n\n```bash\n- hal-\u003ccomponentName\u003e\n- haltest-\u003ccomponentName\u003e\n```\n\n## Build Environment Requirements\n\nIn order to build the tests files, there is a requirement to supply the toolchain, either as a vendor independent toolchain, an SDK, or an RDK toolchain.\n\nThe `ut` for a given module is triggered from scripts / makefiles which clone the `ut-core` framework, and then build the tests defined.\n\nThis allows the `ut-core` framework to be upgraded over time, and have independence of the `ut` unit being tested.\n\nScript templates are provided to show examples files that will be required of reach layer, starting from the hal.\n\nTesting relationship is as follows:-\n\n```mermaid\nerDiagram\n        HAL }|..|{ hal_ut: triggers\n        hal_ut }|--o{ ut_core: uses\n```\n\n```bash\n├── template\n│   ├── api_definition_template -\u003e example trigger files for the top level `API` directories\n│   └── ut_template -\u003e example component specific files for the ut directories\n```\n\n### SDK Toolchain\n\nAm example toolchain is provided for RDK-B, and this is located in github at the below address.\n\n### Core UT Framework\n\nUnit testing core subsystem is available from the following location\n\n[https://github.com/rdkcentral/ut-core]\n\nCloning the core ut-code is available from here:\n\n```bash\ngit clone git@github.com:rdkcentral/ut-core\n```\n\nIt is recommended that you read the documentation :-\n\n- [https://github.com/rdkcentral/ut-core/blob/master/README.md]\n- [https://github.com/rdkcentral/ut-core/blob/master/docs/pages/hal_unit_testing_requirements.md]\n\n```bash\n.\n├── docs\n│   └── pages\n│       └── images\n├── framework\n│   └── cunit\n│       ├── arm-rdk-linux-gnueabi -\u003e Arm prebuild version of cunit.so\n│       └── i686-pc-linux-gnu -\u003e -\u003e Linux prebuild version of cunit.so\n│   └── xxx -\u003e Other framework as required\n├── include -\u003e ut-core header files\n├── src     -\u003e ut-core source files\n├── template\n│   ├── hal_template -\u003e example files for the top level hal directories\n│   └── ut_template -\u003e example files for the ut directories\n└── tools\n├── libs -\u003e (Vendor .so)\n├── Makefile\n\n```\n\nIn order to build the `vendor`, or the `developer` will need to provide any of the following requirements.\n\n1) prebuilt libraries which as part of the SDK\n2) prebuilt libraries to be linked against in the libs directory\n3) link libs directory to built libraries being worked on in RDK Tree.\n\n`libs`, can be either linked to a prebuilt generated by the vendor, or by the RDK build system.\n\ne.g.\n\n```build-skysr300/tmp/work/armv7at2-neon-rdkmllib32-linux-gnueabi/lib32-hal-wifi-sky/1.99+git999-r0/hal-wifi-sky-1.99+git999/.libs/```\n\n`ln -s \u003csource\u003e \u003cdestination\u003e` can be used to setup these directories\n\n### Toolchain\n\nToolchain is provided by the vendor, or via an SDK build in the Yocto build system for the given platform.\n\nRecommand to install the toolchain into `./tools/2.0` directory\n\nFollow the standard build instructions for generating an SDK for your platform, and installing and triggering the toolchain.\n\n#### How to use SDK Toolchain\n\n```bash\n./rdk-glibc-x86_64-arm-toolchain-2.0.sh\n```\n\nThis will install the toolchain, `sysroots` etc into `/opt/rdk/2.0` by default, but it's recommended that that you change this to `${PWD}../2.0` folder in your linux machine.\n\nExample output\n\n```bash\nRDK (A Yocto Project based Distro) SDK installer version 2.0\n\n============================================================\nEnter target directory for SDK (default: /opt/rdk/2.0):\nYou are about to install the SDK to \"/opt/rdk/2.0\". Proceed \\[Y/n\\]? Y\n`\\[sudo\\] password for xxxx:`\nExtracting SDK..............................................................................done\nSetting it up...done\nSDK has been successfully set up and is ready to be used.\nEach time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.\n\n. /opt/rdk/2.0/environment-setup-cortexa9t2-vfp-rdk-linux-gnueabi\n```\n\n4.Once to use cross development toolchain in the current shell, you need to source the environment setup script.\n\n```bash\nchmod +x /opt/rdk/2.0/environment-setup-cortexa9t2-vfp-rdk-linux-gnueabi`\nsource /opt/rdk/2.0/environment-setup-cortexa9t2-vfp-rdk-linux-gnueabi\necho $CC\n```\n\n```bash\narm-rdk-linux-gnueabi-gcc -mthumb -mfpu=vfp -mcpu=cortex-a9 -mfloat-abi=soft -mabi=aapcs-linux -mno-thumb-interwork -ffixed-r8 -fomit-frame-pointer --sysroot=/opt/rdk/2.0/sysroots/cortexa9t2-vfp-rdk-linux-gnueabi\n```\n\n## Testing Environment\n\n## Making the code\n\nThere are two targets for the platform\n\n1. linux - (default) will build all the tests, the test_app, and the stubs\n2. arm - TARGET=arm, will build all the tests, and the test_app for the target\n\n```bash\nmake clean\n```\n\nis not required unless you swap between targets or wish to clean\n\n### Build the `linux` environment with C language\n\n```bash\nmake\n```\n\nThis will build the following directories `src/*.c`, in addition to core functions from `ut-core/src/c_source` and linking against libraries in `ut-core/framework`\n\n`skeletons/src` - will be included in the linux build to enable stubs to compile against\n\n### Build the target `arm` environment with C language\n\nThe toolchain must be sourced as above, once sources though swapping between linux \u0026 arm is possible as required.\n\n```bash\nmake TARGET=arm\n```\n\nThis will build the following directories `src/*.c`, in addition to core functions from `ut-core/src/c_source` and linking against libraries in `ut-core/framework` and link against `libs/.so` or from `sysroot` path in the SDK.\n\nThe final output binary is build as `hal_test` and resides in the `bin` directory, the framework .so files will be copied to the same directory.\n\n### Build the `linux` environment with CPP language\n\n```bash\nmake VARIANT=CPP\n```\n\nThis will build the following directories `src/*.c`, in addition to core functions from `ut-core/src/cpp_source` and linking against libraries in `ut-core/framework`\n\n`skeletons/src` - will be included in the linux build to enable stubs to compile against\n\n### Build the target `arm` environment with CPP language\n\nThe toolchain must be sourced as above, once sources though swapping between linux \u0026 arm is possible as required.\n\n```bash\nmake VARIANT=CPP TARGET=arm\n```\n\nThis will build the following directories `src/*.c`, in addition to core functions from `ut-core/src/cpp_source` and linking against libraries in `ut-core/framework` and link against `libs/.so` or from `sysroot` path in the SDK.\n\nThe final output binary is build as `hal_test` and resides in the `bin` directory, the framework .so files will be copied to the same directory.\n\n### Feature: `BUILD_WEAK_STUBS_SRC` for Weak Library Compilation\n\nThe `BUILD_WEAK_STUBS_SRC` variable enables clients to define and export a list of source files that will be compiled into a weak library. This allows testing suites to use stubbed implementations of functions during development, with the strong implementation provided by vendors or third parties at a later stage.\n\n#### Benefits:\n1. **Supports Testing Development**: Enables testing suites to run without waiting for strong implementations.\n2. **Decouples Development**: Testing can proceed independently of vendor timelines.\n3. **Seamless Replacement**: Strong implementations can replace weak stubs without changes to the testing suites.\n\n#### Key Makefile Logic:\n```make\nWEAK_STUBS_LIB := $(LIB_DIR)/libweak_stubs_libs.so\nWEAK_STUBS_OUTPUT_DIR ?= $(BUILD_DIR)/weak_stubs/src\nWEAK_STUBS_SRC := $(shell find $(BUILD_WEAK_STUBS_SRC) -name *.c)\nWEAK_STUBS_OBJ := $(patsubst $(BUILD_WEAK_STUBS_SRC)/%, $(WEAK_STUBS_OUTPUT_DIR)/%, $(WEAK_STUBS_SRC:.c=.o))\n```\n- `BUILD_WEAK_STUBS_SRC`: Path to source files for weak stubs.\n- `WEAK_STUBS_LIB`: Compiled weak library (`libweak_stubs_libs.so`).\n- `WEAK_STUBS_SRC` and `WEAK_STUBS_OBJ`: Dynamically map source to object files.\n\n#### Workflow:\n1. **Define Stubs**: Clients export `BUILD_WEAK_STUBS_SRC` with the path to stub source files.\n   ```bash\n   export BUILD_WEAK_STUBS_SRC=/path/to/stubs\n   ```\n2. **Build Library**: The Makefile compiles the stubs into a weak library.\n3. **Develop and Test**: Testing suites use the weak library.\n4. **Integrate Strong Implementation**: Vendors replace the weak stubs when ready.\n\nThis approach ensures smooth testing suite development while awaiting third-party components.\n\n## Running on the target\n\nCopy files from `bin/*` to the target.\n\nLog into the target.\n\nAssuming the files that are copied are in the `/home/root` directory, then the following export is required.\n\n- `ut_control` sub-library, located in the `framework` directory, is required for running the target binary. `LD_LIBRARY_PATH` must be set to include it\"\n- All external library dependencies are copied into the `ut/bin` directory\n\n```bash\nexport LD_LIBRARY_PATH=/usr/lib:/lib:/home/root:./\n```\n\nor use the `run.sh`, which is in the same directory\n\nNow the hal test can be executed, `-h` for help is supported.\n\n```bash\n./hal_test  -h\nHelp\n-c - Console Mode (Default)\n-a - Automated Mode\n-b - Basic Mode\n-f - \u003cfilename\u003e - set the output filename for automated mode\n-l - List all tests run to a file\n-h - Help\n```\n\n### Modes of operation\n\n1. Console Mode - will open the interactive console\n2. Automated Mode - will output in xUnit form as a .xml file\n3. Basic Mode - All tests will be ran and the output redirected to the shell\n\n## Source Tree `UT` Unit Test Directory\n\nThe tests are defined into the following structure, as per the template from `template/ut_template/`\n, which can be copied to the root directory if your specific `haltest-xxx` directory for a baseline.\n\n ```bash\n├── bin\n│   └── run.sh\n├── build.sh\n├── docs\n│   ├── generate_docs.sh\n│   └── pages\n│       ├── L1_TestSpecification.md\n│       ├── L2_TestSpecification.md\n│       └── README.md -\u003e ../../README.md\n├── Makefile\n├── README.md\n├── skeletons\n│   └── src\n├── src\n│   ├── main.c\n│   ├── test_l1_test_example.c\n│   └── test_l2_tests_example.c\n└── tools\n```\n\nThe main launch point test application, will configure the test system install the framework and register the tests.\n\n```bash\n├── src\n│   ├── main.c\n```\n\nThe main test app will register all the tests and kick off the framework.\n\n```c\n    UT_status_t status;\n    status = UT_init( argc, argv );\n    if ( status != UT_STATUS_OK )\n    {\n      /* UT Initialise failed */\n      return -1;\n    }\n\n    register_hal_l1_tests();\n    register_hal_l2_tests();\n\n    UT_run_tests();\n```\n\n### Choosing a Major Version of the UT-Core\n\nSince the ut-core interfaces will change over time, and in order to be consistant when creating tests engineers should select the major release they wish to fixed too. (Although it's recommended to periodically upgrade to a later revision )\n\nThe interface will not change between minor versions, but the most recent bugfix version should be selected.\n\nThe versioning format for the testing suites is therefore `\u003cmajor.minor.bugfix/patch/documentation\u003e`\n\nIn the file `ut_template/build.sh` you can see the template version of the script.\n\nThis is selected via `UT_CORE_PROJECT_VERSION` variable as an input in the default build script for the tests suite e.g. `ut/build.sh UT_CORE_PROJECT_VERSION=2.0.0` or by changing the fixed version set in your unit testing `build.sh` trigger script.\n\nFor best practice and receive bug fixes define `UT_PROJECT_MAJOR_VERSION` in `ut/build.sh` to choose the major revision that the testing suite should compile against.\n`ut-core` will assure backwards compatibility in major versions. This means that the bugfixes and minor changes you will automatically acquire on the next test run.\n\n```bash\n# Change this to upgrade your UT-Core Major versions. Non ABI Changes 1.x.x are supported, between major revisions\nUT_PROJECT_MAJOR_VERSION=\"1.\"\n```\n\n### Example of registering test functions with the framework is\n\n```c\n#include \u003cstring.h\u003e\n#include \u003cstdlib.h\u003e\n\n#include \u003cut.h\u003e\n\nvoid test_l1_function1(void)\n{\n  UT_FAIL(\"Need to implement\");\n  /* Positive */\n  /* Negative */\n} \n\nvoid test_l1_function2(void)\n{\n  UT_FAIL(\"Need to implement\");\n  /* Positive */\n  /* Negative */\n} \n\nstatic UT_test_suite_t *pSuite = NULL;\n\n/**\n * @brief Register the main tests for this module\n * \n * @return int - 0 on success, otherwise failure\n */\nint test_l1_register( void )\n{\n    /* add a suite to the registry */\n    pSuite = UT_add_suite(\"[L1 test_Example]\", NULL, NULL);\n    if (NULL == pSuite) \n    {\n        return -1;\n    }\n\n    UT_add_test( pSuite, \"blah_level1_test_function\", test_l1_function1);\n    UT_add_test( pSuite, \"blah_level1_test_function\", test_l1_function2);\n\n    return 0;\n}\n```\n\nEach module has a optional `init` and `clean` function, which can be setup via UT_add_suite(), in the above example these are defaulted to `NULL`, since in this example case they are not used.\n\n## Groups in UT Core\nUT Core's test suite grouping enables efficient, targeted testing by allowing developers to organize and run only\nrelevant tests, saving time and resources.\n\nMore information can be found in: [UTCore: Test Group Support](https://github.com/rdkcentral/ut-core/wiki/UTCore:-Test-Group-Support)\n\n## Testing\n\nThe current file by file, and function by function, may not be the ideal way to support all L1 testing, since calling all functions without the init being called, is likely a requirement.\n\nOther files maybe required, users should use their own description and best practices to perform and implement tests.\n\n## Level 1 Testing - Functional Testing\n\nThe Level 1 testing suit will be classed as functional tests. The main goal of the tests are:\n\n- Max / Min parameter testing should be performed for every function\n- Passing invalid parameters (negative testing)\n  - Passing invalid parameters, every function should fail as per the documentation\n  - Every parameter should be tested for an invalid valid\n- Passing Correct parameters (Positive testing)\n  - Passing correct parameters\n  - Checking from the box if possible is the actions have been performed correctly via other means, e.g. command line.\n\n## Level 2 Testing - Module Testing\n\nThe purpose of the test level is to test the module functionality as much as possible from an operational point of view.\n\n- independent test application that will run and build without the RDK on platform\n- The application can be copied after building to a running box.\n- Application will perform the startup requirements for the section of the HAL required to test, in order to perform Black Box Testing\n- Features to be defined on whether it can be functionally tested or not.\n\n## Autogen scripts\n\nPlease refer to [Running-the-Framework-Generation-Script](https://github.com/rdkcentral/ut-core/wiki/autogenerate.sh:-Running-the-Framework-Generation-Script)\n\n## UT-Core testing suite\n\nThe testing suite to check the ut-core functionality is housed under the `tests` directory and will run in linux.\n\nTo build and run the testing suite and output in basic mode do the following\n\n```bash\ncd ./tests\nmake\n./bin/ut-tests -b\n``````\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frdkcentral%2Fut-core","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frdkcentral%2Fut-core","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frdkcentral%2Fut-core/lists"}