Skip to content
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

Open
skliper opened this issue Sep 30, 2019 · 4 comments
Open

OSAL PPC VxWorks "test runner" #44

skliper opened this issue Sep 30, 2019 · 4 comments

Comments

@skliper
Copy link
Contributor

skliper commented Sep 30, 2019

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:

  • Observe the value of (int)OS_BSPMain
  • issue ld < testname.elf command
  • Watch out for any ''undefined symbol'' errors
  • Verify that (int)OS_BSPMain changed
  • issue sp(OS_BSPMain) command
  • Monitor console output watching for the test to finish
  • perhaps reboot the target if things went horribly wrong

Running 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 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.

@skliper skliper self-assigned this Sep 30, 2019
@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

Imported from trac issue 21. Created by glimes on 2015-02-25T18:23:31, last modified: 2019-08-14T14:11:46

@skliper
Copy link
Contributor Author

skliper commented Sep 30, 2019

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).

@skliper skliper removed their assignment Sep 30, 2019
@skliper
Copy link
Contributor Author

skliper commented Oct 22, 2019

@jphickey you don't need this anymore right? I assume with the setup you've got working now this ticket no longer applies.

@jphickey
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants