* Testing is an advanced topic, yet it seems to be misleadingly sold in Rails tutorial literature as something that everyone else effortlessly does with the same ease of "gem install hairball".[3]
* Good luck finding resources on Test::Unit/Minitest.[1]
* Where the documentation?
* Rails invents its own definitions for "unit tests", "functional tests", and "integration tests". Even though they already exist in testing vernacular. [2] Unfortunately confusing when Rails is your first experience with testing and you think "unit test" means "model test" and "integration test" means fumbling fruitlessly with your jasmine/capybara frankensuite because you're lost like I was and tried to stitch together a few Railscasts because you just don't know any better.
* Instead of embracing tests that don't depend on the Rails stack, the Rails community embraces tools like Spork that keep a Rails process alive. Because Rails takes too long to boot to have a test-driven cycle with tests that depend on Rails. The concept of service objects and wrapping Rails/3rd party libs is brand new to me and I only encountered it after I was good enough to contribute to large Rails apps and read their source code.
[1]: At least Ruby 1.9 changed the name (in essence) to "minitest" which we can finally google. "test unit"? Not so easy to google.
Also, here's the best resource for Minitest I can find: http://www.mattsears.com/articles/2011/12/10/minitest-quick-.... It's a cheatsheet on someone's blog.
Frankly, there are much better arguments for sticking with Rspec. For one, it's the testing library that the community uses and you need community support. The popular gems you'll be using probably have more wiki info on Rspec testing too (like Devise). Rspec is documented and even illustrates best practices. http://betterspecs.org/.
That Minitest is built in to Ruby was never a convincing reason to use it. I already have development dependencies. Trust me that testing isn't going to be the thing that introduces the first 3rd party dependency into my app. Fucking "awesome_print" is already in my Gemfile, so it's not a big deal to add a gem that makes testing better for me.
And for all the hate that Rspec gets for its DSL, Test::Unit/Minitest's DSL (assertion statements) is just as bad and Minitest::Spec introduces an Rspec DSL anyways.
The only way I want to write tests is by writing my assertions in pure Ruby without having to lug around a bunch of different assertion variants just so the testing library knows what kind of error output to show me.
The ONLY solution I've found is a library called Wrong (https://github.com/sconover/wrong) and it works with both Minitest and Rspec.
It lets you write assertions like this:
include Wrong
assert { "abc" == "abd" }
assert { cookie_jar.empty? }
assert { dog.respond_to?(:walk) }
assert { boy.is_a? Human }
Meanwhile, here's Minitest:
assert_equal "abc", "abd"
assert_empty cookie_jar
assert_responds_to dog, :walk
assert_instance_of Human, boy
# I know these because I'm looking at a cheatsheet
"abc".should == "abd"
cookie_jar.should be_empty
it ->(dog){responds_2}.(:walk).(&:does?)
[2]: Xavier Shay brings this up in his talk http://www.confreaks.com/videos/815-larubyconf2012-rails-sus...
[3]: Oh yeah, and after three years of Ruby and Rails, it wasn't until I was exposed to functional programming (Martin Odersky, Rich Hickey), OO design (Sandi Metz), and testing screencasts (Gary Bernhardt) that I finally understood how to even fundamentally write code that could be tested. In other words, it took high level a-ha moments for me to be able to write tests that didn't just cripple my workflow and waste my time and slow down my learning process. That's where I found out that testing is an advanced topic, not a bullet point you can throw into a newbie tutorial on how to generate a Rails scaffold.