----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/9413/#review16512 -----------------------------------------------------------
/proton/trunk/proton-c/bindings/python/proton.py <https://reviews.apache.org/r/9413/#comment35008> I don't recall offhand if this notation works on python 2.4. If you haven't already, we should probably check just to be sure. /proton/trunk/tests/python/proton_tests/interop.py <https://reviews.apache.org/r/9413/#comment35009> I'm thinking we should actually check the data files into svn and load them from disk rather than generate them on the fly. I think this would be good for two reasons (1) the unit tests in other languages wouldn't need to depend on python, and (2) we would also catch compensating bugs, e.g. if I generate the test data on the fly all the time then I could introduce an encode bug along with a compensating decode bug and the tests wouldn't catch it, whereas if we check the files in, then we can verify that the current decode will work properly against historic versions of the encode as well. /proton/trunk/tests/python/proton_tests/interop.py <https://reviews.apache.org/r/9413/#comment35010> I'm wondering if we shouldn't just add methods to the Message class to directly encode/decode to/from binary data. This seems like it might be convenient here and its also plausible that end users would find it useful. It would also let us check interop on a few small aspects of the message encode/decode that might not be covered by just checking through the data interface here. /proton/trunk/tests/python/proton_tests/interop_gen.py <https://reviews.apache.org/r/9413/#comment35011> I'm wondering if we'll want to define a format such that we can add multiple values to check edge cases, e.g. binary with nulls in it, or a string with unicode characters, empty binary, string, and symbol values, etc. I'm not sure offhand what the best way to deal with that would be. I guess in some ways we'd need to update all the unit tests anyways in order to add to an extra assertion, so there might not be all that much point to a generic format. Either way I'd suggest starting out with as many edge cases as we can think of so when we port the python unit tests you have to other languages we get the additional coverage. Edgecases are a pretty common place where subtle mapping issues creep in. It's easy to confuse binary, string, and symbol and map them all into the same thing if you don't have sample values that exercise their differences. - Rafael Schloming On Feb. 12, 2013, 5:40 p.m., Alan Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/9413/ > ----------------------------------------------------------- > > (Updated Feb. 12, 2013, 5:40 p.m.) > > > Review request for qpid, Kenneth Giusti and Rafael Schloming. > > > Description > ------- > > PROTON-215: Add tests to verify AMQP type support for python bindings. > > The test consists of > - a generator program that generates AMQP fragments for all AMQP types > - a set of unit tests to decode, verify and re-encode the fragments. > > This will be extended intended to cover all the proton language bindings. > All bindings > will re-use the generator, unit tests will be added for each language. > > > Diffs > ----- > > /proton/trunk/proton-c/bindings/python/proton.py 1443924 > /proton/trunk/tests/python/proton_tests/__init__.py 1443924 > /proton/trunk/tests/python/proton_tests/interop.py PRE-CREATION > /proton/trunk/tests/python/proton_tests/interop_gen.py PRE-CREATION > > Diff: https://reviews.apache.org/r/9413/diff/ > > > Testing > ------- > > described_array test fails, skipping. I believe the tests have found their > first bug :) > > > Thanks, > > Alan Conway > >
