Journey doesn't clear its named route hash when the routes are reloaded but
Rails 3.2 isn't affected because Journey overwrites the existing route. This
is just a backport of the test to make sure it doesn't become affected in
some future release.
Minitest expects the first argument in `ARGV` to be the path to a test file.
Because `rails benchmarker` and `rails profiler` define an on-the-fly test-case,
using the first `ARGV` to pass the code to execute this results in:
```
/Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:167:in `block in non_options': file not found: 1000.times{"a string"} (ArgumentError)
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:146:in `map!'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:146:in `non_options'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:207:in `non_options'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:52:in `process_args'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/minitest/unit.rb:891:in `_run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/minitest/unit.rb:884:in `run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:21:in `run'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:326:in `block (2 levels) in autorun'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:27:in `run_once'
from /Users/senny/.rbenv/versions/1.9.3-p374/lib/ruby/1.9.1/test/unit.rb:325:in `block in autorun'
```
clearing ARGV after defining the test-case solves this issue.
Moral of the story: One must be careful about lazily initializing
instance variables when subclassing.
I would like to draw your attention to https://github.com/rails/rails/issues/4652 where
the reader will see that there appears to be some kind of initialization issue
in rails.
The source of this issue is that:
1) Engine#env_config contains "@env_config ||= ..."
2) Application#env_config contains "@env_config ||= ..."
3) Threads are in the picture
4) Thread A calls Application#env_config, which super's to Engine#env_config
5) After Engine#env_config returns but before Application#env_config sets @env_config again, Thread B begins running
6) Thread B calls Application#env_config
7) Thread B finds @env_config to contain a value (the one set by Engine#env_config) and returns it
8) Thread B blows up because key set by Application#env_config are there.
9) People report bugs with puma, thin, rainbows, webrick, etc
10) Evan becomes tired of seeing these bugs
11) Evan pours himself a stiff drink, puts on Top Gear(tm), and begins debugging
12) Evan finds the source of the bug
13) Evan authors a PR
14) RIGHT NOW.
The bug is fixed by simply using a different ivar name in the methods.
Alternately, Engine#env_config could just return a new Hash each time, not memoizing into @env_config.
I bid you adieu.
