Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TestFBLongVarCharEncodings#testOctets() fails after change to TestFBEncodings [JDBC204] #253

Closed
firebird-automations opened this issue Dec 4, 2011 · 8 comments

Comments

@firebird-automations
Copy link

Submitted by: @mrotteveel

Last week I changed the test TestFBEncodingsTest#⁠testOctets() to also check for correct padding of octets char fields. This broke TestFBLongVarCharEncodings#⁠testOctets() (which depends on TestFBEncodings.

Commits: ceb953d

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

assignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2 [ 10053 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Correction: It looks like the tests in TestFBLongVarCharEncodings all pass when the test is run in isolation, but if TestFBIntegerField is run first, then TestFBLongVarCharEncodings#⁠testOctets() fails.

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

I looked at it the wrong way. TestFBLongVarCharEncodings extends TestFBEncodings, testOctets() is defined in the superclass and works when executed on the superclass. The problem occurs always in TestFBLongVarCharEncodings (I haven't retested on my laptop yet, but I suspect I overlooked that one when making the change). It uses BLOB SUB_TYPE 1 CHARACTER SET OCTETS (which is a bit illogical, why not just use BLOB SUB_TYPE 0), so it looks like in that case the result is different from expected.

I modified the test to request the 'full length' byte array, and overrode that method in the subclass to return the correct array for that test.

I think I confused the padding, because the test is actually expicitly testing for padding with 0x20.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

description: Last week I changed the test TestFBLongVarCharEncodings#⁠testOctets() to also check for correct padding of octets char fields (if it is padded with 0x00), this test passes on my laptop, but fails sometimes(!) on my desktop.

On my desktop the char field is sometimes padded with 0x20, so as if it is a normal CHAR field, not CHAR CHARACTERSET OCTETS, but other times it *is* padded with 0x00.

We need to investigate where this difference in behavior is coming from.

=>

Last week I changed the test TestFBEncodingsTest#⁠testOctets() to also check for correct padding of octets char fields. This broke TestFBLongVarCharEncodings#⁠testOctets() (which depends on TestFBEncodings.

summary: TestFBLongVarCharEncodings#⁠testOctets() fails on some systems => TestFBLongVarCharEncodings#⁠testOctets() fails after change to TestFBEncodings

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

priority: Major [ 3 ] => Trivial [ 5 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants