ZenTest 4.11.0 → 4.12.1

Sign up to get free protection for your applications and to get access to all the features.
@@ -1,533 +0,0 @@
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&gt;
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&amp;group_id=419&amp;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> &rarr;
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> &rarr;
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
- &rarr; <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
- &rarr; <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> &rarr;
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> &rarr;
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">&copy; 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>
data/bin/autotest DELETED
@@ -1,6 +0,0 @@
1
- #!/usr/bin/env ruby
2
-
3
- require 'autotest'
4
-
5
- Autotest.parse_options
6
- Autotest.runner.run
data/bin/multiruby_setup DELETED
@@ -1,74 +0,0 @@
1
- #!/usr/bin/env ruby -w
2
-
3
- require 'multiruby'
4
-
5
- ENV.delete 'RUBYOPT'
6
-
7
- ARGV << "help" if ARGV.empty?
8
-
9
- Dir.chdir Multiruby.root_dir
10
- Multiruby.setup_dirs(false)
11
-
12
- ARGV.each do |spec|
13
- case spec
14
- when "-h", "--help", "help" then
15
- Multiruby.help
16
- exit 0
17
- when "the_usual" then # TODO: update #help
18
- ARGV.push(*Multiruby::TAGS.map { |v| "mri:tar:#{v.gsub(/_/, '.')}" })
19
- ARGV << "build" << "update:rubygems"
20
- system "multigem install --no-ri --no-rdoc rake minitest ZenTest gemcutter rubyforge hoe"
21
- when "build" then
22
- Multiruby.build_and_install
23
- when "clean" then
24
- Multiruby.clean
25
- when "list" then
26
- Multiruby.list
27
- when /rm:(.*)/ then
28
- Multiruby.rm $1
29
- when "rubygems:merge" then
30
- Multiruby.merge_rubygems
31
- when "rubygems:update", "update:rubygems" then
32
- Multiruby.update_rubygems
33
- ARGV << "build"
34
- when "update" then
35
- Multiruby.update
36
- when "tags" then
37
- p Multiruby.tags
38
- when "mri:svn:current" then
39
- ARGV << "mri:svn:releases" << "mri:svn:branches" << "build"
40
- when "mri:svn:releases" then
41
- Multiruby::TAGS.each do |v|
42
- latest = Multiruby.mri_latest_tag v
43
- abort "Can't find tag #{v}" unless latest
44
- ARGV << "mri:svn:tag:#{latest}:mri_rel_#{v}"
45
- end
46
- ARGV << "build"
47
- when /mri:svn:branch:(.*)/ then
48
- ver = "branches/ruby_#{$1}" unless ver == "trunk"
49
- Multiruby.svn_co "#{Multiruby::MRI_SVN}/#{$1}", "mri_#{$1}"
50
- ARGV << "build"
51
- when "mri:svn:branches" then
52
- Multiruby::BRANCHES.each do |v|
53
- ARGV << "mri:svn:branch:#{v}"
54
- end
55
- ARGV << "build"
56
- when /mri:svn:tag:(.*):(.*)/ then
57
- Multiruby.svn_co "#{Multiruby::MRI_SVN}/tags/#{$1}", $2
58
- ARGV << "build"
59
- when /mri:svn:tag:(.*)/ then
60
- ARGV << "mri:svn:tag:#{$1}:#{$1}" << "build"
61
- when /mri:list:(.*)/ then
62
- v = $1
63
- ver = v[/\d+\.\d+/]
64
- url = "#{Multiruby::RUBY_URL}/#{ver}/"
65
-
66
- puts Multiruby.matching_versions(url, v).join("\n")
67
- when /mri:tar:(.*)/ then
68
- Multiruby.fetch_tar $1
69
- ARGV << "build"
70
- else
71
- warn "unknown spec #{spec}"
72
- end
73
- end
74
-
@@ -1,16 +0,0 @@
1
- # -*- ruby -*-
2
-
3
- # require 'autotest/autoupdate'
4
- # require 'autotest/bundler'
5
- # require 'autotest/isolate'
6
- # require 'autotest/once'
7
- # require 'autotest/rcov'
8
- # require 'autotest/restart'
9
- # require 'autotest/timestamp'
10
-
11
- # Autotest::AutoUpdate.sleep_time = o
12
- # Autotest::AutoUpdate.update_cmd = o
13
- # Autotest::Isolate.dir = o
14
- # Autotest::RCov.command = o
15
- # Autotest::RCov.pattern = o
16
- # Autotest::RCov.options = o
@@ -1,26 +0,0 @@
1
- module Autotest::AutoUpdate
2
- @@sleep_time, @@update_cmd, @@updater = 60, "svn up", nil
3
-
4
- def self.sleep_time= o
5
- @@sleep_time = o
6
- end
7
-
8
- def self.update_cmd= o
9
- @@update_cmd = o
10
- end
11
-
12
- Autotest.add_hook :run_command do |at|
13
- @@updater.kill if @@updater
14
- end
15
-
16
- Autotest.add_hook :ran_command do |at|
17
- @@updater = Thread.start do
18
- loop do
19
- puts "# Waiting for #{@@sleep_time} seconds before updating"
20
- sleep @@sleep_time
21
- puts "# Running #{@@update_cmd}"
22
- system @@update_cmd
23
- end
24
- end
25
- end
26
- end
@@ -1,10 +0,0 @@
1
- ##
2
- # Prefix all test runs with `bundle exec` so the runs use the bundled
3
- # environment.
4
-
5
- module Autotest::Bundler
6
- Autotest.add_hook :initialize do |at|
7
- at.prefix = "bundle exec "
8
- false
9
- end
10
- end