Continuous Testing - Continuous Integration - page 133

Some unit tests require minimal outside dependencies, which are
only other classes. Those dependent classes are themselves simple and
don't have deep object graphs. Occasionally, unit tests even employ
mocks, which are simple objects that substitute for real, more compli-
cated objects. If a dependent object itself does depend on an outside
entity like a file system or database and isn't mocked, the test becomes
a component test (defined next).
Listing 6-2 shows an example of a unit test written in Ruby that
verifies the behavior of a filtering type. This test would still be consid-
ered a unit test even though it uses two classes, RegexFilter and
SimpleFilter , because it only uses one type to verify behavior.

LISTING 6-2 Isolated Unit Test Using Ruby

require "test/unit"
require "filters"

class FiltersTest < Test::Unit::TestCase

def test_regex
fltr = RegexFilter.new(/Google|Amazon/)
assert(fltr.apply_filter("Google"))
end

def test_simple
fltr = SimpleFilter.new("oo")
assert(fltr.apply_filter("google"))
end

def test_filters
fltrs = [SimpleFilter.new("oo"), RegexFilter.new(/Go+gle/)]
fltrs.each{ | fltr |
assert(fltr.apply_filter("I love to Gooogle on the Internet"))
}
end
end

The key aspect for unit tests is having no reliance on outside
dependencies such as databases, which have the tendency to increase
the amount of time it takes to set up and run tests. Unit tests can be cre-
ated and run early in the development cycle (i.e., day one). Because of
the rapid time between coding and testing the results, unit tests are an
efficient way of debugging.