About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.

Send comments to:
keithray@mac.com

For Agile Training, eLearning, or Coaching contact:

Industrial Logic, Inc.

866-540-8336 (toll free)

510-540-8336 (Berkeley, California)

Links

xpminifaq

Résumé

“Adopting XP” Article 2002 (pdf)

“ Refactoring” Article 2006

AYE Conference

Lucien W. Dupont

Elisabeth Hendrickson

Johanna Rothman's Managing Product Development

Brian Marick's Exploration Through Example

Esther Derby's Insights You Can Use

Laurent Bossavit's Incipient(thoughts)

Dale Emery's Conversations with Dale

Martin Fowler's Bliki

Creating Passionate Users

Archives

Subscribe
RSS Exploring Solution Spaces XML

ABC's of Micro-Testing

Here are three basic kinds of micro-tests, a.k.a. "programmer tests" such as used in test-driven design/TDD.

Testing the return value of a side-effect-free function.

A lot of simple examples of TDD do this. Simple return-values, scalars instead of lists, for example, are generally simpler to test.

result = some_function(some_input);
assert_equals(expected_result, result);

Testing the state of an object after creation and/or calling one or more methods on it.

In other words, testing the post-conditions of an object. The fewer methods called, the simpler the test; and, the simpler the state being checked, also the simpler the test.

an_object = new some_object(maybe_some_input);
an_object. some_method(maybe_some_more_input);
assert_equal(expected_object_state, an_object); // or ...
assert_equal(expected_object_state, an_object.get_state());

Testing the collaboration of an object with another.

In other words, checking how it calls methods in another object using some kind of mock object. The fewer the objects and methods involved, the simpler the test.

an_object = new some_object();
collaborator = new some_kind_of_test_double();
an_object. some_method(collaborator);
assert_true(collaborator.expected_method_called_correctly());

The further away that you get from these simple basics, the harder the tests are and the more complex the code's design is. In particular, testing state gets more difficult if the state-changes are not localized to a single object under test -- global variables, modified input-variables, the file-system, networked client-server or peer-to-peer interactions, and databases are some places where non-local state changes can make things difficult.

[/docs] permanent link