Interesting use case example for `are` macro in Clojure test

I found an interesting use case for are in Clojure test.

You might have ever written a test for your data conversion logic. E.g.

• Converting data pulled from third-party web service into your internal schema.
• Converting data fetched from your database to more mobile friendly schema before sending out.

This is an example snippet of test for such a scenario.

convert-test1 shows the style I had been writing until recently. convert-test2 shows how using are making the test better.

Pros:

• No more duplication of field values between input and output.
• No more duplication between output schema and code under test schema.
• It can be use as a document showing clearly how each individual field is mapped.

Cons:

An error message in convert-test1 is better. It shows clearly which field is wrong while convert-test2 throw out the whole problematic result data.

Updated: I have retested, are does report problem for an individual case as well.

RSpec 3 matcher equivalent to =~

contain_exactly

Example:
  expect([1,2]).to contain_exactly(2,1)

Credit: match_array matcher now available as contain_exactly

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.

I get paid for code that works, not for tests ... - Kent Beck

This quote by Kent Beck is just popping up all around articles I have read these days. Want to keep it  here.

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it

From http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

Personal (and non-popular) Rails development rules of thumb

• View first, then Controller and Model last.
• In Controller tests:
• Don't mock ActiveRecord method
• Do stub ActiveRecord method (No real SQL execution allowed)
• Do mock custom model method
• Use signature from model mock to create real method in model (or module)
• Should not contain more than 5 lines or 10 function calls
• In Model tests:
• Do real SQL execution (No mock, no stub)