TinyOS 2.x Automated Unit Testing / TUnit

Let's face it.

Testing an open source embedded project like TinyOS is not easy.

Formal TinyOS testing in the past has been done by getting a group of people together and running a basic set of applications on a few platforms to see if they pass or fail. This worked, but required volunteers' time, and did not offer a very high granularity of testing. If something were to break, how would you know where and when it happened?

Informal testing was dependent on the TinyOS community. If something didn't work, the message boards were the place to make the problem known. Sometimes bugs are discovered, fixed, then rediscovered over and over. This makes it difficult for projects dependent upon the continuing reliability of TinyOS.

Now we have something better.

Although automated unit testing with TUnit doesn't promise to eliminate all bugs, it will help in improving the quality and robustness of the code developed by the TinyOS community. By having the ability to employ practices such as Extreme Programming and automated regression testing, the TinyOS baseline can become extremely stable, and stay that way.

If your project depends on TinyOS, you generally have two choices:

Take a snapshot of some TinyOS version at some random time, and use that TinyOS version throughout your project's lifetime. This means you take on the responsibility of maintaining your copy of TinyOS and finding/fixing any bugs that may have already been fixed in the baseline.
Continually update your project's TinyOS baseline throughout the lifetime of your project. This means you take on the responsibility of making sure your project's source code remains compatible with the latest TinyOS architecture and interfaces.

Case #1 may not be the best choice, because bugs do lurk around source code. Pretending like they don't exist is naïve and may come back to bite you later down the road.

Case #1 can be improved by having a solid TinyOS foundation to build upon, which is made possible through testing. Automated TUnit testing can help form that solid foundation.

Case #2 may not be the best choice either, because TinyOS is an evolving project. Bugs will get fixed over time, but interfaces and architecture will also change, leaving your project incompatible.

Case #2 can be improved by having a local set of unit tests in place that automatically check your project's compatibility with the TinyOS baseline (or any other dependent project). Automated TUnit testing will alert you to discrepencies that can be quickly fixed.

So we offer both. Publically, TinyOS is tested here with users' unit tests. Privately, you can check out and employ TUnit for free in your own proprietary projects.

This forms a solid foundation for TinyOS, as well as the reliability needed for your own code.

TUnit