[rspec-users] rspec runner setting $KCODE considered harmful?
joshwhiting at gmail.com
Wed Sep 22 22:47:57 EDT 2010
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users