Spec ./spec/rspec/support/encoded_string_spec.rb:204 will likely never pass on Rubinius

[yorickpeterse]

The spec ./spec/rspec/support/encoded_string_spec.rb:204 currently fails on Rubinius. This test assumes that the following raises an encoding conversion error:

"foo\nbar".encode("UTF-16LE").split("\n")

Rubinius however supports this just fine and will return the following:

["foo", "bar\x0"]

Now the question is, is this spec supposed to stick around? What is it supposed to test? The expectation of this code failing seems to be based on implementation specific behaviour, although I'm not entirely sure.

@brixen Any thoughts on this, is the specific error here something we want to raise similar to MRI?

[myronmarston]

Now the question is, is this spec supposed to stick around? What is it supposed to test? The expectation of this code failing seems to be based on implementation specific behaviour, although I'm not entirely sure.

The spec was added recently by @bf4 in #151 (which originated in #134). RSpec::Support::EncodedString handles various encoding errors. That spec (and others like it -- you'll see 5 other it 'normally does x' specs in the file) pair with the other spec in the context, and serves two purposes:

• It documents the behavior with raw strings, apart from what EncodedString does to deal with it.
• The other spec in the context has the assumption that that error would normally be raised (as it is meant to cover one of the particular rescue clauses), so that spec validates that the assumption is valid.

It sounds like RBX handles some encoding situations that MRI doesn't. Given that, we can simply exclude that spec on RBX -- after all, it's not testing RSpec logic at all.

[bf4]

Sounds like the spec is doing its job, in that it pointed out that Rbx has a different behavior. I tried in writing the tests to pick examples of each encoding-related exception that would behave the same on all Rubies. Perhaps there is a better example we could use for Encoding::CompatibilityError?

[bf4]

I should add, for completeness, that all the specs that I wrote were around existing behavior. It's possible we'd want to change how we handle Encoding::CompatibilityError. In any case, now that we have the specs, we can make changes with more confidence.

[bf4]

I believe this has been resolved and may be closed