Open skliper opened 5 years ago
Imported from trac issue 21. Created by glimes on 2015-02-25T18:23:31, last modified: 2019-08-14T14:11:46
Trac comment by glimes on 2015-02-25 21:04:49:
I've settled on addressing this with a simple program resident in the "cfs_test" repository alongside the test support code for OSAL which can be compiled for and deployed to an embedded target, which can run existing unit tests (once other fixes have been applied to OSAL to allow the tests to build properly).
@jphickey you don't need this anymore right? I assume with the setup you've got working now this ticket no longer applies.
For all the unit testing of the VxWorks PPC code, I just did the manual method of invoking "ld < test.exe" followed by calling the test entry point from the shell. It works but it is tedious and time consuming and easy to miss something.
It would be nice if this was more scripted/automatic to make running all the UT code on VxWorks easier. So I do think this or something like it would be useful, as it would allow us to test more frequently with less developer time used which is always a good thing.
Independent of any other issues with building test code for the PowerPC running VxWorks -- it appears that I will need a small bit of "helper code" in order to make my testing environment a little bit more robust.
Currently, running a unit test requires someone, by hand, to do the following steps for each test:
(int)OS_BSPMain
ld < testname.elf
command(int)OS_BSPMain
changedsp(OS_BSPMain)
commandRunning the tests by calling
OS_BSPMain()
directly from the shell introduces problems if the test program makes any changes in the task that disturb the shell -- most notably, if the task callsexit()
all bets are off.What I want in a "test runner" is to have code that supervises loading of the program, detects any load errors, and assures that the loaded image provides a suitable entry point. If all is good, start the test as a subtask. The runner needs to then wait for the task to complete, which unfortunately requires it to periodically test to see if the task is still alive.
A nice thing to have for this sort of facility is a timeout, which turns out to be pretty trivial given that we have to drop into a polling loop. If we loop too long, we can kill off the task and make appropriate log annotations.
The initial runner I envision is simply an image to be loaded after the target boots, exporting a function that does the work for one test, coupled with a script that loads the image and calls the function for each test to be run.