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

Denis Shienkov denis.shienkov at gmail.com
Wed Jan 22 19:06:03 CET 2014


 > 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.

The short instruction how to setup and configure the "com0com" software 
is here:

https://codereview.qt-project.org/#change,65431

For this purpose it is enough to have a host with any Windows x32. 
Windows x64 doesn't suit for this purpose because "com0com" is delivered 
with unsigned drivers which won't work there.

As a result, the principal thing is the configuring of the CI hosts 
(setup an ENV variables of QTEST_SERIALPORT_SENDER, 
QTEST_SERIALPORT_RECEIVER, and etc.). I don't know how to do it on CI, 
so an help (and some work) from the Digia is necessary, IMHO.


Thiago, Oswald, Digia, Others,

what do you think about it? IMHO, it is impossible to delays with this 
issue more (1~2 years it is too long)...

If you agree with passes of names of serial ports to tests through ENV, 
then we can start of implementation a set of the minimal tests (even if 
CI is yet ready). Can you comment it?

Best regards,
Denis

16.01.2014 13:26, Laszlo Papp пишет:
> 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