wrong

t-slug "hydralazine hydrochloride, hydrochlorothiazide and reserpine" "hydralazine-hydrochloride") (assert-slug "hydralazine hydrochloride w/ hydrochlorothiazide 100/50" "hydralazine-hydrochloride") ;; Sandbox (to-slug "00-d-amphetamine") Every time I hit C-c C-k (eval-buffer in Emacs w/ nrepl), the asserts are run which will throw an error on failure. And since eval-buffer always returns the result of the last expression evaluated, the above "Sandbox" section represents whatever case I'm currently trying to extend `to-slug` support for. The result of which is returned on every eval-buffer. In this case, `to-slug` doesn't correctly handle "00-d-amphetamine" yet, so as I modify the production code to handle it, I can mash eval-buffer after every change to (1) see if my change introduces regressions and (2) visualize my progress on handling "00-d-amphetamine". Once it works, I add an "00-d-amphetamine" assert-slug and move on to the next case. As to-slug matures, I can then move the asserts to a dedicated test directory if I want to and replace the slime with minimal case tests. -- Things that otherwise slow down my exploration phase. ---- I think core.assert fills the chasm of a function's/file's lifecycle between "I'm not even sure if I want this function or what its input/output will look like" and "my source code definitely needs this and this is its API". In Ruby, I like https://github.com/sconover/wrong.

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 } Like, actual Ruby. And it will figure out on its own how to display diffs in error output. 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 Here's Rspec: "abc".should == "abd" cookie_jar.should be_empty it ->(dog){responds_2}.(:walk).(&:does?) So all this talk about avoiding DSLs yet you don't. And it wasn't until blowmage (of minitest) told me about Wrong in IRC that I found what I wanted -- the only real way to avoid DSLs and verbosity in Ruby testing that I've come across. [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.