Roundtrip tests between different Py versions

[oberstet]

Split out from #11

I only have sketchy knowledge about dbus and stuff, haven't looked deeply enough into the txdbus codebase, but are the unit tests actually talk to a real dbus? and if so, are there tests that

• roundtrip Py2 -> dbus -> Py2 (and Py3 -> dbus -> Py3) - eg both a proc implemented in Py and called from Py
• roundtrip Py2 -> dbus -> Py3 (and Py3 -> dbus -> Py2)

What I meant with round-tripping is between different Python versions.

Like have a procedure implemented in Python 3, exposed via Dbus, and being called from Python 2.

Where the procedure name is a fancy Unicode name, and/or the procedure takes an Unicode argument (and the test actually uses non-US-ASCII characters) and/or the procedure takes a binary argument (and the test actually uses a binary value which isn't valid UTF8).

[cocagne]

The py2->py2 and py3->py3 is covered by simply running the tests with both py2 and py3 interpreters. Mixed py2/py3 would definitely be a good thing to try but I'm not really sure how one would go about doing that in a unit test framework I suppose a sub-process could be spun off within the context of a unit test, assuming the test environment has a suitable alternative interpreter installed with the necessary dependencies? Seem like an assumption that would frequently prove invalid though.

…

On Wed, Jun 7, 2017 at 6:36 AM, Tobias Oberstein ***@***.***> wrote: Split out from #11 <#11> I only have sketchy knowledge about dbus and stuff, haven't looked deeply enough into the txdbus codebase, but are the unit tests actually talk to a real dbus? and if so, are there tests that - roundtrip Py2 -> dbus -> Py2 (and Py3 -> dbus -> Py3) - eg both a proc implemented in Py and called from Py - roundtrip Py2 -> dbus -> Py3 (and Py3 -> dbus -> Py2) What I meant with round-tripping is between different Python versions. Like have a procedure implemented in Python 3, exposed via Dbus, and being called from Python 2. Where the procedure name is a fancy Unicode name, and/or the procedure takes an Unicode argument (and the test actually uses non-US-ASCII characters) and/or the procedure takes a binary argument (and the test actually uses a binary value which isn't valid UTF8). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#69>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABrLfMxUphp8gSV4Kq6pE42OdS5_Fbd4ks5sBoslgaJpZM4Nyk1G> .

[oberstet]

Regarding round-tripping tests on same Python version, is the following a glitch? A bytes value of length 0 (b'') behaves differently on the two:

• https://gist.github.com/oberstet/1be3576f0ef4f51335ae9e18da3872e0
• https://gist.github.com/oberstet/4a2c55f5dbb5c31df140aedf98035b34
• https://gist.github.com/oberstet/8d637a488f7073a60500b8fdd5927ecc

Testing across different Python version is more complicated, I agree. One way that should work would be creating two virtualenv inside the Travis CI container with two different Python versions, and then drive the test from either side, effectively testing Python 2 unit tests versus Python 3 txdbus and vice versa. If we could do that, and have a single code base for both the library and the unit tests, then I think that would clearly demonstrate full support for both Python versions.

[WhyNotHugo]

I agree that there's a bug here (which is kinda obvious since our behaviour/results vary across python versions).

However, I'm not sure that sending 'Hello-µ@ßöäüàá-UTF-8!!' should fail. The spec says that Unicode-escaping is valid, so that should not fail if we send that text Unicode-escaped (which I'd have to check the source to see if we're doing or not). Based on that, we can assert if the python2 version is misbehaving or the python3 version is.