-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OSAL PPC VxWorks "test runner" #44
Comments
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 fromthe shell introduces problems if the test program makes any
changes in the task that disturb the shell -- most notably,
if the task calls
exit()
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.
The text was updated successfully, but these errors were encountered: