SlimTest 4.6.1.1
Sign up to get free protection for your applications and to get access to all the features.
- data/.autotest +21 -0
- data/.gemtest +0 -0
- data/History.txt +795 -0
- data/Manifest.txt +38 -0
- data/README.txt +107 -0
- data/Rakefile +52 -0
- data/articles/Article.css +721 -0
- data/articles/getting_started_with_autotest.html +533 -0
- data/articles/how_to_use_zentest.txt +393 -0
- data/bin/slim-autotest +6 -0
- data/bin/slim-multigem +4 -0
- data/bin/slim-multiruby +76 -0
- data/bin/slim-multiruby_setup +74 -0
- data/bin/slim-unit_diff +38 -0
- data/bin/slim-zentest +23 -0
- data/example.txt +42 -0
- data/example1.rb +7 -0
- data/example2.rb +15 -0
- data/example_dot_autotest.rb +16 -0
- data/lib/autotest.rb +852 -0
- data/lib/autotest/autoupdate.rb +26 -0
- data/lib/autotest/bundler.rb +10 -0
- data/lib/autotest/isolate.rb +19 -0
- data/lib/autotest/once.rb +9 -0
- data/lib/autotest/preload.rb +56 -0
- data/lib/autotest/rcov.rb +27 -0
- data/lib/autotest/restart.rb +14 -0
- data/lib/autotest/timestamp.rb +9 -0
- data/lib/focus.rb +25 -0
- data/lib/functional_test_matrix.rb +92 -0
- data/lib/multiruby.rb +412 -0
- data/lib/unit_diff.rb +274 -0
- data/lib/zentest.rb +594 -0
- data/lib/zentest_mapping.rb +117 -0
- data/test/test_autotest.rb +527 -0
- data/test/test_focus.rb +35 -0
- data/test/test_unit_diff.rb +372 -0
- data/test/test_zentest.rb +566 -0
- data/test/test_zentest_mapping.rb +242 -0
- metadata +151 -0
|
@@ -0,0 +1,533 @@
|
|
|
1
|
+
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
|
2
|
+
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
3
|
+
<html xml:lang="en-US" lang="en-US" xmlns=
|
|
4
|
+
"http://www.w3.org/1999/xhtml">
|
|
5
|
+
<head>
|
|
6
|
+
<title>PH7 - Getting started with Autotest - Continuous
|
|
7
|
+
Testing</title>
|
|
8
|
+
<link href="Article.css" media="all" rel="Stylesheet" type="text/css" />
|
|
9
|
+
</head>
|
|
10
|
+
<body>
|
|
11
|
+
<div class="content">
|
|
12
|
+
<h1>NOTE: This article was written in 2007. It is out of date.</h1>
|
|
13
|
+
<h1 style="text-align: center;">Getting started with Autotest -
|
|
14
|
+
Continuous Testing</h1>
|
|
15
|
+
<div id="abstract" class="Abstract">
|
|
16
|
+
<p class="first">Why manually run your tests, when the computer can
|
|
17
|
+
do it for you! <a href=
|
|
18
|
+
"http://www.zenspider.com/ZSS/Products/ZenTest/">Autotest</a> is a
|
|
19
|
+
great tool to speed up test-driven development with Ruby or Ruby on
|
|
20
|
+
Rails. Autotest makes your coding session even more productive as
|
|
21
|
+
<strong>it automatically runs a subset of your test suite each time
|
|
22
|
+
you change a file. Autotest is smart -- it figures out which subset
|
|
23
|
+
to run based on the files you've changed.</strong> Think of it as
|
|
24
|
+
<strong><q>Continuous Testing</q></strong>.</p>
|
|
25
|
+
<p>Autotest source code is well-documented (<a href=
|
|
26
|
+
"http://zentest.rubyforge.org/ZenTest/" title=
|
|
27
|
+
"ZenTest documentation">rdoc</a>) but finding a high level overview
|
|
28
|
+
online is a little more challenging. This article will get you up
|
|
29
|
+
and running in no time, so that you may concentrate on writing
|
|
30
|
+
code. <a href="getting_started_with_autotest">Let's get
|
|
31
|
+
started!</a></p>
|
|
32
|
+
</div>
|
|
33
|
+
<h2 id="why_autotest">Why Autotest?</h2>
|
|
34
|
+
<h3 id="continuous_testing">Continuous Testing</h3>
|
|
35
|
+
<p>The cool thing about Autotest is that you have <strong>instant
|
|
36
|
+
feedback on your code</strong> (tests run within a second). Even
|
|
37
|
+
better, <strong>the testing happens on its own</strong> so
|
|
38
|
+
<strong>you no longer have to switch back and forth</strong> from
|
|
39
|
+
the coding context to the testing context anymore (both wise
|
|
40
|
+
cognitively and from a <acronym title="User Interface">UI</acronym>
|
|
41
|
+
perspective). This effortless and immediate feedback on your code
|
|
42
|
+
as well as the automated and unattended test runs are quite similar
|
|
43
|
+
to the characteristics of <a href=
|
|
44
|
+
"http://www.martinfowler.com/articles/continuousIntegration.html"
|
|
45
|
+
title=
|
|
46
|
+
"Martin Fowler's legendary introduction to Continuous Integration">Continuous
|
|
47
|
+
Integration</a> at the team level. However, continuous integration
|
|
48
|
+
concentrates on improving <em>integration</em> at a <em>team</em>
|
|
49
|
+
level while Autotest concentrates on facilitating the
|
|
50
|
+
<em>development</em> for a <em>single</em> developer (or
|
|
51
|
+
programming-pair) <em>before</em> the code gets integrated -- hence
|
|
52
|
+
the term <strong><dfn>Continuous Testing</dfn></strong>.</p>
|
|
53
|
+
<p>As this is highly visual, <strong>have a look at Nuby on Rails'
|
|
54
|
+
<a href="http://topfunky.com/clients/blog/autotest-tm.mov">autotest
|
|
55
|
+
screencast</a></strong>.</p>
|
|
56
|
+
<h3 id="quicker_test_runs">Quicker Test Runs</h3>
|
|
57
|
+
<p>Autotest can also provide <strong>quicker test runs</strong>
|
|
58
|
+
than standard convention since it intelligently monitors the
|
|
59
|
+
changes and only runs the tests that are impacted by these changes.
|
|
60
|
+
In practice this is relevant only for <q>classic</q> Rails
|
|
61
|
+
applications because:</p>
|
|
62
|
+
<ul>
|
|
63
|
+
<li><strong>Rails conventions provide good heuristics</strong> for
|
|
64
|
+
Autotest to decide which tests to run when a file changes. If your
|
|
65
|
+
application does not stick to the classic Rails layout and naming
|
|
66
|
+
conventions the <q>magic</q> does not work so well anymore. In this
|
|
67
|
+
case, it is probably better to have Autotest <a href=
|
|
68
|
+
"getting_started_with_autotest#running_whole_test_suite">run your
|
|
69
|
+
whole test suite for all changes</a>.</li>
|
|
70
|
+
<li>There is value in running a <em>subset</em> of the whole test
|
|
71
|
+
suite <strong>only because running <q>classic</q> Rails unit tests
|
|
72
|
+
can be slow</strong>. This is mostly since Rails approach to unit
|
|
73
|
+
testing is quite unconventional and involves database access. This
|
|
74
|
+
approach goes against general <q>agile</q> wisdom that you should
|
|
75
|
+
make sure your unit tests run quickly, and do not have any
|
|
76
|
+
dependency for external systems. Also note that there are <a href=
|
|
77
|
+
"http://jayfields.blogspot.com/2006/06/ruby-on-rails-unit-tests.html">
|
|
78
|
+
well-documented ways</a> to have your Rails unit tests not depend
|
|
79
|
+
on the database and have them run blazing fast!</li>
|
|
80
|
+
</ul>
|
|
81
|
+
<h3 id="lack_of_proper_ide">Make Up for a Lack of a Proper Ruby
|
|
82
|
+
IDE</h3>
|
|
83
|
+
<p>Autotest can come in handy if your favorite IDE has limited Ruby
|
|
84
|
+
support, or if you prefer a more ligthweight development
|
|
85
|
+
environment (text editor + terminal + Autotest): it gives you an
|
|
86
|
+
easy and automated way to run your tests.</p>
|
|
87
|
+
<h2 id="install_autotest">Install Autotest</h2>
|
|
88
|
+
<h3>Make Sure You Already have RubyGem Installed</h3>
|
|
89
|
+
<p>The easiest way to install <code>Autotest</code> is to use the
|
|
90
|
+
<strong>ZenTest gem</strong>. If you have no idea of what a
|
|
91
|
+
<dfn>gem</dfn> is, or you have not installed the RubyGem packaging
|
|
92
|
+
system yet, please have a look at the <a href=
|
|
93
|
+
"http://rubygems.org/">RubyGem official website</a>. If you are
|
|
94
|
+
serious about Ruby development, it will be hard <em>not</em> to use
|
|
95
|
+
RubyGem.</p>
|
|
96
|
+
<h3 id="install_osx_ubuntu">OS X and Ubuntu</h3>
|
|
97
|
+
<p>On OS X or Ubuntu launch from a terminal:</p>
|
|
98
|
+
<pre class="command-box">
|
|
99
|
+
$ sudo gem install ZenTest
|
|
100
|
+
</pre>
|
|
101
|
+
<h3 id="install_other_unix">Other Unix flavors</h3>
|
|
102
|
+
<p>For other *Nix flavors, try</p>
|
|
103
|
+
<pre class="command-box">
|
|
104
|
+
$ suPassword:<span class=
|
|
105
|
+
"placeholder">Type root password here</span>$ gem install ZenTest
|
|
106
|
+
</pre>
|
|
107
|
+
<h2 id="run_autotest">Run autotest</h2>
|
|
108
|
+
<h3 id="run_rails">Ruby on Rails project</h3>
|
|
109
|
+
<p>Consistent with Rails principles, Autotest does not require any
|
|
110
|
+
configuration to run. Provided you follow classic Rails
|
|
111
|
+
conventions, Autotest will figure things out on its own.
|
|
112
|
+
<strong>Simply launch Autotest from the base directory of your Ruby
|
|
113
|
+
on Rails project.</strong></p>
|
|
114
|
+
<pre class="command-box">
|
|
115
|
+
$ cd <span class=
|
|
116
|
+
"placeholder">base directory of your Ruby on Rails project</span>$ autotest
|
|
117
|
+
</pre>
|
|
118
|
+
<p>Autotest will then run all your tests (the first time), and wait
|
|
119
|
+
for you to modify some code:</p>
|
|
120
|
+
<pre class="command-box">
|
|
121
|
+
$ autotest
|
|
122
|
+
/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
|
|
123
|
+
Loaded suite -e
|
|
124
|
+
Started
|
|
125
|
+
.......................
|
|
126
|
+
Finished in 0.672928 seconds.
|
|
127
|
+
|
|
128
|
+
================================================================================
|
|
129
|
+
<strong>23 tests, 60 assertions, 0 failures, 0 errors</strong>
|
|
130
|
+
</pre>
|
|
131
|
+
<p>Go ahead and <strong>modify some code in your project so that a
|
|
132
|
+
test fails.</strong> Save the modified file to disk and Autotest
|
|
133
|
+
will automatically rerun some of the tests:</p>
|
|
134
|
+
<pre class="command-box">
|
|
135
|
+
/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
|
|
136
|
+
Loaded suite -e
|
|
137
|
+
Started
|
|
138
|
+
...F........
|
|
139
|
+
Finished in 0.42272 seconds.
|
|
140
|
+
|
|
141
|
+
1) Failure:
|
|
142
|
+
test_should_be_found(TaskTest) [<strong>./test/unit/task_test.rb:22</strong>]:
|
|
143
|
+
--- /tmp/diff6647.0 2006-11-15 20:46:43.000000000 -0800
|
|
144
|
+
+++ /tmp/diff6647.1 2006-11-15 20:46:43.000000000 -0800
|
|
145
|
+
@@ -1 +1 @@
|
|
146
|
+
<strong>
|
|
147
|
+
-Expected result
|
|
148
|
+
+Actual result</strong>
|
|
149
|
+
|
|
150
|
+
================================================================================
|
|
151
|
+
<strong>4 tests, 9 assertions, 1 failures, 0 errors</strong>
|
|
152
|
+
</pre>
|
|
153
|
+
<p>Note that autotest ran only a <em>subset</em> of your test suite
|
|
154
|
+
this time (4 tests out of 23 in my case). Also note that
|
|
155
|
+
<strong>Autotest is especially good in providing brief and relevant
|
|
156
|
+
feedback on the test failures</strong>.</p>
|
|
157
|
+
<p>Autotest focuses on running previous failures until you have
|
|
158
|
+
fixed them. So <strong>test failures are run until they have all
|
|
159
|
+
passed. Then the full test suite is run</strong> to ensure that
|
|
160
|
+
nothing else was inadvertently broken.</p>
|
|
161
|
+
<h3 id="run_ruby">Ruby Project</h3>
|
|
162
|
+
<p>In theory you would run Autotest the same way as you would for
|
|
163
|
+
any Ruby project -- even if it is not based on Rails:</p>
|
|
164
|
+
<pre class="command-box">
|
|
165
|
+
$ cd <span class=
|
|
166
|
+
"placeholder">base directory of your Ruby project</span>$ autotest
|
|
167
|
+
</pre>
|
|
168
|
+
<p>In practice, Autotest might have problems finding your tests or
|
|
169
|
+
figuring out which tests to run when you change some code. If this
|
|
170
|
+
is the case, take a look at the <a href=
|
|
171
|
+
"getting_started_with_autotest#troubleshoot_test_detection"><q>troubleshooting
|
|
172
|
+
test detection</q></a> section.</p>
|
|
173
|
+
<h3 id="full_test_run">Forcing a Full Test Run and Stopping
|
|
174
|
+
Autotest</h3>
|
|
175
|
+
<p><strong>If you want to force Autotest to run the <em>entire</em>
|
|
176
|
+
test suite</strong> <strong>hit <kbd>Ctrl - C</kbd> once</strong>
|
|
177
|
+
in the terminal running Autotest. Hitting <kbd>Ctrl - C</kbd> twice
|
|
178
|
+
will stop Autotest.</p>
|
|
179
|
+
<h2 id="configure_plugins">Configure Plugins</h2>
|
|
180
|
+
<p>Autotest also provides some cool plugins that enable you to
|
|
181
|
+
<strong>get feedback the way you want</strong>.</p>
|
|
182
|
+
<h3 id="create_dot_autotest">Create a <code>.autotest</code>
|
|
183
|
+
file</h3>
|
|
184
|
+
<p><strong>You configure plugins by creating a
|
|
185
|
+
<code>.autotest</code> file in your project base
|
|
186
|
+
directory</strong>. You can also provide a default configuration
|
|
187
|
+
for all your projects by creating a <code>.autotest</code> file in
|
|
188
|
+
your home directory (when present, project configuration files
|
|
189
|
+
override user default configuration file).</p>
|
|
190
|
+
<p><strong>You enable a plugin by adding a line requiring the
|
|
191
|
+
plugin in the <code>.autotest</code> file</strong>. For instance,
|
|
192
|
+
to enable the <q>Growl</q> plugin, you would add the following
|
|
193
|
+
line:</p>
|
|
194
|
+
<pre class="source-code-box">
|
|
195
|
+
require 'autotest/growl'
|
|
196
|
+
</pre>
|
|
197
|
+
<p>Below you will find a description of the most popular plugins
|
|
198
|
+
and how to enable them.</p>
|
|
199
|
+
<h3 id="red_green_plugin">Red / Green Plugin</h3>
|
|
200
|
+
<p>The <q>Red / Green</q> plugin provides color to
|
|
201
|
+
<code>Autotest</code> messages in the terminal window. As expected,
|
|
202
|
+
output is green if all the tests pass, red if some test fails.
|
|
203
|
+
Having red / green visual output makes it easier for one to scan
|
|
204
|
+
the output and quickly determine whether everything is OK or
|
|
205
|
+
something went wrong.</p>
|
|
206
|
+
<p>Visually, the <q>Red /Green</q> plugin turns</p>
|
|
207
|
+
<pre class="command-box">
|
|
208
|
+
================================================================================
|
|
209
|
+
200 tests, 520 assertions, 0 failures, 0 errors
|
|
210
|
+
</pre>
|
|
211
|
+
<p>into</p>
|
|
212
|
+
<pre class="command-box" style="color: green;">
|
|
213
|
+
================================================================================
|
|
214
|
+
200 tests, 520 assertions, 0 failures, 0 errors
|
|
215
|
+
</pre>
|
|
216
|
+
<p>or</p>
|
|
217
|
+
<pre class="command-box" style="color: red;">
|
|
218
|
+
================================================================================
|
|
219
|
+
5 tests, 20 assertions, 1 failures, 0 errors
|
|
220
|
+
</pre>
|
|
221
|
+
<p>To enable the <q>Red / Green</q> plugin add the following line
|
|
222
|
+
to your <code>.autotest</code> file:</p>
|
|
223
|
+
<pre class="source-code-box">
|
|
224
|
+
require 'autotest/redgreen'
|
|
225
|
+
</pre>
|
|
226
|
+
<h3 id="desktop_notification_plugins">Desktop Notification
|
|
227
|
+
Plugins</h3>
|
|
228
|
+
<p>You might not even have to look at <code>the Autotest</code>
|
|
229
|
+
terminal output to figure out the result of a test run.
|
|
230
|
+
<strong>Several plugins provide desktop notification messages
|
|
231
|
+
capabilities</strong>. In this way you can run Autotest in the
|
|
232
|
+
background and see popup messages when something fails.</p>
|
|
233
|
+
<h4 id="growl_plugin">Growl Plugin (OS X)</h4>
|
|
234
|
+
<p><a href="http://growl.info/">Growl</a> is a popular desktop
|
|
235
|
+
notification system for OSX. If you are developing on a Mac, enable
|
|
236
|
+
the Growl plugin by adding</p>
|
|
237
|
+
<pre class="source-code-box">
|
|
238
|
+
require 'autotest/growl'
|
|
239
|
+
</pre>
|
|
240
|
+
<p>to your <code>.autotest</code> file. Note that for this plugin
|
|
241
|
+
to work, you not only need to install <a href="http://growl.info/"
|
|
242
|
+
title="Growl website">Growl</a> <strong>but also its command line
|
|
243
|
+
interface: <a href=
|
|
244
|
+
"http://growl.info/documentation/growlnotify.php">growlnotify</a>.</strong></p>
|
|
245
|
+
<h4 id="snarl_plugin">Snarl Plugin (Windows)</h4>
|
|
246
|
+
<p><a href="http://www.fullphat.net/">Snarl</a> is a notification
|
|
247
|
+
system for Windows largely inspired by Growl. Autotest will use it
|
|
248
|
+
if you enable the Snarl plugin in your <code>.autotest</code>
|
|
249
|
+
file:</p>
|
|
250
|
+
<pre class="source-code-box">
|
|
251
|
+
require 'autotest/snarl'
|
|
252
|
+
</pre>
|
|
253
|
+
<h4 id="kde_notify_plugin">KDE Notify Plugin (Linux)</h4>
|
|
254
|
+
<p>If you are running Linux and use KDE as your desktop
|
|
255
|
+
environment, you will get desktop notification by adding to your
|
|
256
|
+
<code>.autotest</code> file:</p>
|
|
257
|
+
<pre class="source-code-box">
|
|
258
|
+
require 'autotest/kdenotify'
|
|
259
|
+
</pre>
|
|
260
|
+
<h4 id="gnome_notify_plugin">Gnome Notify plugin (Linux)</h4>
|
|
261
|
+
<p>If you are running Linux and use Gnome as your desktop
|
|
262
|
+
environment, unfortunately there is no official plugin for desktop
|
|
263
|
+
notification. You can still get desktop notifications by adding the
|
|
264
|
+
following code snipet in your <code>.autotest</code> file:</p>
|
|
265
|
+
<pre class="source-code-box">
|
|
266
|
+
module Autotest::GnomeNotify
|
|
267
|
+
|
|
268
|
+
# Time notification will be displayed before disappearing automatically
|
|
269
|
+
EXPIRATION_IN_SECONDS = 2
|
|
270
|
+
ERROR_STOCK_ICON = "gtk-dialog-error"
|
|
271
|
+
SUCCESS_STOCK_ICON = "gtk-dialog-info"
|
|
272
|
+
|
|
273
|
+
# Convenience method to send an error notification message
|
|
274
|
+
#
|
|
275
|
+
# [stock_icon] Stock icon name of icon to display
|
|
276
|
+
# [title] Notification message title
|
|
277
|
+
# [message] Core message for the notification
|
|
278
|
+
def self.notify stock_icon, title, message
|
|
279
|
+
options = "-t #{EXPIRATION_IN_SECONDS * 1000} -i #{stock_icon}"
|
|
280
|
+
system "notify-send #{options} '#{title}' '#{message}'"
|
|
281
|
+
end
|
|
282
|
+
|
|
283
|
+
Autotest.add_hook :red do |at|
|
|
284
|
+
notify ERROR_STOCK_ICON, "Tests failed", "#{at.files_to_test.size} tests failed"
|
|
285
|
+
end
|
|
286
|
+
|
|
287
|
+
Autotest.add_hook :green do |at|
|
|
288
|
+
notify SUCCESS_STOCK_ICON, "All tests passed, good job!", ""
|
|
289
|
+
end
|
|
290
|
+
|
|
291
|
+
end
|
|
292
|
+
</pre>
|
|
293
|
+
<p>For this to work <strong>you need to have <a href=
|
|
294
|
+
"http://trac.galago-project.org/wiki/DesktopNotifications">libnotify</a>
|
|
295
|
+
installed on your system and a program named
|
|
296
|
+
<code>notify-send</code> in your <code>PATH</code></strong>. For
|
|
297
|
+
most Linux distributions this simply means that you should install
|
|
298
|
+
the <code>libnotify-bin</code> package. If you are running Ubuntu,
|
|
299
|
+
run</p>
|
|
300
|
+
<pre class="command-box">
|
|
301
|
+
sudo apt-get install libnotify-bin
|
|
302
|
+
</pre>
|
|
303
|
+
<h3 id="pretty_plugin">Pretty Plugin</h3>
|
|
304
|
+
<p>If you are running Autotest on a Mac you can enable the
|
|
305
|
+
<q>pretty</q> plugin to <strong>visualize your Autotest status
|
|
306
|
+
history</strong> as a sequence of red and green squares:</p>
|
|
307
|
+
<p class="figure"><img alt="Autotest Pretty Plugin Screenshot" src=
|
|
308
|
+
"http://blog.zenspider.com/img/autotest_pretty.png" /></p>
|
|
309
|
+
<p>Of course a green square indicates passing tests while a red
|
|
310
|
+
square signals some test failures. If you want to get a feel of
|
|
311
|
+
what a session is like with this plugin enabled, ZenSpider has a
|
|
312
|
+
<a href=
|
|
313
|
+
"http://vanity.zenspider.com.nyud.net:8090/~ryan/autotest_plugins.mov"
|
|
314
|
+
title="ZenSpider pretty plugin video">nice video</a> demonstrating
|
|
315
|
+
the pretty plugin in action.</p>
|
|
316
|
+
<p>To enable this plugin <strong>you will need to install <a href=
|
|
317
|
+
"http://rubycocoa.sourceforge.net/doc/" title=
|
|
318
|
+
"Ruby Cocoa documentation">RubyCocoa</a></strong> and add the
|
|
319
|
+
folowing line to your <code>.autotest</code> file:</p>
|
|
320
|
+
<pre class="source-code-box">
|
|
321
|
+
require 'autotest/pretty'
|
|
322
|
+
</pre>
|
|
323
|
+
<h3 id="html_report_plugin">HTML Report Plugin</h3>
|
|
324
|
+
<p>The <q>HTML report</q> plugin <strong>publishes most recent
|
|
325
|
+
Autotest statuses as a web page</strong> under
|
|
326
|
+
<code>~/Sites/autotest.html</code>. You can then point a browser to
|
|
327
|
+
this page and see something like:</p>
|
|
328
|
+
<div class="sample-box">
|
|
329
|
+
<div style="COLOR:green">Sat Feb 03 14:34:09 PST 2007: 0</div>
|
|
330
|
+
<div style="COLOR:red">Sat Feb 03 14:33:50 PST 2007: 1</div>
|
|
331
|
+
<div style="COLOR:green">Sat Feb 03 14:33:45 PST 2007: 0</div>
|
|
332
|
+
<div style="COLOR:red">Sat Feb 03 14:33:29 PST 2007: 4</div>
|
|
333
|
+
<div style="COLOR:green">Sat Feb 03 14:33:19 PST 2007: 0</div>
|
|
334
|
+
</div>
|
|
335
|
+
<p>Of course the content of the web page is updated while you work.
|
|
336
|
+
Note that <strong>you need to have an an existing
|
|
337
|
+
<code>~/Sites</code> directory</strong> <em>before</em> you enable
|
|
338
|
+
the plugin with the following line:</p>
|
|
339
|
+
<pre class="source-code-box">
|
|
340
|
+
require 'autotest/html_report'
|
|
341
|
+
</pre>
|
|
342
|
+
<h3 id="menu_plugin">Menu Plugin</h3>
|
|
343
|
+
<p>Remember that, by default, hitting <code>Ctrl - C</code> once
|
|
344
|
+
will force Autotest to run the entire test suite, and hitting
|
|
345
|
+
<code>Ctrl - C</code> twice will stop Autotest? The <q>menu</q>
|
|
346
|
+
plugin changes this behavior: each time you hit <code>Ctrl -
|
|
347
|
+
C</code> it will explicitly ask you whether you want to quit,
|
|
348
|
+
restart or just keep going.</p>
|
|
349
|
+
<pre class="command-box">
|
|
350
|
+
c: continue q: quit r: restart menu>
|
|
351
|
+
</pre>
|
|
352
|
+
<p>Enable the menu plugin by adding the following line to your
|
|
353
|
+
<code>.autotest</code> file.</p>
|
|
354
|
+
<pre class="source-code-box">
|
|
355
|
+
require 'autotest/menu'
|
|
356
|
+
</pre>
|
|
357
|
+
<h3 id="timestamp_plugin">Timestamp Plugin</h3>
|
|
358
|
+
<p>While Autotest waits for you to save a file, the timestamp
|
|
359
|
+
plugin prints a message with the current time. Messages look
|
|
360
|
+
like:</p>
|
|
361
|
+
<pre class="command-box">
|
|
362
|
+
# waiting... Sat Feb 03 15:56:23 EST 2007
|
|
363
|
+
</pre>
|
|
364
|
+
<p>To enable the timestamp plugin add the following to your
|
|
365
|
+
<code>.autotest</code> file:</p>
|
|
366
|
+
<pre class="source-code-box">
|
|
367
|
+
require 'autotest/timestamp'
|
|
368
|
+
</pre>
|
|
369
|
+
<h3>Getting More Information</h3>
|
|
370
|
+
<p>Your Autotest install comes with a sample <code>.autotest</code>
|
|
371
|
+
file listing all available plugins. It is named
|
|
372
|
+
<code>example_dot_autotest.rb</code>. You will find it in the gems
|
|
373
|
+
install directory. Most likely this directory will look like:</p>
|
|
374
|
+
<ul>
|
|
375
|
+
<li><code>/usr/local/lib/ruby/gems/1.8/gems/ZenTest-3.4.3/</code>
|
|
376
|
+
on OS X.</li>
|
|
377
|
+
<li><code>/usr/lib/ruby/gems/1.8/gems/ZenTest-3.4.3/</code> on
|
|
378
|
+
other Unix platforms</li>
|
|
379
|
+
</ul>
|
|
380
|
+
<p>Interesting plugins that are not distributed with Autotest can
|
|
381
|
+
also be found within <a href=
|
|
382
|
+
"http://rubyforge.org/tracker/?atid=1680&group_id=419&func=browse">
|
|
383
|
+
autotest pending patches</a>. The <a href=
|
|
384
|
+
"http://rspec.rubyforge.org/" title=
|
|
385
|
+
"RSpec project website">RSpec</a> patches you will find there will
|
|
386
|
+
be of particular interest to those of you that enjoy <a href=
|
|
387
|
+
"http://behaviour-driven.org/" title=
|
|
388
|
+
"Official Behavior Driven Development website">behavior-driven
|
|
389
|
+
development</a>.</p>
|
|
390
|
+
<h2 id="troubleshoot_test_detection">Troubleshooting Autotest Test
|
|
391
|
+
Detection</h2>
|
|
392
|
+
<p>Whether Autotest does not work out of the box for you or its
|
|
393
|
+
magics eludes you, it is always good to get some understanding of
|
|
394
|
+
the heuristics that Autotest uses to figure which test(s) to
|
|
395
|
+
run.</p>
|
|
396
|
+
<h3 id="rails_heuristics">Heuristics for Rails</h3>
|
|
397
|
+
<p>Autotest automatically discovers Ruby on Rails projects by
|
|
398
|
+
checking for a <code>config/environment.rb</code> file. If there is
|
|
399
|
+
one, Autotest will base its logic on standard Rails file mappings
|
|
400
|
+
and conventions.</p>
|
|
401
|
+
<p>If for some reason you want to force Ruby on Rails mode you can
|
|
402
|
+
always launch Autotest it with the <code>-rails</code> option:</p>
|
|
403
|
+
<pre class="command-box">
|
|
404
|
+
$ autotest -rails
|
|
405
|
+
</pre>
|
|
406
|
+
<p>A <em>simplified</em> version of Autotest heuristics in this
|
|
407
|
+
mode would be:</p>
|
|
408
|
+
<ul>
|
|
409
|
+
<li>When changing a test file, only this file is run (e.g.
|
|
410
|
+
<code>test/unit/foo_test.rb</code> →
|
|
411
|
+
<code>test/unit/foo_test.rb</code>).</li>
|
|
412
|
+
<li>When changing a model file, only associated unit test file is
|
|
413
|
+
run (e.g. <code>app/models/foo.rb</code> →
|
|
414
|
+
<code>test/unit/foo_test.rb</code>).</li>
|
|
415
|
+
<li>When changing a controller file, associated functional test
|
|
416
|
+
file is run (e.g. <code>app/controllers/foo_controller.rb</code>
|
|
417
|
+
→ <code>test/functional/foo_controller_test.rb</code>).</li>
|
|
418
|
+
<li>When changing a fixture file, associated unit test and
|
|
419
|
+
functional test are run (e.g. <code>app/fixtures/foos.yml</code>
|
|
420
|
+
→ <code>test/unit/foo_test.rb</code> +
|
|
421
|
+
<code>test/functional/foo_controller_test.rb</code>).</li>
|
|
422
|
+
<li>When changing a helper file, associated functional test file is
|
|
423
|
+
run (e.g. <code>app/helpers/foo_helper.rb</code> →
|
|
424
|
+
<code>test/functional/foo_controller_test.rb</code>).</li>
|
|
425
|
+
<li>When changing <code>application_helper.rb</code> file all
|
|
426
|
+
functional test files are run (e.g.
|
|
427
|
+
<code>application_helper.rb</code> →
|
|
428
|
+
<code>test/functional/*_test.rb</code>).</li>
|
|
429
|
+
<li>When changing a file under the <code>config</code> directory,
|
|
430
|
+
all tests are run.</li>
|
|
431
|
+
</ul>
|
|
432
|
+
<p>You've got the idea. Actual heuristics are a little more complex
|
|
433
|
+
and also handle the concept of <code>view</code> and
|
|
434
|
+
<code>controller</code> tests. <strong>For a more thourough
|
|
435
|
+
understanding have look at the <code>rails_autotest.rb</code>
|
|
436
|
+
file</strong> in ZenTest gem install directory.</p>
|
|
437
|
+
<p>In case these heuristics do not play well with your own
|
|
438
|
+
conventions, do not give up yet: <strong>you can always configure
|
|
439
|
+
Autotest to <a href=
|
|
440
|
+
"getting_started_with_autotest#running_whole_test_suite">run the
|
|
441
|
+
whole test suite for all changes</a></strong>.</p>
|
|
442
|
+
<h3 id="ruby_heuristics">Heuristics for Non Rails Projects</h3>
|
|
443
|
+
<p>For non Rails project, Autotest uses a simple naming scheme to
|
|
444
|
+
map implementation files to test files:</p>
|
|
445
|
+
<ul>
|
|
446
|
+
<li>Test files must be stored in the <code>test</code>
|
|
447
|
+
directory</li>
|
|
448
|
+
<li>Implementation files must be stored in the <code>lib</code>
|
|
449
|
+
directory</li>
|
|
450
|
+
<li>Test files names must start with <code>test_</code></li>
|
|
451
|
+
<li>Test class names must start with <code>Test</code></li>
|
|
452
|
+
<li>Test files corresponding to a specific implementation file must
|
|
453
|
+
be named <code>test_*<span class="placeholder">name of
|
|
454
|
+
implementation file</span>.rb</code></li>
|
|
455
|
+
</ul>
|
|
456
|
+
<p>If you can live with these conventions, Autotest will work
|
|
457
|
+
out-of-the-box for you. If these conventions are not your cup of
|
|
458
|
+
tea and you have your own, the next paragraph explains how to
|
|
459
|
+
configure Autotest so that it runs the whole test suite each time
|
|
460
|
+
you save a file.</p>
|
|
461
|
+
<h3 id="running_whole_test_suite">Running the Whole Test Suite for
|
|
462
|
+
All Changes</h3>
|
|
463
|
+
<p>If for some reason Autotest heuristics do not work for you, you
|
|
464
|
+
can customize them in your <code>.autotest</code> file with a
|
|
465
|
+
little bit of work.</p>
|
|
466
|
+
<p>For instance, if your entire test suite runs quickly (as it
|
|
467
|
+
should), you can easily configure Autotest to run the whole test
|
|
468
|
+
suite for any change by adding the following code to your
|
|
469
|
+
<code>.autotest</code> file:</p>
|
|
470
|
+
<pre class="command-box">
|
|
471
|
+
#
|
|
472
|
+
# Override autotest default magic deciding which test to run when
|
|
473
|
+
# a file is changed : enable more flexible naming conventions
|
|
474
|
+
# trading some of the efficiency: we rerun all the tests each time.
|
|
475
|
+
#
|
|
476
|
+
class Autotest
|
|
477
|
+
|
|
478
|
+
def test_files_for(filename)
|
|
479
|
+
return Dir["test/**/*.rb"]
|
|
480
|
+
end
|
|
481
|
+
|
|
482
|
+
end
|
|
483
|
+
</pre>
|
|
484
|
+
<h2>Conclusion</h2>
|
|
485
|
+
<p>Autotest provides an easy and effortless way to run your tests:
|
|
486
|
+
just save a file. This is a great way to get quick feedback on your
|
|
487
|
+
code and avoid any context switch. Autotest automated test runs are
|
|
488
|
+
also extremelly valuable if your favorite IDE has poor Ruby
|
|
489
|
+
support, or if you prefer a more ligthweight development
|
|
490
|
+
environment (text editor + terminal + Autotest).</p>
|
|
491
|
+
<p>Autotest also tries hard to be smart on deciding which tests to
|
|
492
|
+
run:</p>
|
|
493
|
+
<ul>
|
|
494
|
+
<li>It only runs the tests affected by your latest code
|
|
495
|
+
changes.</li>
|
|
496
|
+
<li>When some tests fail, Autotest focuses on running previous
|
|
497
|
+
failures until you have fixed them. Once they pass, the full test
|
|
498
|
+
suite is run to ensure that nothing else was inadvertently
|
|
499
|
+
broken.</li>
|
|
500
|
+
</ul>
|
|
501
|
+
<p>On deciding which tests to run, Autotest <q>magic</q> works out
|
|
502
|
+
of the box if your application follows classic Ruby on Rails
|
|
503
|
+
conventions. If this is not your cup of tea, it is extremely easy
|
|
504
|
+
to customize Autotest to fit your conventions.</p>
|
|
505
|
+
<p>Via its plugins Autotest also offers a lot of interesting
|
|
506
|
+
feedback options, from terminal output to html publishing to
|
|
507
|
+
desktop notifications. The pretty plugin offers a highly visual
|
|
508
|
+
representation of your test runs history, which could be useful
|
|
509
|
+
when teaching Test Driven Development (green, red, green, red,
|
|
510
|
+
...).</p>
|
|
511
|
+
<p>On the flip side, It is important to note that Autotest does not
|
|
512
|
+
fit all developement styles: Some developers like better control on
|
|
513
|
+
which tests they are running. While working on a piece of code,
|
|
514
|
+
they will typically focuss on a few tests (which they know they
|
|
515
|
+
could have broken), and then run the whole test suite just before
|
|
516
|
+
committing. Autotest emulates this as well as it can with his focus
|
|
517
|
+
on running previous failures; but ultimately a human will always
|
|
518
|
+
have a better intuition, especially if your project does not follow
|
|
519
|
+
classic Rails conventions.</p>
|
|
520
|
+
<p>In all cases, it is worth spending some time playing with
|
|
521
|
+
Autotest and experiment with its innovative, lightweight and
|
|
522
|
+
effortless approach to test runs, what I have been calling
|
|
523
|
+
<q>continuous testing</q>.</p>
|
|
524
|
+
</div>
|
|
525
|
+
<p class="Copyright">© Copyright Philippe Hanrigou, all rights
|
|
526
|
+
reserved.</p>
|
|
527
|
+
<p class="License">This work is licensed under a <a rel="license"
|
|
528
|
+
href="http://creativecommons.org/licenses/by/2.5/">Creative Commons
|
|
529
|
+
Attribution 2.5 License</a>.</p>
|
|
530
|
+
<p class="License">Used and distributed with permission from
|
|
531
|
+
Philippe Hanrigou.</p>
|
|
532
|
+
</body>
|
|
533
|
+
</html>
|