Software Development Cross Solution - Index of - Free

etter code through testing
Testing produces better code
We’ve been working on testing, but writing tests first has done more than just
test our system. It’s caused us to organize code better, keeping production
code in one place, and everything else in another. We’ve also written simpler
code—and although not everything in the system works yet, the parts that do
are streamlined, without anything that’s not absolutely required.
And, because of the tight coupling between our system’s business logic and
database code, we implemented a design pattern, the strategy pattern. Not
only does this make testing easier, it decouples our code, and even makes it
easy to work with different types of databases.
So testing first has gotten us a lot of things:
OrderProcessor
- mDBAccessor : DBAccessor
+ setDBAccessor(DBAccessor) : void
+ processOrder(orderInfo : OrderInformation) : Receipt
300 Chapter 8
Well-organized code. Production code is in one place; testing code is
in another. Even implementations of our database access code used for
testing are separate from production code.
Code that always does the same thing. Lots of approaches to
testing result in code that does one thing in testing, but another in
production (ever seen an if (debug) statement?). TDD means
writing production code, all the time.
Loosely coupled code. Tightly coupled systems are brittle and
difficult to maintain, not to mention really, really hard to test. Because
we wanted to test our code, we ended up breaking our design into a
loosely coupled, more flexible system.
Ever heard your computer science professor or lead architect talking about
low coupling and high cohesion? This is what they were talking about. We
have low coupling because of our use of interfaces and the strategy pattern,
and we’ve got high cohesion by having our database and business logic code
concentrated into separate but well defined classes.
Remember the single responsibility
principle?
OrderProcessor has the business logic to
handle an order, and doesn’t worry about
databases. So it’s got high cohesion.
Because of the interface approach
of the strategy pattern, you’ve
reduced the coupling between the
OrderProcessor and your DB code.
TestDBAccessor
Download at WoweBook.Com
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)
Our test uses a testingspecific
implementation
of DBAccessor, but the
order processor runs the
same code, because of
our strategy pattern, in
testing or in production.
DBAccessor
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)
MySqlDBAccessor
These accessors worry about
database access, and only database
access. That’s high cohesion.
+ getGC(gcId : int) :GiftCard
+ saveGC(card : GiftCard) :void
+ saveOrder(orderInfo : OrderInformation)