Automation for VxWork Runtime Application - VxWorks

This is a discussion on Automation for VxWork Runtime Application - VxWorks ; Hi All, Is there any automation tool that we could use to test VxWork Runtime Application? Best Regards,...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Automation for VxWork Runtime Application

  1. Automation for VxWork Runtime Application

    Hi All,

    Is there any automation tool that we could use to test VxWork Runtime
    Application?

    Best Regards,


  2. Re: Automation for VxWork Runtime Application

    Hi:

    There are a few tools meant for unit and module testing code that has
    been developed. Most rely on expected vs actual results of calls to
    functions to verify correctness. Some can generate test cases
    automatically, and some are totally manual. I've used or done evals on
    a couple of the more popular one (VectorCast from Vector Software,
    tbrun from LDRA software, and CrossTest). These all work with Tornado.

    They are useful if you like to run regression tests, as most have the
    ability to automatically run and determine if correctness has been
    maintained when code changes.

    Good luck,
    lc


  3. Re: Automation for VxWork Runtime Application

    Hi:

    There are a few tools meant for unit and module testing code that has
    been developed. Most rely on expected vs actual results of calls to
    functions to verify correctness. Some can generate test cases
    automatically, and some are totally manual. I've used or done evals on
    a couple of the more popular one (VectorCast from Vector Software,
    tbrun from LDRA software, and CrossTest). These all work with Tornado.

    They are useful if you like to run regression tests, as most have the
    ability to automatically run and determine if correctness has been
    maintained when code changes.

    Good luck,
    lc


  4. Re: Automation for VxWork Runtime Application

    We have modified cppunitlite (you may have to search a bit to find the
    original source distribution) for our unit tests.

    The big problem with the TDD movement for embedded developers is the
    time required to edit, compile and reload the target. It isn't as
    efficient as desktop or webapp development. This means that hard core
    TDD where you -- write a single test, confirm that it fails, write code
    to make the test work, next test -- is really inefficient. We've long
    since left behind scenarios where host simulation is an option.

    cppunitlite is a nice compromise for me, I can make TDD a little more
    efficient for embedded development. Developers run unit tests before
    they checkin. We also execute them within our automated builds. they
    are compiled out for production releases. It's one of the best
    improvements we ever made to our development environment.


+ Reply to Thread