flexmock 0.9.0 → 1.0.0.beta.1
Sign up to get free protection for your applications and to get access to all the features.
- data/README.rdoc +325 -177
- data/Rakefile +22 -8
- data/TAGS +772 -669
- data/doc/releases/flexmock-1.0.0.rdoc +128 -0
- data/lib/flexmock.rb +1 -1
- data/lib/flexmock/argument_matchers.rb +16 -3
- data/lib/flexmock/argument_matching.rb +33 -0
- data/lib/flexmock/argument_types.rb +5 -1
- data/lib/flexmock/base.rb +1 -1
- data/lib/flexmock/composite.rb +3 -3
- data/lib/flexmock/core.rb +32 -2
- data/lib/flexmock/core_class_methods.rb +1 -1
- data/lib/flexmock/default_framework_adapter.rb +1 -1
- data/lib/flexmock/deprecated_methods.rb +1 -1
- data/lib/flexmock/errors.rb +1 -1
- data/lib/flexmock/expectation.rb +15 -13
- data/lib/flexmock/expectation_director.rb +1 -1
- data/lib/flexmock/explicit_needed.rb +39 -0
- data/lib/flexmock/mock_container.rb +8 -2
- data/lib/flexmock/noop.rb +1 -1
- data/lib/flexmock/ordering.rb +1 -1
- data/lib/flexmock/partial_mock.rb +12 -2
- data/lib/flexmock/rails.rb +1 -1
- data/lib/flexmock/recorder.rb +1 -1
- data/lib/flexmock/rspec.rb +5 -1
- data/lib/flexmock/rspec_spy_matcher.rb +74 -0
- data/lib/flexmock/spy_describers.rb +60 -0
- data/lib/flexmock/test_unit.rb +1 -1
- data/lib/flexmock/test_unit_assert_spy_called.rb +34 -0
- data/lib/flexmock/test_unit_integration.rb +3 -1
- data/lib/flexmock/undefined.rb +1 -1
- data/lib/flexmock/validators.rb +1 -1
- data/lib/flexmock/version.rb +4 -2
- data/test/assert_spy_called_test.rb +89 -0
- data/test/container_methods_test.rb +1 -1
- data/test/default_framework_adapter_test.rb +1 -1
- data/test/deprecated_methods_test.rb +1 -1
- data/test/examples_from_readme_test.rb +1 -1
- data/test/extended_should_receive_test.rb +1 -1
- data/test/naming_test.rb +1 -2
- data/test/new_instances_test.rb +1 -3
- data/test/partial_mock_test.rb +7 -1
- data/test/record_mode_test.rb +1 -1
- data/test/rspec_integration/integration_spec.rb +11 -3
- data/test/rspec_integration/spy_example_spec.rb +141 -0
- data/test/samples_test.rb +1 -1
- data/test/should_ignore_missing_test.rb +6 -2
- data/test/should_receive_test.rb +31 -2
- data/test/spys_test.rb +148 -0
- data/test/test_unit_integration/auto_test_unit_test.rb +1 -1
- data/test/tu_integration_test.rb +1 -1
- data/test/undefined_test.rb +1 -1
- metadata +16 -8
data/README.rdoc
CHANGED
@@ -3,7 +3,7 @@
|
|
3
3
|
FlexMock is a simple, but flexible, mock object library for Ruby unit
|
4
4
|
testing.
|
5
5
|
|
6
|
-
Version :: 0.
|
6
|
+
Version :: 1.0.0.beta.1
|
7
7
|
|
8
8
|
= Links
|
9
9
|
|
@@ -21,10 +21,11 @@ You can install FlexMock with the following command.
|
|
21
21
|
|
22
22
|
== Simple Example
|
23
23
|
|
24
|
-
We have a data acquisition class (
|
25
|
-
temperature sensor and returns an average of 3 readings.
|
26
|
-
have a _real_ temperature to use for testing, so we mock one
|
27
|
-
mock object that responds to the
|
24
|
+
We have a data acquisition class (<code>TemperatureSampler</code>)
|
25
|
+
that reads a temperature sensor and returns an average of 3 readings.
|
26
|
+
We don't have a _real_ temperature to use for testing, so we mock one
|
27
|
+
up with a mock object that responds to the
|
28
|
+
<code>read_temperature</code> message.
|
28
29
|
|
29
30
|
Here's the complete example:
|
30
31
|
|
@@ -37,8 +38,8 @@ Here's the complete example:
|
|
37
38
|
end
|
38
39
|
|
39
40
|
def average_temp
|
40
|
-
total = (0...3).collect {
|
41
|
-
@sensor.read_temperature
|
41
|
+
total = (0...3).collect {
|
42
|
+
@sensor.read_temperature
|
42
43
|
}.inject { |i, s| i + s }
|
43
44
|
total / 3.0
|
44
45
|
end
|
@@ -61,9 +62,10 @@ Example}[http://flexmock.rubyforge.org/files/doc/GoogleExample_rdoc.html].
|
|
61
62
|
== Test::Unit Integration
|
62
63
|
|
63
64
|
FlexMock integrates nicely with Test::Unit. Just require the
|
64
|
-
'flexmock/test_unit' file at the top of your test file. The
|
65
|
-
will be available for mock creation, and
|
66
|
-
automatically validated and closed at the
|
65
|
+
'flexmock/test_unit' file at the top of your test file. The
|
66
|
+
<code>flexmock</code> method will be available for mock creation, and
|
67
|
+
any created mocks will be automatically validated and closed at the
|
68
|
+
end of the individual test.
|
67
69
|
|
68
70
|
Your test case will look something like this:
|
69
71
|
|
@@ -88,7 +90,7 @@ FlexMock also supports integration with the RSpec behavior
|
|
88
90
|
specification framework. Starting with version 0.9.0 of RSpec, you
|
89
91
|
will be able to say:
|
90
92
|
|
91
|
-
|
93
|
+
RSpec.configure do |config|
|
92
94
|
config.mock_with :flexmock
|
93
95
|
end
|
94
96
|
|
@@ -99,20 +101,26 @@ will be able to say:
|
|
99
101
|
end
|
100
102
|
end
|
101
103
|
|
102
|
-
|
103
|
-
|
104
|
+
<b>NOTE:</b> <em>Older versions of RSpec used the Spec::Runner for
|
105
|
+
configuration. If you are running with a very old RSpec, you may need
|
106
|
+
the following:</em>
|
107
|
+
|
108
|
+
# Configuration for RSpec prior to RSpec 2.x
|
109
|
+
Spec::Runner.configure do |config|
|
110
|
+
config.mock_with :flexmock
|
111
|
+
end
|
104
112
|
|
105
113
|
== Quick Reference
|
106
114
|
|
107
|
-
=== Creating Mock Objects
|
115
|
+
=== Creating Mock Objects
|
108
116
|
|
109
|
-
The
|
110
|
-
configurations.
|
111
|
-
|
117
|
+
The <code>flexmock</code> method is used to create mocks in various
|
118
|
+
configurations. Here's a quick rundown of the most common options. See
|
119
|
+
FlexMock::MockContainer#flexmock for more details.
|
112
120
|
|
113
121
|
* <b>mock = flexmock("joe")</b>
|
114
122
|
|
115
|
-
Create a mock object named "joe" (the name is used in reporting errors).
|
123
|
+
Create a mock object named "joe" (the name is used in reporting errors).
|
116
124
|
|
117
125
|
* <b>mock = flexmock(:foo => :bar, :baz => :froz)</b>
|
118
126
|
|
@@ -125,13 +133,25 @@ See FlexMock::MockContainer#flexmock for more details.
|
|
125
133
|
You can combine the mock name and an expectation hash in the same call to
|
126
134
|
flexmock.
|
127
135
|
|
136
|
+
* <b>mock = flexmock("joe", :on, User)</b>
|
137
|
+
|
138
|
+
This defines a mock that is based on the User class (the class is
|
139
|
+
called the mock's "base class"). Mocks with base classes prevent you
|
140
|
+
from mocking or stubbing methods that are not instance methods of
|
141
|
+
teh base class. This helps prevent tests from becoming stale with
|
142
|
+
incorrectly mocked objects when the method names change.
|
143
|
+
|
144
|
+
Use the <code>explicit</code> modifier to
|
145
|
+
<code>should_receive</code> to override base class restrictions.
|
146
|
+
|
128
147
|
* <b>partial_mock = flexmock(real_object)</b>
|
129
148
|
|
130
|
-
If you you give
|
131
|
-
that real object as a base for a partial mock
|
132
|
-
|
133
|
-
|
134
|
-
|
149
|
+
If you you give <code>flexmock</code> a real object in the argument
|
150
|
+
list, it will treat that real object as a base for a partial mock
|
151
|
+
object. The return value <code>m</code> may be used to set
|
152
|
+
expectations. The real_object should be used in the reference
|
153
|
+
portion of the test.
|
154
|
+
|
135
155
|
* <b>partial_mock = flexmock(real_object, "name", :foo => :baz)</b>
|
136
156
|
|
137
157
|
Names and expectation hashes may be used with partial mocks as well.
|
@@ -154,7 +174,7 @@ See FlexMock::MockContainer#flexmock for more details.
|
|
154
174
|
these methods. Indicate safe mode by passing the symbol :safe as
|
155
175
|
the first argument of flexmock. A block <em>is required</em> when
|
156
176
|
using safe mode (the partial_mock returned in safe mode does not
|
157
|
-
have a
|
177
|
+
have a <code>should_receive</code> method).
|
158
178
|
|
159
179
|
The methods added to partial mocks in non-safe mode are:
|
160
180
|
|
@@ -163,13 +183,13 @@ See FlexMock::MockContainer#flexmock for more details.
|
|
163
183
|
* any_instance (note: deprecated)
|
164
184
|
* mock
|
165
185
|
* mock_teardown
|
166
|
-
* mock_setup
|
186
|
+
* mock_setup
|
167
187
|
|
168
188
|
* <b>mock = flexmock(...) { |mock| mock.should_receive(...) }</b>
|
169
189
|
|
170
|
-
If a block is given to any of the
|
171
|
-
passed to the block as an argument. Code in the
|
172
|
-
expectations for the mock object.
|
190
|
+
If a block is given to any of the <code>flexmock</code> forms, the
|
191
|
+
mock object will be passed to the block as an argument. Code in the
|
192
|
+
block can set the desired expectations for the mock object.
|
173
193
|
|
174
194
|
* <b>mock_model = flexmock(:model, YourModel, ...) { |mock| mock.should_receive(...) }</b>
|
175
195
|
|
@@ -192,17 +212,20 @@ See FlexMock::MockContainer#flexmock for more details.
|
|
192
212
|
* kind_of?(class) -- returns true if class is YourModel or one of its ancestors
|
193
213
|
* class -- returns YourModel.
|
194
214
|
|
195
|
-
<b>
|
196
|
-
|
197
|
-
|
198
|
-
|
215
|
+
* <b>mock = flexmock(... :spy_on, class_object, ...)</b>
|
216
|
+
|
217
|
+
<b>NOTE:</b> Versions of FlexMock prior to 0.6.0 used
|
218
|
+
<code>flexstub</code> to create partial mocks. The
|
219
|
+
<code>flexmock</code> method now assumes all the functionality that
|
220
|
+
was spread out between two different methods. <code>flexstub</code> is
|
221
|
+
still available for backward compatibility.
|
199
222
|
|
200
223
|
=== Expectation Declarators
|
201
224
|
|
202
225
|
Once a mock is created, you need to define what that mock should expect to
|
203
226
|
see. Expectation declarators are used to specify these expectations placed
|
204
227
|
upon received method calls. A basic expectation, created with the
|
205
|
-
|
228
|
+
<code>should_receive</code> method, just establishes the fact that a method may (or may
|
206
229
|
not) be called on the mock object. Refinements to that expectation may be
|
207
230
|
additionally declared. FlexMock always starts with the most general
|
208
231
|
expectation and adds constraints to that.
|
@@ -211,11 +234,12 @@ For example, the following code:
|
|
211
234
|
|
212
235
|
mock.should_receive(:average).and_return(12)
|
213
236
|
|
214
|
-
Means that the mock will now accept method calls to an
|
215
|
-
expectation will accept any arguments
|
216
|
-
(including zero times). Strictly
|
217
|
-
|
218
|
-
|
237
|
+
Means that the mock will now accept method calls to an
|
238
|
+
<code>average</code> method. The expectation will accept any arguments
|
239
|
+
and may be called any number of times (including zero times). Strictly
|
240
|
+
speaking, the <code>and_return</code> part of the declaration isn't
|
241
|
+
exactly a constraint, but it does specify what value the mock will
|
242
|
+
return when the expectation is matched.
|
219
243
|
|
220
244
|
If you want to be more specific, you need to add additional constraints to
|
221
245
|
your expectation. Here are some examples:
|
@@ -233,7 +257,7 @@ object. See theFlexMock::Expectation for more details.
|
|
233
257
|
|
234
258
|
Declares that a message named <em>method_name</em> will be sent to the mock
|
235
259
|
object. Constraints on this expected message (called expectations) may be
|
236
|
-
chained to the
|
260
|
+
chained to the <code>should_receive</code> call.
|
237
261
|
|
238
262
|
* <b>should_receive(<em>method_name1</em>, <em>method_name2</em>, ...)</b>
|
239
263
|
|
@@ -244,20 +268,31 @@ object. See theFlexMock::Expectation for more details.
|
|
244
268
|
Define a number of expected messages that have the same constrants, but
|
245
269
|
return different values.
|
246
270
|
|
247
|
-
* <b>
|
271
|
+
* <b>should_receive(...).explicit</b>
|
272
|
+
|
273
|
+
If a mock has a base class, use the <code>explicit</code> modifier
|
274
|
+
to override the restriction on method names imposed by the base
|
275
|
+
class. The explicit modifier must come immediately after the
|
276
|
+
<code>should_receive</code> call and before any other expectation
|
277
|
+
declarators.
|
278
|
+
|
279
|
+
If a mock does not have a base class, this method has no effect.
|
280
|
+
|
281
|
+
* <b>should_expect { |<em>recorder</em>| ... }</b>
|
248
282
|
|
249
283
|
Creates a mock recording object that will translate received method calls
|
250
284
|
into mock expectations. The recorder is passed to a block supplied with the
|
251
|
-
|
285
|
+
<code>should_expect</code> method. See examples below.
|
252
286
|
|
253
287
|
* <b>with(<em>arglist</em>)</b>
|
254
288
|
|
255
289
|
Declares that this expectation matches messages that match the given
|
256
|
-
argument list. The <tt>===</tt> operator is used on a argument by
|
257
|
-
basis to determine matching. This means that most literal
|
258
|
-
literally, class values match any instance of a class
|
259
|
-
match any matching string (after a
|
260
|
-
validators (below) for
|
290
|
+
argument list. The <tt>===</tt> operator is used on a argument by
|
291
|
+
argument basis to determine matching. This means that most literal
|
292
|
+
values match literally, class values match any instance of a class
|
293
|
+
and regular expression match any matching string (after a
|
294
|
+
<code>to_s</code> conversion). See argument validators (below) for
|
295
|
+
details on argument validation options.
|
261
296
|
|
262
297
|
* <b>with_any_args</b>
|
263
298
|
|
@@ -268,63 +303,6 @@ object. See theFlexMock::Expectation for more details.
|
|
268
303
|
|
269
304
|
Declares that this expectation matches messages with no arguments
|
270
305
|
|
271
|
-
* <b>and_return(<em>value</em>)</b>
|
272
|
-
|
273
|
-
Declares that the expected message will return the given value.
|
274
|
-
|
275
|
-
* <b>and_return(<em>value1</em>, <em>value2</em>, ...)</b>
|
276
|
-
|
277
|
-
Declares that the expected message will return a series of values. Each
|
278
|
-
invocation of the message will return the next value in the series. The last
|
279
|
-
value will be repeatably returned if the number of matching calls exceeds
|
280
|
-
the number of values.
|
281
|
-
|
282
|
-
* <b>and_return { |args, ...| code ... } </b>
|
283
|
-
|
284
|
-
Declares that the expected message will return the yielded value of the
|
285
|
-
block. The block will receive all the arguments in the message. If the
|
286
|
-
message was provided a block, it will be passed as the last parameter of the
|
287
|
-
block's argument list.
|
288
|
-
|
289
|
-
* <b>returns( ... )</b>
|
290
|
-
|
291
|
-
Alias for <tt>and_return</tt>.
|
292
|
-
|
293
|
-
* <b>and_raise(exception, *args)</b>
|
294
|
-
|
295
|
-
Declares that the expected messsage will raise the specified
|
296
|
-
exception. If +exception+ is an exception class, then the raised
|
297
|
-
exception will be constructed from the class with +new+ given the
|
298
|
-
supplied arguments. If +exception+ is an instance of an exception
|
299
|
-
class, then it will be raised directly.
|
300
|
-
|
301
|
-
* <b>raises( ... )</b>
|
302
|
-
|
303
|
-
Alias for <tt>and_raise</tt>.
|
304
|
-
|
305
|
-
* <b>and_throw(symbol)</b>
|
306
|
-
* <b>and_throw(symbol, value)</b>
|
307
|
-
|
308
|
-
Declares that the expected messsage will throw the specified symbol.
|
309
|
-
If an optional value is included, then it will be the value returned
|
310
|
-
from the corresponding catch statement.
|
311
|
-
|
312
|
-
* <b>throws( ... )</b>
|
313
|
-
|
314
|
-
Alias for <tt>and_throw</tt>.
|
315
|
-
|
316
|
-
* <b>and_yield(values, ...)</b>
|
317
|
-
|
318
|
-
Declares that the mocked method will receive a block, and the mock
|
319
|
-
will call that block with the values given. Not providing a block
|
320
|
-
will be an error. Providing more than one +and_yield+ clause one a
|
321
|
-
single expectation will mean that subsquent mock method calls will
|
322
|
-
yield the values provided by the additional +and_yield+ clause.
|
323
|
-
|
324
|
-
* <b>yields( ... )</b>
|
325
|
-
|
326
|
-
Alias for <tt>and_yield( ... )</tt>.
|
327
|
-
|
328
306
|
* <b>zero_or_more_times</b>
|
329
307
|
|
330
308
|
Declares that the expected message is may be sent zero or more times
|
@@ -382,11 +360,12 @@ object. See theFlexMock::Expectation for more details.
|
|
382
360
|
an order group may be received in any order. Ordered messages outside the
|
383
361
|
group must be received either before or after all of the grouped messages.
|
384
362
|
|
385
|
-
For example, in the following, messages
|
386
|
-
any order (because they are in
|
387
|
-
|
388
|
-
|
389
|
-
|
363
|
+
For example, in the following, messages <code>flip</code> and
|
364
|
+
<code>flop</code> may be received in any order (because they are in
|
365
|
+
the same group), but must occur strictly after <code>start</code>
|
366
|
+
but before <code>end</code>. The message <code>any_time</code> may
|
367
|
+
be received at any time because it is not ordered.
|
368
|
+
|
390
369
|
m = flexmock()
|
391
370
|
m.should_receive(:any_time)
|
392
371
|
m.should_receive(:start).ordered
|
@@ -418,37 +397,115 @@ object. See theFlexMock::Expectation for more details.
|
|
418
397
|
for various methods in the setup of a test suite, and then override
|
419
398
|
only the methods that need special handling in any given test.
|
420
399
|
|
400
|
+
=== Expectation Actions
|
401
|
+
|
402
|
+
Action expectations are used to specify what the mock should
|
403
|
+
<em>do</em> when the expectation is matched. The actions themselves do
|
404
|
+
not take part in determining whether a given expectation matches or
|
405
|
+
not.
|
406
|
+
|
407
|
+
* <b>and_return(<em>value</em>)</b>
|
408
|
+
|
409
|
+
Declares that the expected message will return the given value.
|
410
|
+
|
411
|
+
* <b>and_return(<em>value1</em>, <em>value2</em>, ...)</b>
|
412
|
+
|
413
|
+
Declares that the expected message will return a series of values. Each
|
414
|
+
invocation of the message will return the next value in the series. The last
|
415
|
+
value will be repeatably returned if the number of matching calls exceeds
|
416
|
+
the number of values.
|
417
|
+
|
418
|
+
* <b>and_return { |<em>args</em>, ...| <em>code</em> ... } </b>
|
419
|
+
|
420
|
+
Declares that the expected message will return the yielded value of the
|
421
|
+
block. The block will receive all the arguments in the message. If the
|
422
|
+
message was provided a block, it will be passed as the last parameter of the
|
423
|
+
block's argument list.
|
424
|
+
|
425
|
+
* <b>returns( ... )</b>
|
426
|
+
|
427
|
+
Alias for <tt>and_return</tt>.
|
428
|
+
|
429
|
+
* <b>and_raise(<em>exception</em>, <em>*args</em>)</b>
|
430
|
+
|
431
|
+
Declares that the expected messsage will raise the specified
|
432
|
+
exception. If <code>exception</code> is an exception class, then the
|
433
|
+
raised exception will be constructed from the class with
|
434
|
+
<code>new</code> given the supplied arguments. If
|
435
|
+
<code>exception</code> is an instance of an exception class, then it
|
436
|
+
will be raised directly.
|
437
|
+
|
438
|
+
* <b>raises( ... )</b>
|
439
|
+
|
440
|
+
Alias for <tt>and_raise</tt>.
|
441
|
+
|
442
|
+
* <b>and_throw(<em>symbol</em>)</b>
|
443
|
+
* <b>and_throw(<em>symbol</em>, <em>value</em>)</b>
|
444
|
+
|
445
|
+
Declares that the expected messsage will throw the specified symbol.
|
446
|
+
If an optional value is included, then it will be the value returned
|
447
|
+
from the corresponding catch statement.
|
448
|
+
|
449
|
+
* <b>throws( ... )</b>
|
450
|
+
|
451
|
+
Alias for <tt>and_throw</tt>.
|
452
|
+
|
453
|
+
* <b>and_yield(<em>values</em>, ...)</b>
|
454
|
+
|
455
|
+
Declares that the mocked method will receive a block, and the mock
|
456
|
+
will call that block with the values given. Not providing a block
|
457
|
+
will be an error. Providing more than one <code>and_yield</code>
|
458
|
+
clause one a single expectation will mean that subsquent mock method
|
459
|
+
calls will yield the values provided by the additional
|
460
|
+
<code>and_yield</code> clause.
|
461
|
+
|
462
|
+
* <b>yields( ... )</b>
|
463
|
+
|
464
|
+
Alias for <tt>and_yield( ... )</tt>.
|
465
|
+
|
466
|
+
* <b>pass_thru</b>
|
467
|
+
|
468
|
+
Declares that the expected message will allow the method to be
|
469
|
+
passed to the original method definition in the partial mock object.
|
470
|
+
<code>pass_thru</code> is also allowed on regular mocks, but since
|
471
|
+
there is no original method to be called, pass_thru will always
|
472
|
+
return the undefined object.
|
473
|
+
|
474
|
+
=== Other Expectation Methods
|
475
|
+
|
421
476
|
* <b>mock</b>
|
422
477
|
|
423
478
|
Expectation constraints always return the expectation so that the
|
424
|
-
constraints can be chained. If you wish to do a one-liner and assign
|
425
|
-
mock to a variable, the
|
426
|
-
original mock object.
|
427
|
-
|
479
|
+
constraints can be chained. If you wish to do a one-liner and assign
|
480
|
+
the mock to a variable, the <code>mock</code> method on an
|
481
|
+
expectation will return the original mock object.
|
482
|
+
|
428
483
|
m = flexmock.should_receive(:hello).once.and_return("World").mock
|
429
484
|
|
430
485
|
<b>NOTE:</b> <em>Using <b>mock</b> when specifying a Demeter mock
|
431
486
|
chain will return the last mock of the chain, which might not be
|
432
|
-
what you expect
|
487
|
+
what you expect.</em>
|
433
488
|
|
434
489
|
=== Argument Validation
|
435
490
|
|
436
|
-
The values passed to the
|
437
|
-
expectations. The first expectation found that
|
438
|
-
method call will be used to validate
|
491
|
+
The values passed to the <code>with</code> declarator determine the
|
492
|
+
criteria for matching expectations. The first expectation found that
|
493
|
+
matches the arguments in a mock method call will be used to validate
|
494
|
+
that mock method call.
|
439
495
|
|
440
496
|
The following rules are used for argument matching:
|
441
497
|
|
442
|
-
* A
|
443
|
-
that is an instance of that class.
|
498
|
+
* A <code>with</code> parameter that is a class object will match any
|
499
|
+
actual argument that is an instance of that class.
|
444
500
|
|
445
501
|
Examples:
|
446
502
|
|
447
503
|
with(Integer) will match f(3)
|
448
504
|
|
449
|
-
* A regular expression will match any actual argument that matches the
|
450
|
-
expression. Non-string actual arguments are converted to
|
451
|
-
before applying the regular
|
505
|
+
* A regular expression will match any actual argument that matches the
|
506
|
+
regular expression. Non-string actual arguments are converted to
|
507
|
+
strings via <code>to_s</code> before applying the regular
|
508
|
+
expression.
|
452
509
|
|
453
510
|
Examples:
|
454
511
|
|
@@ -474,14 +531,15 @@ The following rules are used for argument matching:
|
|
474
531
|
|
475
532
|
<b>Note:</b> If you do not use the FlexMock::TestCase Test Unit
|
476
533
|
integration module, or the FlexMock::ArgumentTypes module, you will
|
477
|
-
have to fully qualify the
|
478
|
-
special argument matches (
|
534
|
+
have to fully qualify the <code>eq</code> method. This is true of
|
535
|
+
all the special argument matches (<code>eq</code>, <code>on</code>,
|
536
|
+
<code>any</code>, <code>hsh</code> and <code>ducktype</code>).
|
479
537
|
|
480
538
|
with(FlexMock.eq(Integer))
|
481
539
|
with(FlexMock.on { code })
|
482
540
|
with(FlexMock.any)
|
483
541
|
with(FlexMock.hsh(:tag => 3))
|
484
|
-
with(FlexMock.ducktype(:wag
|
542
|
+
with(FlexMock.ducktype(:wag, :bark))
|
485
543
|
|
486
544
|
* If you wish to match a hash on _some_ of its values, the
|
487
545
|
FlexMock.hsh(...) method will work. Only specify the hash values
|
@@ -531,11 +589,11 @@ The following rules are used for argument matching:
|
|
531
589
|
|
532
590
|
=== Creating Partial Mocks
|
533
591
|
|
534
|
-
Sometimes it is useful to mock the behavior of one or two methods in
|
535
|
-
existing object without changing the behavior of the rest of the
|
536
|
-
you pass a real object to the
|
537
|
-
real object in your test and will just
|
538
|
-
you specify.
|
592
|
+
Sometimes it is useful to mock the behavior of one or two methods in
|
593
|
+
an existing object without changing the behavior of the rest of the
|
594
|
+
object. If you pass a real object to the <code>flexmock</code> method,
|
595
|
+
it will allow you to use that real object in your test and will just
|
596
|
+
mock out the one or two methods that you specify.
|
539
597
|
|
540
598
|
For example, suppose that a Dog object uses a Woofer object to bark. The code
|
541
599
|
for Dog looks like this (we will leave the code for Woofer to your
|
@@ -557,15 +615,15 @@ Now we want to test Dog, but using a real Woofer object in the test is a real
|
|
557
615
|
pain (why? ... well because Woofer plays a sound file of a dog barking, and
|
558
616
|
that's really annoying during testing).
|
559
617
|
|
560
|
-
So, how can we create a Dog object with mocked Woofer? All we need to
|
561
|
-
allow FlexMock to replace the
|
618
|
+
So, how can we create a Dog object with mocked Woofer? All we need to
|
619
|
+
do is allow FlexMock to replace the <code>bark</code> method.
|
562
620
|
|
563
621
|
Here's the test code:
|
564
622
|
|
565
623
|
class TestDogBarking < Test::Unit::TestCase
|
566
624
|
include FlexMock::TestCase
|
567
625
|
|
568
|
-
# Setup the tests by mocking the +new+ method of
|
626
|
+
# Setup the tests by mocking the +new+ method of
|
569
627
|
# Woofer and return a mock woofer.
|
570
628
|
def setup
|
571
629
|
@dog = Dog.new
|
@@ -582,24 +640,119 @@ The nice thing about this technique is that after the test is over, the mocked
|
|
582
640
|
out methods are returned to their normal state. Outside the test everything is
|
583
641
|
back to normal.
|
584
642
|
|
585
|
-
<b>NOTE:</b> In previous versions of FlexMock, partial mocking was
|
586
|
-
"stubs" and the
|
587
|
-
Although partial mocks were often used as stubs,
|
588
|
-
correct. The current version of FlexMock
|
589
|
-
|
590
|
-
|
591
|
-
|
592
|
-
|
643
|
+
<b>NOTE:</b> In previous versions of FlexMock, partial mocking was
|
644
|
+
called "stubs" and the <code>flexstub</code> method was used to create
|
645
|
+
the partial mocks. Although partial mocks were often used as stubs,
|
646
|
+
the terminology was not quite correct. The current version of FlexMock
|
647
|
+
uses the <code>flexmock</code> method to create both regular stubs and
|
648
|
+
partial stubs. A version of the <code>flexstub</code> method is
|
649
|
+
included for backwards compatibility. See Martin Fowler's article
|
650
|
+
<em>Mocks Aren't Stubs</em>
|
651
|
+
(http://www.martinfowler.com/articles/mocksArentStubs.html) for a
|
652
|
+
better understanding of the difference between mocks and stubs.
|
593
653
|
|
594
|
-
This partial mocking technique was inspired by the
|
595
|
-
|
654
|
+
This partial mocking technique was inspired by the <code>Stuba</code>
|
655
|
+
library in the <code>Mocha</code> project.
|
596
656
|
|
597
|
-
===
|
657
|
+
=== Spies
|
598
658
|
|
599
|
-
|
600
|
-
|
601
|
-
|
602
|
-
|
659
|
+
FlexMock supports spy-like mocks as well as the traditional mocks.
|
660
|
+
|
661
|
+
class TestDogBarking < Test::Unit::TestCase
|
662
|
+
def test_dog
|
663
|
+
dog = flexmock(:on, Dog)
|
664
|
+
dog.bark("loud")
|
665
|
+
assert_spy_called dog, :bark, "loud"
|
666
|
+
end
|
667
|
+
end
|
668
|
+
|
669
|
+
==== Asserting Spy Methods are Called (Test::Unit / MiniTest)
|
670
|
+
|
671
|
+
FlexMock provied a custom assertion method for use with Test::Unit and
|
672
|
+
MiniTest for asserting that mocked methods are actually called.
|
673
|
+
|
674
|
+
* <b>assert_spy_called <em>mock</em>, <em>options_hash</em>, <em>method_name</em>, <em>args...</em></b>
|
675
|
+
|
676
|
+
This will assert that the method called <em>method_name</em> has
|
677
|
+
been called at least once on the given mock object. If arguments are
|
678
|
+
given, then the method must be called with actual argument that
|
679
|
+
match the given argument matchers.
|
680
|
+
|
681
|
+
All the argument matchers defined in the "Argument Validation"
|
682
|
+
section above are allowed in the <code>assert_spy_called</code>
|
683
|
+
method.
|
684
|
+
|
685
|
+
The options has is optional. If omitted, all options have their
|
686
|
+
default values.
|
687
|
+
|
688
|
+
* <b>assert_spy_not_called <em>mock</em>, <em>options_hash</em>, <em>method_name</em>, <em>args...</em></b>
|
689
|
+
|
690
|
+
Same as <code>assert_spy_called</code>, except with the sense of the
|
691
|
+
test reversed.
|
692
|
+
|
693
|
+
*Examples:*
|
694
|
+
|
695
|
+
dog = flexmock(:on, Dog)
|
696
|
+
|
697
|
+
dog.wag(:tail)
|
698
|
+
dog.wag(:head)
|
699
|
+
|
700
|
+
assert_spy_called dog, :wag, :tail
|
701
|
+
assert_spy_called dog, :wag, :head
|
702
|
+
assert_spy_called dog, {times: 2}, :wag
|
703
|
+
|
704
|
+
assert_spy_not_called dog, :bark
|
705
|
+
assert_spy_not_called dog, {times: 3}, :wag
|
706
|
+
|
707
|
+
==== RSpec Matcher for Spying
|
708
|
+
|
709
|
+
FlexMock also provides an RSpec matcher that can be used to specify
|
710
|
+
spy behavior.
|
711
|
+
|
712
|
+
* <b>mock.should have_received(<em>method_name</em>).with(<em>args...</em>).times(<em>n</em>)</b>
|
713
|
+
|
714
|
+
Specifies that the method named <em>method_name</em> should have
|
715
|
+
been received by the mock object with the given arguments.
|
716
|
+
|
717
|
+
The <code>with</code> and <code>times</code> clauses are optional.
|
718
|
+
|
719
|
+
If a <code>with</code> clause is given, only messages with matching
|
720
|
+
arguments are considered. <em>args</em> can be any of the argument
|
721
|
+
matches mentioned in the "Argument Validation" section above. If
|
722
|
+
<code>with</code> is not given, then the arguments are not
|
723
|
+
considered when finding matching calls.
|
724
|
+
|
725
|
+
If a <code>times</code> clause is given, then there must be exactly
|
726
|
+
<code>n</code> calls for that method name on the mock. If the
|
727
|
+
<code>times</code> clause is not given, then there must be at least
|
728
|
+
one call matching the method name (and arguments if they are
|
729
|
+
considered).
|
730
|
+
|
731
|
+
<code>never</code> is an alias for <code>times(0)</code>,
|
732
|
+
<code>once</code> is an alias for <code>times(1)</code>, and
|
733
|
+
<code>twice</code> is an alias for <code>times(2)</code>.</p>
|
734
|
+
|
735
|
+
*Examples:*
|
736
|
+
|
737
|
+
dog = flexmock(:on, Dog)
|
738
|
+
|
739
|
+
dog.wag(:tail)
|
740
|
+
dog.wag(:head)
|
741
|
+
|
742
|
+
dog.should have_received(:wag).with(:tail)
|
743
|
+
dog.should have_received(:wag).with(:head)
|
744
|
+
dog.should have_received(:wag).twice
|
745
|
+
|
746
|
+
dog.should_not have_received(:bark)
|
747
|
+
dog.should_not have_received(:wag).times(3)
|
748
|
+
|
749
|
+
=== Mocking Class Object
|
750
|
+
|
751
|
+
In the previous example we mocked out the <code>bark</code> method of
|
752
|
+
a Dog object to avoid invoking the Woofer object. Perhaps a better
|
753
|
+
technique would be to mock the Woofer object directly. But Dog uses
|
754
|
+
Woofer explicitly so we cannot just pass in a mock object for Dog to
|
755
|
+
use.
|
603
756
|
|
604
757
|
But wait, we can add mock behavior to any existing object, and classes are
|
605
758
|
objects in Ruby. So why don't we just mock out the Woofer class object to
|
@@ -608,7 +761,7 @@ return mocks for us.
|
|
608
761
|
class TestDogBarking < Test::Unit::TestCase
|
609
762
|
include FlexMock::TestCase
|
610
763
|
|
611
|
-
# Setup the tests by mocking the
|
764
|
+
# Setup the tests by mocking the <code>new</code> method of
|
612
765
|
# Woofer and return a mock woofer.
|
613
766
|
def setup
|
614
767
|
flexmock(Woofer).should_receive(:new).
|
@@ -643,12 +796,13 @@ very easy.
|
|
643
796
|
end
|
644
797
|
end
|
645
798
|
|
646
|
-
Note that FlexMock adds the mock expectations after the original
|
647
|
-
has completed. If the original version of
|
648
|
-
instance to a block, that
|
799
|
+
Note that FlexMock adds the mock expectations after the original
|
800
|
+
<code>new</code> method has completed. If the original version of
|
801
|
+
<code>new</code> yields the newly created instance to a block, that
|
802
|
+
block will get an non-mocked version of the object.
|
649
803
|
|
650
|
-
Note that
|
651
|
-
methods at the same time. E.g.
|
804
|
+
Note that <code>new_instances</code> will accept a block if you wish
|
805
|
+
to mock several methods at the same time. E.g.
|
652
806
|
|
653
807
|
flexmock(Woofer).new_instances do |m|
|
654
808
|
m.should_receive(:woof).twice.and_return(:grrr)
|
@@ -669,7 +823,7 @@ In your test setup you might have:
|
|
669
823
|
@mock_dog = flexmock("Fido")
|
670
824
|
@mock_dog.should_receive(:tail => :a_tail, :bark => "woof").by_default
|
671
825
|
end
|
672
|
-
|
826
|
+
|
673
827
|
The behaviors for :tail and :bark are good for most of the tests, but
|
674
828
|
perhaps you wish to verify that :bark is called exactly once in a
|
675
829
|
given test. Since :bark by default has no count expectations, you can
|
@@ -678,12 +832,12 @@ override the default in the given test.
|
|
678
832
|
def test_something_where_bark_must_be_called_once
|
679
833
|
@mock_dog.should_receive(:bark => "woof").once
|
680
834
|
|
681
|
-
# At this point, the default for :bark is ignored,
|
835
|
+
# At this point, the default for :bark is ignored,
|
682
836
|
# and the "woof" value will be returned.
|
683
837
|
|
684
838
|
# However, the default for :tail (which returns :a_tail)
|
685
839
|
# is still active.
|
686
|
-
end
|
840
|
+
end
|
687
841
|
|
688
842
|
By setting defaults, your individual tests don't have to concern
|
689
843
|
themselves with details of all the default setup. But the details of
|
@@ -752,7 +906,7 @@ beforehand.
|
|
752
906
|
=== Create a simple mock object that returns a value for a set of method calls
|
753
907
|
|
754
908
|
require 'flexmock/test_unit'
|
755
|
-
|
909
|
+
|
756
910
|
class TestSimple < Test::Unit::TestCase
|
757
911
|
def test_simple_mock
|
758
912
|
m = flexmock(:pi => 3.1416, :e => 2.71)
|
@@ -764,7 +918,7 @@ beforehand.
|
|
764
918
|
=== Create a mock object that returns an undefined object for method calls
|
765
919
|
|
766
920
|
require 'flexmock/test_unit'
|
767
|
-
|
921
|
+
|
768
922
|
class TestUndefined < Test::Unit::TestCase
|
769
923
|
def test_undefined_values
|
770
924
|
m = flexmock("mock")
|
@@ -814,8 +968,8 @@ but the third query (which matches any query call with a four
|
|
814
968
|
character parameter) may be called multiple times (but at least once).
|
815
969
|
Startup and finish must also happen exactly once.
|
816
970
|
|
817
|
-
Also note that we use the
|
818
|
-
values to figure out what value to return.
|
971
|
+
Also note that we use the <code>with</code> method to match different
|
972
|
+
argument values to figure out what value to return.
|
819
973
|
|
820
974
|
def test_ordered_queries
|
821
975
|
db = flexmock('db')
|
@@ -833,9 +987,9 @@ values to figure out what value to return.
|
|
833
987
|
=== Same as above, but using the Record Mode interface
|
834
988
|
|
835
989
|
The record mode interface offers much the same features as the
|
836
|
-
|
837
|
-
messages to be sent directly to a recording object rather than be
|
838
|
-
specified indirectly using a symbol.
|
990
|
+
<code>should_receive</code> interface introduced so far, but it allows
|
991
|
+
the messages to be sent directly to a recording object rather than be
|
992
|
+
specified indirectly using a symbol.
|
839
993
|
|
840
994
|
def test_ordered_queries_in_record_mode
|
841
995
|
db = flexmock('db')
|
@@ -888,8 +1042,8 @@ effect.
|
|
888
1042
|
|
889
1043
|
Generally you need to mock only those methods that return an
|
890
1044
|
interesting value or wish to assert were sent in a particular manner.
|
891
|
-
Use the
|
892
|
-
ignoring.
|
1045
|
+
Use the <code>should_ignore_missing</code> method to turn on missing
|
1046
|
+
method ignoring.
|
893
1047
|
|
894
1048
|
def test_an_important_message
|
895
1049
|
m = flexmock('m')
|
@@ -898,9 +1052,9 @@ ignoring.
|
|
898
1052
|
# test code here
|
899
1053
|
end
|
900
1054
|
|
901
|
-
When
|
902
|
-
return an undefined object.
|
903
|
-
will return the undefined object.
|
1055
|
+
When <code>should_ignore_missing</code> is enabled, ignored missing
|
1056
|
+
methods will return an undefined object. Any operation on the
|
1057
|
+
undefined object will return the undefined object.
|
904
1058
|
|
905
1059
|
=== Mock just one method on an existing object
|
906
1060
|
|
@@ -917,15 +1071,9 @@ real web service in our unit tests, we will mock the quote service.
|
|
917
1071
|
assert_equal 100, value
|
918
1072
|
end
|
919
1073
|
|
920
|
-
== Other Mock Objects
|
921
|
-
|
922
|
-
test-unit-mock :: http://www.deveiate.org/code/Test-Unit-Mock.shtml
|
923
|
-
mocha/stubba :: http://mocha.rubyforge.org/
|
924
|
-
Schmock :: http://rubyforge.org/projects/schmock/
|
925
|
-
|
926
1074
|
== License
|
927
1075
|
|
928
|
-
Copyright 2003
|
1076
|
+
Copyright 2003-2012 by Jim Weirich (jim.weirich@gmail.com).
|
929
1077
|
All rights reserved.
|
930
1078
|
|
931
1079
|
Permission is granted for use, copying, modification, distribution,
|
@@ -934,8 +1082,8 @@ above copyright notice is included.
|
|
934
1082
|
|
935
1083
|
= Other stuff
|
936
1084
|
|
937
|
-
Author:: Jim Weirich <jim@
|
938
|
-
Requires:: Ruby 1.
|
1085
|
+
Author:: Jim Weirich <jim.weirich@gmail.com>
|
1086
|
+
Requires:: Ruby 1.9.2 or later (Earlier versions of Flexmock may work with earlier versions of Ruby)
|
939
1087
|
|
940
1088
|
== Warranty
|
941
1089
|
|