rspec users - Sep 2010 - rspec runner setting $KCODE considered harmful?

I ran across a problem today in which some code ran fine in regular
operation but failed in a test case. I scratched my head and thought "why
would running from within the test harness change the behavior of my code?"
Clearly it was the Heisenberg uncertainty principle in action! :)

I discovered the root cause was that the rspec runner is setting the magical
ruby global, $KCODE, to ''u''. However, my application (which is
not a rails
app) had never specified $KCODE. I was relying on some default behavior of
regular expressions under ruby 1.8 (byte-wise character matching semantics)
that *change* when $KCODE is set to "u". Specifically, all regular
expressions change their default behavior to utf-8 character-wise semantics.
A simple example of this phenomenon: http://gist.github.com/592990

I''ve corrected the issue on my end by adopting the
$KCODE=''u'' semantics in
my application, but this led me to a couple comments/questions I thought
would be relevant to raise with other rspec-minded folks:

- Is it necessary for rspec to set $KCODE or is this a bug? Wouldn''t it
be
better if it didn''t twiddle any magical globals that change
interpreter-wide
behaviors? It reminds me of the bad days of perl when some distant code
would unexpectedly change out your line terminator character on you.

- It seems like a good idea to call out all the things the rspec environment
changes that affect natural runtime behavior of code: twiddling of globals,
class monkey patches, etc. It''d be great to get these into a list of
publicly documented pitfalls for people to watch out for.

Thanks for listening. Rspec has brought huge value to my engineering project
and I really appreciate the tool!

-Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100922/1a0df723/attachment.html>

On Sep 22, 2010, at 9:47 PM, Josh Whiting wrote:
> I ran across a problem today in which some code ran fine in regular
operation but failed in a test case. I scratched my head and thought "why
would running from within the test harness change the behavior of my code?"
Clearly it was the Heisenberg uncertainty principle in action! :)
> 
> I discovered the root cause was that the rspec runner is setting the
magical ruby global, $KCODE, to ''u''. However, my application
(which is not a rails app) had never specified $KCODE. I was relying on some
default behavior of regular expressions under ruby 1.8 (byte-wise character
matching semantics) that *change* when $KCODE is set to "u".
Specifically, all regular expressions change their default behavior to utf-8
character-wise semantics. A simple example of this phenomenon:
http://gist.github.com/592990
> 
> I''ve corrected the issue on my end by adopting the
$KCODE=''u'' semantics in my application, but this led me to a
couple comments/questions I thought would be relevant to raise with other
rspec-minded folks:
> 
> - Is it necessary for rspec to set $KCODE or is this a
bug?Wouldn''t it be better if it didn''t twiddle any magical
globals that change interpreter-wide behaviors? It reminds me of the bad days of
perl when some distant code would unexpectedly change out your line terminator
character on you.
> 
> - It seems like a good idea to call out all the things the rspec
environment changes that affect natural runtime behavior of code: twiddling of
globals, class monkey patches, etc. It''d be great to get these into a
list of publicly documented pitfalls for people to watch out for.
> 
> Thanks for listening. Rspec has brought huge value to my engineering
project and I really appreciate the tool!

I don''t remember the details, but that was added to solve a particular
problem back in 2005 or 2006. Changing it in RSpec-1 would break some existing
specs with a minor upgrade, so that''s a non-option.

This does not get set, however, in RSpec-2. I added a note about this to
http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown

Cheers,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100923/66067885/attachment.html>

On Thu, Sep 23, 2010 at 6:44 AM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> This does not get set, however, in RSpec-2. I added a note about this to
> http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown
>
Great, thanks for the pointer. Agreed changing something like this should
probably not be done a point release...

Cheers
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20100923/e85058b0/attachment-0001.html>