ZenTest 4.11.2 → 4.12.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: dee722585445db1a500cb7654d1f490077359d013f7d11400953b56b141d6b25
-  data.tar.gz: fb4ce1a3719c49a461c5e4316ce5148d95427290598ef1f2dbafdd12bfad2c98
+  metadata.gz: f353025789e91d62a786e456c79bac18d8530f4c909326e6338dc2baeff052b4
+  data.tar.gz: '09068377d0f01b52260334421edc23c0666ad25def23bbe754d425de41989a84'
 SHA512:
-  metadata.gz: d0e5626f7f11f05cf9f88a55ecbd2fcbe375710bd2e8bc335e3ca1f3a226bbbb6f82b0bedeb19da6083955b1b8dd0dccfb120886c2e64a43feb39084e00a204f
-  data.tar.gz: 047716d93f8321a572bbead8c6cf0ff254fcec7778ff49e006b05f9b688eb53072946b8f7e70b541154b251c0001d1b3e9063fb99ecbbe9f768b69b73d4561ff
+  metadata.gz: 8c92e152c21a1175febe8c2d48032ba3755739762e6dbaed60f6200af1f37320e8b013d44ea54fd56c41b9bad9cd6eb7513bd7ef33cc5208e2108cb06e8e9e7c
+  data.tar.gz: 00dee54f3217ac491c37cc01e2bfa607cd90d33d23a6b66e69a8bf1464ea74a80a51bb45831f5474dfc0def76e1717f88a86e36c23b3f97fd9b159a2301a11e2

checksums.yaml.gz.sig

@@ -1,4 +1,3 @@
-,p:[Z5N3�x���31�v����,���;vB
%4�Wbf�Hu�4�,
-J����Q���du�I����"5��?tOK��'
-PƄ�TV@3�!���]ש+�5U�eT��Sh�x���J�;l�eSV\җ���ε})3�a��
-l�V
+W��Ri�j�qrَX�巅o�Dk��/���0���a]#�]�a�rV�+
+N���]!f[�
F1֫.�
+�}�kk��I��=,;�-��<v�Ӓ���M

data/.autotest

@@ -7,7 +7,6 @@ Autotest.add_hook :initialize do |at|
   at.add_exception 'coverage.info'
 
   at.libs << ':../../minitest/dev/lib'
-  at.testlib = ".minitest"
 
   %w(TestZenTest).each do |klass|
     at.extra_class_map[klass] = "test/test_zentest.rb"

data/History.txt

@@ -1,3 +1,22 @@
+=== 4.12.0 / 2019-09-22
+
+* 3 major enhancements:
+
+  * Deleted autotest from project. Use minitest-autotest instead.
+  * Removed multiruby_setup. Use ruby-install or ruby-build or install your own.
+  * Update multiruby to use ~/.rubies (default for ruby-install).
+
+* 4 minor enhancements:
+
+  * Find and use the multiruby next to multigem.
+  * multiruby ignores GEM_HOME and GEM_PATH (to allow multigem to work).
+  * multiruby respects global `multiruby_skip` entries in `~/.hoerc`.
+  * multiruby sorts versions properly so glob ordering is consistent.
+
+* 1 bug fix:
+
+  * Removed hacks for rbx because nobody uses rbx.
+
 === 4.11.2 / 2019-01-02
 
 * 1 bug fix:

data/Manifest.txt

@@ -4,34 +4,19 @@ Manifest.txt
 README.txt
 Rakefile
 articles/Article.css
-articles/getting_started_with_autotest.html
 articles/how_to_use_zentest.txt
-bin/autotest
 bin/multigem
 bin/multiruby
-bin/multiruby_setup
 bin/unit_diff
 bin/zentest
 example.txt
 example1.rb
 example2.rb
-example_dot_autotest.rb
-lib/autotest.rb
-lib/autotest/autoupdate.rb
-lib/autotest/bundler.rb
-lib/autotest/isolate.rb
-lib/autotest/once.rb
-lib/autotest/preload.rb
-lib/autotest/rcov.rb
-lib/autotest/restart.rb
-lib/autotest/timestamp.rb
 lib/focus.rb
 lib/functional_test_matrix.rb
-lib/multiruby.rb
 lib/unit_diff.rb
 lib/zentest.rb
 lib/zentest_mapping.rb
-test/test_autotest.rb
 test/test_focus.rb
 test/test_unit_diff.rb
 test/test_zentest.rb

data/bin/multigem

@@ -1,4 +1,5 @@
 #!/usr/bin/env ruby -w
 
-exec "multiruby", "-S", "gem", *ARGV
+multiruby = File.expand_path "../multiruby", __FILE__
 
+exec multiruby, "-S", "gem", *ARGV

data/bin/multiruby

@@ -1,24 +1,37 @@
 #!/usr/bin/env ruby -w
 
-require 'multiruby'
+require "yaml"
 
-root_dir = Multiruby.root_dir
+class Array
+  def human_sort
+    sort_by { |item| item.to_s.split(/(\d+)/).map { |e| [e.to_i, e] } }
+  end
+end
+
+root_dir = File.expand_path "~/.rubies"
+
+versions = Dir.chdir(root_dir) { Dir["*"] }.human_sort
 
 def setenv dir
-  bin  = "#{dir}/bin"
-  gem  = Dir["#{dir}/lib/ruby/gems/*"].first
+  ENV["PATH"] = "#{dir}/bin:#{ENV["PATH"]}"
+end
 
-  ENV['PATH'] = bin + File::PATH_SEPARATOR + ENV['PATH']
-  ENV['GEM_HOME'] = gem
-  ENV['GEM_PATH'] = gem
+def unsetenv key
+  if ENV[key] then
+    warn "WARNING: %s is set to %p. Removing..." % [key, ENV[key]]
+    ENV.delete key
+  end
 end
 
+unsetenv "GEM_HOME"
+unsetenv "GEM_PATH"
+
 ##
-# multiruby -1 1.8.7 ruby_args...
+# multiruby -1 2.0 ruby_args...
 
 if ARGV.first == "-1" then
   ARGV.shift
-  vers = Dir["#{root_dir}/install/#{ARGV.shift}*"]
+  vers = Dir["#{root_dir}/#{ARGV.shift}*"]
 
   abort "ambiguous version: #{vers.map { |p| File.basename p }.inspect}" if
     vers.size != 1
@@ -29,11 +42,14 @@ if ARGV.first == "-1" then
   exec "#{dir}/bin/ruby", *ARGV
 end
 
-versions = Multiruby.build_and_install
-versions = ENV['VERSIONS'].split(/:/) if ENV.has_key? 'VERSIONS'
-
-if ENV.has_key? 'EXCLUDED_VERSIONS' then
-  excludes = Regexp.union(*ENV['EXCLUDED_VERSIONS'].split(/:/))
+rcpath = File.expand_path "~/.hoerc"
+skip = if File.exist? rcpath then
+         conf = YAML.load File.read rcpath
+         conf["multiruby_skip"] || []
+       end
+excl = (ENV["EXCLUDED_VERSIONS"] || "").split(/:/) + skip
+unless excl.empty? then
+  excludes = Regexp.union(*excl)
   versions = versions.delete_if { |v| v =~ excludes }
 end
 
@@ -42,13 +58,12 @@ original_path = ENV['PATH']
 
 results = {}
 versions.each do |version|
-  dir  = "#{root_dir}/install/#{version}"
+  dir  = "#{root_dir}/#{version}"
   ruby = "#{dir}/bin/ruby"
-
-  ruby.sub!(/bin.ruby/, 'bin/rbx') if version =~ /rubinius/
+  ver  = version.delete_prefix "ruby-"
 
   puts
-  puts "VERSION = #{version}"
+  puts "VERSION = #{ver}"
   cmd = [ruby, ARGV].flatten.map { |s| s =~ /\"/ ? "'#{s}'" : s }.join(' ')
   cmd.sub!(/#{ENV['HOME']}/, '~')
   puts "CMD     = #{cmd}"
@@ -59,7 +74,7 @@ versions.each do |version|
   system ruby, *ARGV
   puts
   puts "RESULT = #{$?}"
-  results[version] = $?
+  results[ver] = $?
 
   # restore the path to original state
   ENV['PATH'] = original_path

data/lib/zentest.rb

@@ -64,7 +64,7 @@ end
 
 class ZenTest
 
-  VERSION = "4.11.2"
+  VERSION = "4.12.0"
 
   include ZenTestMapping
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: ZenTest
 version: !ruby/object:Gem::Version
-  version: 4.11.2
+  version: 4.12.0
 platform: ruby
 authors:
 - Ryan Davis
@@ -30,7 +30,7 @@ cert_chain:
   Em82dBUFsipwMLCYj39kcyHWAxyl6Ae1Cn9r/ItVBCxoeFdrHjfavnrIEoXUt4bU
   UfBugfLD19bu3nvL+zTAGx/U
   -----END CERTIFICATE-----
-date: 2019-01-02 00:00:00.000000000 Z
+date: 2019-09-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rdoc
@@ -58,14 +58,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '3.17'
+        version: '3.18'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '3.17'
+        version: '3.18'
 description: |-
   ZenTest provides 4 different tools: zentest, unit_diff, autotest, and
   multiruby.
@@ -96,10 +96,8 @@ email:
 - ryand-ruby@zenspider.com
 - drbrain@segment7.net
 executables:
-- autotest
 - multigem
 - multiruby
-- multiruby_setup
 - unit_diff
 - zentest
 extensions: []
@@ -116,34 +114,19 @@ files:
 - README.txt
 - Rakefile
 - articles/Article.css
-- articles/getting_started_with_autotest.html
 - articles/how_to_use_zentest.txt
-- bin/autotest
 - bin/multigem
 - bin/multiruby
-- bin/multiruby_setup
 - bin/unit_diff
 - bin/zentest
 - example.txt
 - example1.rb
 - example2.rb
-- example_dot_autotest.rb
-- lib/autotest.rb
-- lib/autotest/autoupdate.rb
-- lib/autotest/bundler.rb
-- lib/autotest/isolate.rb
-- lib/autotest/once.rb
-- lib/autotest/preload.rb
-- lib/autotest/rcov.rb
-- lib/autotest/restart.rb
-- lib/autotest/timestamp.rb
 - lib/focus.rb
 - lib/functional_test_matrix.rb
-- lib/multiruby.rb
 - lib/unit_diff.rb
 - lib/zentest.rb
 - lib/zentest_mapping.rb
-- test/test_autotest.rb
 - test/test_focus.rb
 - test/test_unit_diff.rb
 - test/test_zentest.rb
@@ -169,7 +152,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.0.2
+rubygems_version: 3.0.6
 signing_key: 
 specification_version: 4
 summary: 'ZenTest provides 4 different tools: zentest, unit_diff, autotest, and multiruby'

data/articles/getting_started_with_autotest.html

@@ -1,533 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
-    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xml:lang="en-US" lang="en-US" xmlns=
-"http://www.w3.org/1999/xhtml">
-<head>
-<title>PH7 - Getting started with Autotest - Continuous
-Testing</title>
-<link href="Article.css" media="all" rel="Stylesheet" type="text/css" />
-</head>
-<body>
-<div class="content">
-<h1>NOTE: This article was written in 2007. It is out of date.</h1>
-<h1 style="text-align: center;">Getting started with Autotest -
-Continuous Testing</h1>
-<div id="abstract" class="Abstract">
-<p class="first">Why manually run your tests, when the computer can
-do it for you! <a href=
-"http://www.zenspider.com/ZSS/Products/ZenTest/">Autotest</a> is a
-great tool to speed up test-driven development with Ruby or Ruby on
-Rails. Autotest makes your coding session even more productive as
-<strong>it automatically runs a subset of your test suite each time
-you change a file. Autotest is smart -- it figures out which subset
-to run based on the files you've changed.</strong> Think of it as
-<strong><q>Continuous Testing</q></strong>.</p>
-<p>Autotest source code is well-documented (<a href=
-"http://zentest.rubyforge.org/ZenTest/" title=
-"ZenTest documentation">rdoc</a>) but finding a high level overview
-online is a little more challenging. This article will get you up
-and running in no time, so that you may concentrate on writing
-code. <a href="getting_started_with_autotest">Let's get
-started!</a></p>
-</div>
-<h2 id="why_autotest">Why Autotest?</h2>
-<h3 id="continuous_testing">Continuous Testing</h3>
-<p>The cool thing about Autotest is that you have <strong>instant
-feedback on your code</strong> (tests run within a second). Even
-better, <strong>the testing happens on its own</strong> so
-<strong>you no longer have to switch back and forth</strong> from
-the coding context to the testing context anymore (both wise
-cognitively and from a <acronym title="User Interface">UI</acronym>
-perspective). This effortless and immediate feedback on your code
-as well as the automated and unattended test runs are quite similar
-to the characteristics of <a href=
-"http://www.martinfowler.com/articles/continuousIntegration.html"
-title=
-"Martin Fowler's legendary introduction to Continuous Integration">Continuous
-Integration</a> at the team level. However, continuous integration
-concentrates on improving <em>integration</em> at a <em>team</em>
-level while Autotest concentrates on facilitating the
-<em>development</em> for a <em>single</em> developer (or
-programming-pair) <em>before</em> the code gets integrated -- hence
-the term <strong><dfn>Continuous Testing</dfn></strong>.</p>
-<p>As this is highly visual, <strong>have a look at Nuby on Rails'
-<a href="http://topfunky.com/clients/blog/autotest-tm.mov">autotest
-screencast</a></strong>.</p>
-<h3 id="quicker_test_runs">Quicker Test Runs</h3>
-<p>Autotest can also provide <strong>quicker test runs</strong>
-than standard convention since it intelligently monitors the
-changes and only runs the tests that are impacted by these changes.
-In practice this is relevant only for <q>classic</q> Rails
-applications because:</p>
-<ul>
-<li><strong>Rails conventions provide good heuristics</strong> for
-Autotest to decide which tests to run when a file changes. If your
-application does not stick to the classic Rails layout and naming
-conventions the <q>magic</q> does not work so well anymore. In this
-case, it is probably better to have Autotest <a href=
-"getting_started_with_autotest#running_whole_test_suite">run your
-whole test suite for all changes</a>.</li>
-<li>There is value in running a <em>subset</em> of the whole test
-suite <strong>only because running <q>classic</q> Rails unit tests
-can be slow</strong>. This is mostly since Rails approach to unit
-testing is quite unconventional and involves database access. This
-approach goes against general <q>agile</q> wisdom that you should
-make sure your unit tests run quickly, and do not have any
-dependency for external systems. Also note that there are <a href=
-"http://jayfields.blogspot.com/2006/06/ruby-on-rails-unit-tests.html">
-well-documented ways</a> to have your Rails unit tests not depend
-on the database and have them run blazing fast!</li>
-</ul>
-<h3 id="lack_of_proper_ide">Make Up for a Lack of a Proper Ruby
-IDE</h3>
-<p>Autotest can come in handy if your favorite IDE has limited Ruby
-support, or if you prefer a more ligthweight development
-environment (text editor + terminal + Autotest): it gives you an
-easy and automated way to run your tests.</p>
-<h2 id="install_autotest">Install Autotest</h2>
-<h3>Make Sure You Already have RubyGem Installed</h3>
-<p>The easiest way to install <code>Autotest</code> is to use the
-<strong>ZenTest gem</strong>. If you have no idea of what a
-<dfn>gem</dfn> is, or you have not installed the RubyGem packaging
-system yet, please have a look at the <a href=
-"http://rubygems.org/">RubyGem official website</a>. If you are
-serious about Ruby development, it will be hard <em>not</em> to use
-RubyGem.</p>
-<h3 id="install_osx_ubuntu">OS X and Ubuntu</h3>
-<p>On OS X or Ubuntu launch from a terminal:</p>
-<pre class="command-box">
-$ sudo gem install ZenTest
-</pre>
-<h3 id="install_other_unix">Other Unix flavors</h3>
-<p>For other *Nix flavors, try</p>
-<pre class="command-box">
-$ suPassword:<span class=
-"placeholder">Type root password here</span>$ gem install ZenTest
-</pre>
-<h2 id="run_autotest">Run autotest</h2>
-<h3 id="run_rails">Ruby on Rails project</h3>
-<p>Consistent with Rails principles, Autotest does not require any
-configuration to run. Provided you follow classic Rails
-conventions, Autotest will figure things out on its own.
-<strong>Simply launch Autotest from the base directory of your Ruby
-on Rails project.</strong></p>
-<pre class="command-box">
-$ cd <span class=
-"placeholder">base directory of your Ruby on Rails project</span>$ autotest
-</pre>
-<p>Autotest will then run all your tests (the first time), and wait
-for you to modify some code:</p>
-<pre class="command-box">
-$ autotest
-/usr/bin/ruby1.8 -I.:lib:test -rtest/unit -e "%w[test/functional/tasks_controller_test.rb test/unit/quarter_test.rb test/unit/task_test.rb].each { |f| require f }" | unit_diff -u
-Loaded suite -e
-Started
-.......................
-Finished in 0.672928 seconds.
-
-================================================================================
-<strong>23 tests, 60 assertions, 0 failures, 0 errors</strong>
-</pre>
-<p>Go ahead and <strong>modify some code in your project so that a
-test fails.</strong> Save the modified file to disk and Autotest
-will automatically rerun some of the tests:</p>
-<pre class="command-box">
-/usr/bin/ruby1.8 -I.:lib:test -rtest/unit -e "%w[test/functional/tasks_controller_test.rb test/unit/task_test.rb].each { |f| require f }" | unit_diff -u
-Loaded suite -e
-Started
-...F........
-Finished in 0.42272 seconds.
-
-1) Failure:
-test_should_be_found(TaskTest) [<strong>./test/unit/task_test.rb:22</strong>]:
---- /tmp/diff6647.0     2006-11-15 20:46:43.000000000 -0800
-+++ /tmp/diff6647.1     2006-11-15 20:46:43.000000000 -0800
-@@ -1 +1 @@
-<strong>
--Expected result
-+Actual result</strong>
-
-================================================================================
-<strong>4 tests, 9 assertions, 1 failures, 0 errors</strong>
-</pre>
-<p>Note that autotest ran only a <em>subset</em> of your test suite
-this time (4 tests out of 23 in my case). Also note that
-<strong>Autotest is especially good in providing brief and relevant
-feedback on the test failures</strong>.</p>
-<p>Autotest focuses on running previous failures until you have
-fixed them. So <strong>test failures are run until they have all
-passed. Then the full test suite is run</strong> to ensure that
-nothing else was inadvertently broken.</p>
-<h3 id="run_ruby">Ruby Project</h3>
-<p>In theory you would run Autotest the same way as you would for
-any Ruby project -- even if it is not based on Rails:</p>
-<pre class="command-box">
-$ cd <span class=
-"placeholder">base directory of your Ruby project</span>$ autotest
-</pre>
-<p>In practice, Autotest might have problems finding your tests or
-figuring out which tests to run when you change some code. If this
-is the case, take a look at the <a href=
-"getting_started_with_autotest#troubleshoot_test_detection"><q>troubleshooting
-test detection</q></a> section.</p>
-<h3 id="full_test_run">Forcing a Full Test Run and Stopping
-Autotest</h3>
-<p><strong>If you want to force Autotest to run the <em>entire</em>
-test suite</strong> <strong>hit <kbd>Ctrl - C</kbd> once</strong>
-in the terminal running Autotest. Hitting <kbd>Ctrl - C</kbd> twice
-will stop Autotest.</p>
-<h2 id="configure_plugins">Configure Plugins</h2>
-<p>Autotest also provides some cool plugins that enable you to
-<strong>get feedback the way you want</strong>.</p>
-<h3 id="create_dot_autotest">Create a <code>.autotest</code>
-file</h3>
-<p><strong>You configure plugins by creating a
-<code>.autotest</code> file in your project base
-directory</strong>. You can also provide a default configuration
-for all your projects by creating a <code>.autotest</code> file in
-your home directory (when present, project configuration files
-override user default configuration file).</p>
-<p><strong>You enable a plugin by adding a line requiring the
-plugin in the <code>.autotest</code> file</strong>. For instance,
-to enable the <q>Growl</q> plugin, you would add the following
-line:</p>
-<pre class="source-code-box">
-require 'autotest/growl'
-</pre>
-<p>Below you will find a description of the most popular plugins
-and how to enable them.</p>
-<h3 id="red_green_plugin">Red / Green Plugin</h3>
-<p>The <q>Red / Green</q> plugin provides color to
-<code>Autotest</code> messages in the terminal window. As expected,
-output is green if all the tests pass, red if some test fails.
-Having red / green visual output makes it easier for one to scan
-the output and quickly determine whether everything is OK or
-something went wrong.</p>
-<p>Visually, the <q>Red /Green</q> plugin turns</p>
-<pre class="command-box">
-================================================================================
-200 tests, 520 assertions, 0 failures, 0 errors
-</pre>
-<p>into</p>
-<pre class="command-box" style="color: green;">
-================================================================================
-200 tests, 520 assertions, 0 failures, 0 errors
-</pre>
-<p>or</p>
-<pre class="command-box" style="color: red;">
-================================================================================
-5 tests, 20 assertions, 1 failures, 0 errors
-</pre>
-<p>To enable the <q>Red / Green</q> plugin add the following line
-to your <code>.autotest</code> file:</p>
-<pre class="source-code-box">
-require 'autotest/redgreen'
-</pre>
-<h3 id="desktop_notification_plugins">Desktop Notification
-Plugins</h3>
-<p>You might not even have to look at <code>the Autotest</code>
-terminal output to figure out the result of a test run.
-<strong>Several plugins provide desktop notification messages
-capabilities</strong>. In this way you can run Autotest in the
-background and see popup messages when something fails.</p>
-<h4 id="growl_plugin">Growl Plugin (OS X)</h4>
-<p><a href="http://growl.info/">Growl</a> is a popular desktop
-notification system for OSX. If you are developing on a Mac, enable
-the Growl plugin by adding</p>
-<pre class="source-code-box">
-require 'autotest/growl'
-</pre>
-<p>to your <code>.autotest</code> file. Note that for this plugin
-to work, you not only need to install <a href="http://growl.info/"
-title="Growl website">Growl</a> <strong>but also its command line
-interface: <a href=
-"http://growl.info/documentation/growlnotify.php">growlnotify</a>.</strong></p>
-<h4 id="snarl_plugin">Snarl Plugin (Windows)</h4>
-<p><a href="http://www.fullphat.net/">Snarl</a> is a notification
-system for Windows largely inspired by Growl. Autotest will use it
-if you enable the Snarl plugin in your <code>.autotest</code>
-file:</p>
-<pre class="source-code-box">
-require 'autotest/snarl'
-</pre>
-<h4 id="kde_notify_plugin">KDE Notify Plugin (Linux)</h4>
-<p>If you are running Linux and use KDE as your desktop
-environment, you will get desktop notification by adding to your
-<code>.autotest</code> file:</p>
-<pre class="source-code-box">
-require 'autotest/kdenotify'
-</pre>
-<h4 id="gnome_notify_plugin">Gnome Notify plugin (Linux)</h4>
-<p>If you are running Linux and use Gnome as your desktop
-environment, unfortunately there is no official plugin for desktop
-notification. You can still get desktop notifications by adding the
-following code snipet in your <code>.autotest</code> file:</p>
-<pre class="source-code-box">
-module Autotest::GnomeNotify
-
-  # Time notification will be displayed before disappearing automatically
-  EXPIRATION_IN_SECONDS = 2
-  ERROR_STOCK_ICON = "gtk-dialog-error"
-  SUCCESS_STOCK_ICON = "gtk-dialog-info"
-
-  # Convenience method to send an error notification message
-  #
-  # [stock_icon]   Stock icon name of icon to display
-  # [title]        Notification message title
-  # [message]      Core message for the notification
-  def self.notify stock_icon, title, message
-    options = "-t #{EXPIRATION_IN_SECONDS * 1000} -i #{stock_icon}"
-    system "notify-send #{options} '#{title}' '#{message}'"
-  end
-
-  Autotest.add_hook :red do |at|
-    notify ERROR_STOCK_ICON, "Tests failed", "#{at.files_to_test.size} tests failed"
-  end
-
-  Autotest.add_hook :green do |at|
-    notify SUCCESS_STOCK_ICON, "All tests passed, good job!", ""
-  end
-
-end
-</pre>
-<p>For this to work <strong>you need to have <a href=
-"http://trac.galago-project.org/wiki/DesktopNotifications">libnotify</a>
-installed on your system and a program named
-<code>notify-send</code> in your <code>PATH</code></strong>. For
-most Linux distributions this simply means that you should install
-the <code>libnotify-bin</code> package. If you are running Ubuntu,
-run</p>
-<pre class="command-box">
-sudo apt-get install libnotify-bin
-</pre>
-<h3 id="pretty_plugin">Pretty Plugin</h3>
-<p>If you are running Autotest on a Mac you can enable the
-<q>pretty</q> plugin to <strong>visualize your Autotest status
-history</strong> as a sequence of red and green squares:</p>
-<p class="figure"><img alt="Autotest Pretty Plugin Screenshot" src=
-"http://blog.zenspider.com/img/autotest_pretty.png" /></p>
-<p>Of course a green square indicates passing tests while a red
-square signals some test failures. If you want to get a feel of
-what a session is like with this plugin enabled, ZenSpider has a
-<a href=
-"http://vanity.zenspider.com.nyud.net:8090/~ryan/autotest_plugins.mov"
-title="ZenSpider pretty plugin video">nice video</a> demonstrating
-the pretty plugin in action.</p>
-<p>To enable this plugin <strong>you will need to install <a href=
-"http://rubycocoa.sourceforge.net/doc/" title=
-"Ruby Cocoa documentation">RubyCocoa</a></strong> and add the
-folowing line to your <code>.autotest</code> file:</p>
-<pre class="source-code-box">
-require 'autotest/pretty'
-</pre>
-<h3 id="html_report_plugin">HTML Report Plugin</h3>
-<p>The <q>HTML report</q> plugin <strong>publishes most recent
-Autotest statuses as a web page</strong> under
-<code>~/Sites/autotest.html</code>. You can then point a browser to
-this page and see something like:</p>
-<div class="sample-box">
-<div style="COLOR:green">Sat Feb 03 14:34:09 PST 2007: 0</div>
-<div style="COLOR:red">Sat Feb 03 14:33:50 PST 2007: 1</div>
-<div style="COLOR:green">Sat Feb 03 14:33:45 PST 2007: 0</div>
-<div style="COLOR:red">Sat Feb 03 14:33:29 PST 2007: 4</div>
-<div style="COLOR:green">Sat Feb 03 14:33:19 PST 2007: 0</div>
-</div>
-<p>Of course the content of the web page is updated while you work.
-Note that <strong>you need to have an an existing
-<code>~/Sites</code> directory</strong> <em>before</em> you enable
-the plugin with the following line:</p>
-<pre class="source-code-box">
-require 'autotest/html_report'
-</pre>
-<h3 id="menu_plugin">Menu Plugin</h3>
-<p>Remember that, by default, hitting <code>Ctrl - C</code> once
-will force Autotest to run the entire test suite, and hitting
-<code>Ctrl - C</code> twice will stop Autotest? The <q>menu</q>
-plugin changes this behavior: each time you hit <code>Ctrl -
-C</code> it will explicitly ask you whether you want to quit,
-restart or just keep going.</p>
-<pre class="command-box">
-c: continue q: quit r: restart menu&gt;
-</pre>
-<p>Enable the menu plugin by adding the following line to your
-<code>.autotest</code> file.</p>
-<pre class="source-code-box">
-require 'autotest/menu'
-</pre>
-<h3 id="timestamp_plugin">Timestamp Plugin</h3>
-<p>While Autotest waits for you to save a file, the timestamp
-plugin prints a message with the current time. Messages look
-like:</p>
-<pre class="command-box">
-# waiting... Sat Feb 03 15:56:23 EST 2007
-</pre>
-<p>To enable the timestamp plugin add the following to your
-<code>.autotest</code> file:</p>
-<pre class="source-code-box">
-require 'autotest/timestamp'
-</pre>
-<h3>Getting More Information</h3>
-<p>Your Autotest install comes with a sample <code>.autotest</code>
-file listing all available plugins. It is named
-<code>example_dot_autotest.rb</code>. You will find it in the gems
-install directory. Most likely this directory will look like:</p>
-<ul>
-<li><code>/usr/local/lib/ruby/gems/1.8/gems/ZenTest-3.4.3/</code>
-on OS X.</li>
-<li><code>/usr/lib/ruby/gems/1.8/gems/ZenTest-3.4.3/</code> on
-other Unix platforms</li>
-</ul>
-<p>Interesting plugins that are not distributed with Autotest can
-also be found within <a href=
-"http://rubyforge.org/tracker/?atid=1680&amp;group_id=419&amp;func=browse">
-autotest pending patches</a>. The <a href=
-"http://rspec.rubyforge.org/" title=
-"RSpec project website">RSpec</a> patches you will find there will
-be of particular interest to those of you that enjoy <a href=
-"http://behaviour-driven.org/" title=
-"Official Behavior Driven Development website">behavior-driven
-development</a>.</p>
-<h2 id="troubleshoot_test_detection">Troubleshooting Autotest Test
-Detection</h2>
-<p>Whether Autotest does not work out of the box for you or its
-magics eludes you, it is always good to get some understanding of
-the heuristics that Autotest uses to figure which test(s) to
-run.</p>
-<h3 id="rails_heuristics">Heuristics for Rails</h3>
-<p>Autotest automatically discovers Ruby on Rails projects by
-checking for a <code>config/environment.rb</code> file. If there is
-one, Autotest will base its logic on standard Rails file mappings
-and conventions.</p>
-<p>If for some reason you want to force Ruby on Rails mode you can
-always launch Autotest it with the <code>-rails</code> option:</p>
-<pre class="command-box">
-$ autotest -rails
-</pre>
-<p>A <em>simplified</em> version of Autotest heuristics in this
-mode would be:</p>
-<ul>
-<li>When changing a test file, only this file is run (e.g.
-<code>test/unit/foo_test.rb</code> &rarr;
-<code>test/unit/foo_test.rb</code>).</li>
-<li>When changing a model file, only associated unit test file is
-run (e.g. <code>app/models/foo.rb</code> &rarr;
-<code>test/unit/foo_test.rb</code>).</li>
-<li>When changing a controller file, associated functional test
-file is run (e.g. <code>app/controllers/foo_controller.rb</code>
-&rarr; <code>test/functional/foo_controller_test.rb</code>).</li>
-<li>When changing a fixture file, associated unit test and
-functional test are run (e.g. <code>app/fixtures/foos.yml</code>
-&rarr; <code>test/unit/foo_test.rb</code> +
-<code>test/functional/foo_controller_test.rb</code>).</li>
-<li>When changing a helper file, associated functional test file is
-run (e.g. <code>app/helpers/foo_helper.rb</code> &rarr;
-<code>test/functional/foo_controller_test.rb</code>).</li>
-<li>When changing <code>application_helper.rb</code> file all
-functional test files are run (e.g.
-<code>application_helper.rb</code> &rarr;
-<code>test/functional/*_test.rb</code>).</li>
-<li>When changing a file under the <code>config</code> directory,
-all tests are run.</li>
-</ul>
-<p>You've got the idea. Actual heuristics are a little more complex
-and also handle the concept of <code>view</code> and
-<code>controller</code> tests. <strong>For a more thourough
-understanding have look at the <code>rails_autotest.rb</code>
-file</strong> in ZenTest gem install directory.</p>
-<p>In case these heuristics do not play well with your own
-conventions, do not give up yet: <strong>you can always configure
-Autotest to <a href=
-"getting_started_with_autotest#running_whole_test_suite">run the
-whole test suite for all changes</a></strong>.</p>
-<h3 id="ruby_heuristics">Heuristics for Non Rails Projects</h3>
-<p>For non Rails project, Autotest uses a simple naming scheme to
-map implementation files to test files:</p>
-<ul>
-<li>Test files must be stored in the <code>test</code>
-directory</li>
-<li>Implementation files must be stored in the <code>lib</code>
-directory</li>
-<li>Test files names must start with <code>test_</code></li>
-<li>Test class names must start with <code>Test</code></li>
-<li>Test files corresponding to a specific implementation file must
-be named <code>test_*<span class="placeholder">name of
-implementation file</span>.rb</code></li>
-</ul>
-<p>If you can live with these conventions, Autotest will work
-out-of-the-box for you. If these conventions are not your cup of
-tea and you have your own, the next paragraph explains how to
-configure Autotest so that it runs the whole test suite each time
-you save a file.</p>
-<h3 id="running_whole_test_suite">Running the Whole Test Suite for
-All Changes</h3>
-<p>If for some reason Autotest heuristics do not work for you, you
-can customize them in your <code>.autotest</code> file with a
-little bit of work.</p>
-<p>For instance, if your entire test suite runs quickly (as it
-should), you can easily configure Autotest to run the whole test
-suite for any change by adding the following code to your
-<code>.autotest</code> file:</p>
-<pre class="command-box">
-#
-# Override autotest default magic deciding which test to run when
-# a file is changed : enable more flexible naming conventions
-# trading some of the efficiency: we rerun all the tests each time.
-#
-class Autotest
-
-  def test_files_for(filename)
-    return Dir["test/**/*.rb"]
-  end 
-
-end
-</pre>
-<h2>Conclusion</h2>
-<p>Autotest provides an easy and effortless way to run your tests:
-just save a file. This is a great way to get quick feedback on your
-code and avoid any context switch. Autotest automated test runs are
-also extremelly valuable if your favorite IDE has poor Ruby
-support, or if you prefer a more ligthweight development
-environment (text editor + terminal + Autotest).</p>
-<p>Autotest also tries hard to be smart on deciding which tests to
-run:</p>
-<ul>
-<li>It only runs the tests affected by your latest code
-changes.</li>
-<li>When some tests fail, Autotest focuses on running previous
-failures until you have fixed them. Once they pass, the full test
-suite is run to ensure that nothing else was inadvertently
-broken.</li>
-</ul>
-<p>On deciding which tests to run, Autotest <q>magic</q> works out
-of the box if your application follows classic Ruby on Rails
-conventions. If this is not your cup of tea, it is extremely easy
-to customize Autotest to fit your conventions.</p>
-<p>Via its plugins Autotest also offers a lot of interesting
-feedback options, from terminal output to html publishing to
-desktop notifications. The pretty plugin offers a highly visual
-representation of your test runs history, which could be useful
-when teaching Test Driven Development (green, red, green, red,
-...).</p>
-<p>On the flip side, It is important to note that Autotest does not
-fit all developement styles: Some developers like better control on
-which tests they are running. While working on a piece of code,
-they will typically focuss on a few tests (which they know they
-could have broken), and then run the whole test suite just before
-committing. Autotest emulates this as well as it can with his focus
-on running previous failures; but ultimately a human will always
-have a better intuition, especially if your project does not follow
-classic Rails conventions.</p>
-<p>In all cases, it is worth spending some time playing with
-Autotest and experiment with its innovative, lightweight and
-effortless approach to test runs, what I have been calling
-<q>continuous testing</q>.</p>
-</div>
-<p class="Copyright">&copy; Copyright Philippe Hanrigou, all rights
-reserved.</p>
-<p class="License">This work is licensed under a <a rel="license"
-href="http://creativecommons.org/licenses/by/2.5/">Creative Commons
-Attribution 2.5 License</a>.</p>
-<p class="License">Used and distributed with permission from
-Philippe Hanrigou.</p>
-</body>
-</html>