RubyMine can't find test_helper

I have been an RSpec user since I started working on Ruby and Rails. I usually run a spec file, which reflect the production code file that I'm currently working on, inside RubyMine. So far it has been working fine out of the box.

As a lot more people start talking about Minitest, I want to give it a try. I was starting a new project today. It was a perfect chance to try out Minitest. I expected it to work perfectly out of the box with RubyMine, but apparently it is not.

I got this error when I tried running my test as usual.

`require': cannot load such file -- test_helper (LoadError)

Basically, it says that Ruby can't find test_helper file that is required in the top of my Minitest test file. I knew that it's LOAD_PATH issue but I didn't actually know how to config it properly since I was spoiled by out of the box RSpec integration.

I did googling around by no luck. There's only a page show how to config Minitest report.

I did try to switch back to RSpec just to see whether it's still working fine, and it is. I looked at the runner command that's generated by RubyMine when we execute the spec. There's nothing special from what it generates for Minitest. It seems like RSpec does some work figuring out the path for us. That's why it works out of the box.

So I aim toward finding a way to manually config properly the test running path. Finally, I figured it out with the clue from this comment.

• First go to Run > Edit Configurations.
• On the left panel, select Defaults and Ruby
• Put the absolute path to your Rails project into Working directory: field
• Append field Ruby arguments with -Itest (tell Ruby to look into test directory)
• If you had run the test before, you need to remove all the configurations under Ruby section (outside Defaults) to force them to load the new configuration
• And enjoy the Minitest experiences! (Should work with TestUnit too)

There's one potential problem with this solution. If you do run any non-test Ruby files, they will always load test directory which you don't want them to. Personally I've never do that so this setup is fine for me.

[Ruby] Run multiple MiniTest files in command line without other setup required (Rake, ...)

MiniTest is a great, simple build-in test framework for Ruby. We can use immediately without anymore setup beside installing Ruby. But there's an annoying limitation when starting a project that we can only run one file at a time via command line. Try to execute many files with "ruby *" doesn't help.

Here's the simplest way to run multiple minitest files I can think of

ruby -e "Dir.glob('**/*_spec.rb').each { |f| require File.expand_path(f) }"

Change suffix _spec to _test for test-unit style file.

[Ubuntu] Remove Password Prompt For sudo

• Open a terminal
• Run sudo visudo
• Add line 
• <username> ALL=NOPASSWD: ALL
• For example, david ALL=NOPASSWD: ALL
• Save and quit
• Done

From: https://help.ubuntu.com/community/RootSudo#Remove_Password_Prompt_For_sudo

[Blog] Great use of Null Object pattern

Last weekend, I watched a talk Code Smells: Your Refactoring Cheat Codes by John Pignata from MountainWest RubyConf 2013. I was really enjoyed with it. One of the technique that I really like is his use of Null Object pattern. Even though, I know this pattern for long time, but in the situation he was in, I would not be able to come up with the solution like that.

Almost at the end of the talk, his code came to the state that he has jobs and PushDaemon that pushing jobs to the worker. Because a job returned from factory can be nil, he needs to check and allow only non-nil job to be pushed. This is a well-known use case for Null Object Pattern. He modified factory to  return NullJob instead of nil. Now his PushDaemon doesn't need to check for nil anymore.

The code was cleaner without nil checking but pushing null job to worker is not so efficient. How can we avoid pushing NullJob to the worker without checking for nil? That was the time he showed a great technique. Flipping push method (<<) in PushDaemon which was send to worker list to send to job with the opposite direction (>>) and pass worker list as an argument instead. Then implements >> for all the jobs to push itself to worker list except for NullJob. >> of NullJob does nothing. At the end, everything fall cleanly and efficiently.

I highly recommend you to check out his talk for other great refactoring techniques yourself from the link beginning of this blog or on his blog directly.