Home

Flexibility Showcase

This project was born out of a need for greater continious testing flexibility than autotest could provide. The following showcases some alternative testing needs that watchr makes possible, as well as uses beyond testing.

Continious Testing

Autotest is an amazing library that brought continious testing to the ruby community. It is opinionated, though, which in some circumstances can become problematic. For example, it reacts to saving this project’s test/test_watchr.rb with:

  /usr/bin/ruby1.8 -I.:lib:test -rubygems -e "%w[test/unit test/test_watchr.rb].each { |f| require f }"

locking the environment into ruby1.8, rubygems and test/unit. It’s easy to see why watchr doesn’t have any of these restrictions, since the whole command is custom. The gem you’re working on runs minitest on ruby1.9, and you use rip? Easy:

  watch( 'test/test_.*\.rb' ) {|md| system("/usr/bin/ruby1.9 #{md[0]}") }

Or you use specs/ as your test dir?

  watch( 'test/test_.*\.rb' ) {|md| system("ruby -I.:lib:specs #{md[0]}") }

Maybe the project you’re working on doesn’t load rubygems internally (which is good practice), but you still use it locally yourself:

 watch( 'test/test_.*\.rb' ) {|md| system("ruby -rubygems #{md[0]}") }

Continious Documenting

watchr is generic enough to allow uses other than running specs. One such use is keeping your project’s documentation up to date, similar to livelydocs:

  run_rdoc = lambda { system('rake --silent rdoc') }

  watch( '(lib|bin)/.*\.rb', &run_rdoc )
  watch( 'README',           &run_rdoc )

Assuming the script is stored in rdocs.watchr, run with

  $ watchr rdocs.watchr

and your documentation will be updated whenever you save a ruby file in lib/ or bin/, or the README.