Skip to content

Mocks, stubs and fakes

  • strict warning: Non-static method view::load() should not be called statically in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/views.module on line 823.
  • strict warning: Declaration of views_plugin_display::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display.inc on line 1684.
  • strict warning: Declaration of views_plugin_display_page::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display_page.inc on line 457.
  • strict warning: Declaration of views_plugin_display_block::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_display_block.inc on line 184.
  • strict warning: Declaration of views_handler_field_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_field.inc on line 243.
  • strict warning: Declaration of views_handler_sort_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_sort.inc on line 82.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 584.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 584.
  • strict warning: Declaration of views_handler_filter_broken::ui_name() should be compatible with views_handler::ui_name($short = false) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/handlers/views_handler_filter.inc on line 608.
  • strict warning: Declaration of views_plugin_row::options_validate() should be compatible with views_plugin::options_validate(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_row.inc on line 61.
  • strict warning: Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit(&$form, &$form_state) in /home/artemmarchenko/agilesoftwaredevelopment.com/modules/views/plugins/views_plugin_row.inc on line 61.

April 25, 2006 by Artem

I am rather new to the Test-Driven-Development (TDD) and continuous testing in general. Therefore I quite often experience the terminology difficulties: how to call fully functional alternative object, how to call almost empty stub objects, etc. It looks like I am not alone.

Martin Fowler highlights the Gerard Meszaros's proposal:

The generic term he uses is a Test Double (think stunt double). Test Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists:

  • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
  • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryDatabase is a good example).
  • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
  • Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting.

Nice dictionary. I am going to try using it for some time. How do you like these term definitions? Worth trying? Worth advertising to colleagues?

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

Best of AgileSoftwareDevelopment.com