[Development] [QtSerialPort] Add some set of base auto tests

Laszlo Papp lpapp at kde.org
Thu Jan 16 10:26:44 CET 2014


It had been discussed on this list about 1-2 years ago (if memory
serves well), and the common consensus was to use com0com on Windows
and some VT alike option on Linux. I do not think the technology
changed much, so it is probably still the best option... In my opinion
though, the best and easiest option would be socat on Linux. That can
elegantly create pseudo terminals for this purpose.

I was writing some unit tests last year targeting the replacement of
socat internally, but it turned out a bit complex, so I lost
motivation. In theory, it would be possible to use an internal "socat"
functionality without requiring external dependencies, so the init and
tear down would take over the responsibility for this, but it is not
that urgent. It is probably not an issue on Linux to setup socat, but
I will leave that the decision with the CI contributors.

As mentioned on Gerrit before, I was discussing it with Simo, but the
problem is really that we neither had anything integrated, nor
instructions how to set it up... Those are necessary to get done
before requesting any further steps on the CI side.

In the long future, my opinion is to get QtMock up to the speed,
preferably using the llvm C++ parser (which was not option back then
when I thought abut it), and then we could remove all this workaround
with a cross-platform solution which is not only useful for
QtSerialPort.

On Tue, Jan 14, 2014 at 8:14 AM, Denis Shienkov
<denis.shienkov at gmail.com> wrote:
> Hi developers.
>
> I want to bring up a question of possibility of addition of some base tests
> for QtSerialPort. I understand that it is a complex challenge because for
> this purpose is desirable existence of at least two serial ports of devices
> which are connected by a Null-modem cable.
>
> But this problem can be bypassed by use of virtual devices which are
> provided with the software of some vendors,
> e.g.:
>
> * on Windows:
>
> - eltima virtual serial port driver: http://www.eltima.com/products/vspdxp/
> - hdd free virtual serial ports:
> http://www.hhdsoftware.com/free-virtual-serial-ports
> - com0com null modem emulator: http://sourceforge.net/projects/com0com/
> and others
>
> * on Linux:
>
> - tibbo virtual serial port driver:
> http://tibbo.com/downloads/soi/vspdl.html
>
> So, for a covering of the minimum basic tests I would choose com0com the
> project (because free) for windows and tibbo the project (but I yet didn't
> use it never) for linux. In this case on CI it is enough to install this
> software and to configure it.
>
> The main feature of tests for QtSerialPort is need of explicit specifying of
> names of serial ports for their use. So, our team had an idea to pass these
> names (two names at least) to tests through ENV.
>
> Please see an main ideas example with the tests here:
> https://codereview.qt-project.org/#change,65431
>
> At present behavior of tests such that in case of absence in ENV of the
> QTEST_SERIALPORT_SENDER and the QTEST_SERIALPORT_RECEIVER variables any
> tests will be skipped/ignored. Otherwise each test will take necessary
> device name from the necessary variable and to be executed.
>
> It allows to use these tests and to developers (for example for me) to make
> additional tests that cover the CI tests. Because I can setup as the real
> physical serial devices and as other software of the virtual serial devices
> (for example from Eltima and so forth), i.e. I have an more flexibility.
>
> Also it will be useful for other users who have other types of serial ports.
> They can execute these tests with the specific types of devices that have.
> Also it will be useful to have these tests available even if on CI them
> still isn't present because it will give the chance for the end users (or
> for developers) to test changes by means of the same test sets.
>
> Guys, I wait for your comments and sentences about it... Because it is
> necessary to solve something, otherwise it is impossible further to continue
> to work for the project since complexity increases... :(
>
> Best regards,
> Denis
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



More information about the Development mailing list