Embedded Linux. Can I use unit tests for the telnet target

Sysprogs forums Forums VisualGDB Embedded Linux. Can I use unit tests for the telnet target

This topic contains 4 replies, has 2 voices, and was last updated by  support 11 months, 2 weeks ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #27842

    viordash
    Participant

    To debug and deploy code on my device (Soc Hi3518) I use telnet transport (https://visualgdb.com/tutorials/custom/transports/). SSH is not available

    How I can use the unit testing in this environment? When I make Run All, I see output, “Pipe-based test reporting only supported on SSH-based Linux targets

     

    #27856

    support
    Keymaster

    Hi,

    This error happens because the tests use a separate pipe (created with mkfifo) to report structured tests outputs to VisualGDB, and telnet doesn’t allow easily multiplexing multiple streams.

    Does your target have mkfifo + netcat installed? If yes, please try checking if you can launch netcat in the background over telnet and let it forward a mkfifo-ed pipe to TCP. If yes, we can extend the custom target interface to allow running unit tests (your implementation would need to “open” a remote pipe and return a .Net Stream object corresponding to it, that will be independent from the regular telnet output).

    #27860

    viordash
    Participant

    I’ll do it later and let you know

    #30940

    viordash
    Participant

    Hi
    Sorry for the long absence.
    I have checked the utilities you mentioned, mkfifo + netcat. They are in the system and work.
    I would be very grateful if you extend the custom target interface so that I can fully run tests

    #30958

    support
    Keymaster

    No problem and thanks for your pull request with adding proper timeout handling to the telnet target.

    We have added a new ITargetWithRawPipes interface to VisualGDBExtensibility.dll that should be implemented by the telnet target:

    VisualGDB will call the OpenPipeForReading() method, supplying it the full path of the pipe on the Linux machine (e.g. /tmp/pipe). The target should open it and return a readable stream that VisualGDB will read from a background thread.

    Note that the pipe output can contain arbitrary bytes and not just printable characters, so the target may need special handling to escape/unescape them properly. We highly advise testing it by reading a test file containing all possible 256 byte values.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.