Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   C/C++ (http://www.chiefdelphi.com/forums/forumdisplay.php?f=183)
-   -   Unit Tests & Test-Driven Development (http://www.chiefdelphi.com/forums/showthread.php?t=111127)

William Kunkel 13-01-2013 01:43

Unit Tests & Test-Driven Development
 
Does anyone know of a sane way to write unit tests for robot code? I'd prefer to have a test-driven development cycle for our code, but I can't think of a good way to implement it for this kind of programming. There's a test harness project on FirstForge here, but it seems to be a dead project. Any ideas?

virtuald 13-01-2013 02:22

Re: Unit Tests & Test-Driven Development
 
Revive the project ;)

Spaghetti 13-01-2013 11:03

Re: Unit Tests & Test-Driven Development
 
Curious if short of emulating the robot like the test-harness project was trying for, does anyone have a nice flow for unit testing bits of logic sans crio that have no robot dependencies?

William Kunkel 13-01-2013 11:12

Re: Unit Tests & Test-Driven Development
 
I'd love to revive the project, but I don't think it's appropriate to do during build season.

virtuald 14-01-2013 13:08

Re: Unit Tests & Test-Driven Development
 
What we created for RobotPy users (python interpreter for cRio) is a library called fake-wpilib, which has bare implementations of most of the WPILib objects. You setup some hooks, import the robot code, and call StartCompetition(), and your unit tests have access to see/control everything.

We have implemented separately a tk-based program that allows our students to run their python robot code in a simulator of sorts, and they can drive the robot around and use sensors and such.

If I was re-implementing the test harness again for C++, this is probably how I would go about it. It seems like someone could create a script that could parse the C++ code and automatically create functional shells from that. Tools like SWIG and SIP sorta do that sort of thing, you would just need a mechanism to map function inputs to public variables.

Chris Hibner 14-01-2013 13:43

Re: Unit Tests & Test-Driven Development
 
The simplest way is to design your software units for test. What I mean is this: do NOT make any calls to the WPI library from within your unit. Make all calls to WPI library in a wrapper function.

For example:

Code:


void periodic_10ms_task(void)
{
    armAngle = WPI_readEncoder(ARM_ENCODER);
    armLimit = WPI_readDIO(ARM_LIMIT_SWITCH);

    armOutput = controlArm(armAngle, armLimit);

    WPI_setPWM(armOutput);
}

Before anyone complains: I don't really know what the WPI library function name are - the above names are made up (we use LabVIEW).

Now you can test you controlArm() function as a unit on a PC using MS VisualC++ Express.


All times are GMT -5. The time now is 18:23.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi