Download Unit Testing Tips and Tricks: Database Interaction

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Database model wikipedia , lookup

Object-relational impedance mismatch wikipedia , lookup

Transcript
Unit Testing Tips and Tricks:
Database Interaction
Louis Thomas
Overview
•
•
•
•
•
Preaching about TDD
What is a Unit Test
Common Unit Testing Patterns
Unit Testing Database Interactions
Acceptance Tests With Databases
Are you test infected?
• There are two kinds of people:
– People who don’t like it
• Can’t be done attitude
– People who do like it
• “I think I can” attitude
Test Driven Development Is
Hard
•
Conceptually, it’s simple!
(Sure, just like OO is simple…)
•
•
It’s a learning process. It will be hard at
first.
Be creative!
I’m Guilty…
• I'm guilty. I am a hack. I am an "impurist". I
often don't do "pure" TDD.
• I find TDD easier to do for some tasks
than others. I do whatever I feel like.
However, I like what I get with TDD, so I
lean towards it
• Unit tests are good even if you
don’t do TDD!
There Are Many Kinds Of Tests
• Acceptance tests, user test, integration
tests, unit tests; black box, white box…
• All tests have merit if they can detect
bugs.
• Tests only have value if they are run!
Unit Tests
• From developer's point of view.
• Tests the smallest amount of a system that
is interesting.
Often just one part of one class!
• Highly automated
Unit Test Rule Of Thumb
• If you are having trouble writing a unit test
or (for those of you who aren't test infected)
if it's "impossible" to write a test for your
system,
• You are trying to test to much. Test a
smaller chunk.
But How?
• Sometimes objects have complex
behaviors, extensive state, and tight
relationships. This makes tests difficult:set
up is difficult and time consuming, and
objects cannot be isolated.
• (But wait, that’s not right! Right?)
Loosening The Coupling
• Introduce interfaces between complex
objects.
• Create a mock object to stand in for the
complex object.
• Repeat as needed. (Be creative.)
Creating Interfaces
• If it's our object, just create an interface!
• if it's not our object,
– create a mock that extends the object and
overrides all its methods (works sometimes)
– create an interface anyway and create an
adapter for the foreign object
• Example: WallClock
Example: WallClock
Interface
public interface WallClock {
long getTime();
}
Wrapper for normal system service
public class DefaultWallClock implements WallClock {
public static final WallClock INSTANCE=new DefaultWallClock();
public long getTime() {
return System.currentTimeMillis();
}
}
Mock Objects
• Start out as simple as possible (throw
exceptions on all methods).
• Add recording of incoming method calls
– - ex: RecordingMockObject, Thumbprinters
Example: ReportingMockObject
public class ReportingMockObject {
StringBuffer m_stringBuffer=new StringBuffer();
//---------------------------------------------------------------public String getActivityRecordAndReset() {
String sActivityRecord=m_stringBuffer.toString();
m_stringBuffer=new StringBuffer();
return sActivityRecord;
}
//---------------------------------------------------------------public void recordActivity(String sMessage) {
m_stringBuffer.append(sMessage);
}
}
Example: MockClientSession
public class MockClientSession extends ReportingMockObject
implements ClientSession {
public MockClientSession() {
}
public void flushOutgoingBuffer() {
recordActivity("fOB");
}
public void setInterval(int nUpdateIntervalMilliseconds) {
recordActivity("sI("+nUpdateIntervalMilliseconds+")");
}
public void notifyNewOutgoingData() {
recordActivity("nNOD");
}
public String getClientName() {
recordActivity("gCN");
return "mockClient";
}
//…
}
Example:
MockMultiTableSessionListener
public class MockMultiTableSessionListener extends ReportingMockObject implements
MultiTableSession.Listener {
public interface Thumbprinter {
String getThumbprint(MultiTableSession.Update update);
String getThumbprint(SessionState sessionState);
}
//################################################################
private final Thumbprinter m_thumbprinter;
//…
public MockMultiTableSessionListener(Thumbprinter thumbprinter) {
m_thumbprinter=thumbprinter;
}
//…
public void sessionStateNotification(SessionState sessionState) {
if (true==m_bLogSessionStateNotification) {
recordActivity("sSN("+m_thumbprinter.getThumbprint(sessionState)+")");
}
}
}
Mock Objects, cont’d
• Add facility for sending back canned
responses
– (ex, setNextReply, setFailOnNextRequest)
Example: WallClock
public class MockWallClock implements WallClock {
private long[] m_nextTimes;
private int m_nNextTimeIndex;
public void setNextTime(long nNextTime) {
setNextTimeList(new long[] {nNextTime});
}
public void setNextTimeList(long[] nextTimes) {
Require.neqNull(nextTimes, "nextTimes");
m_nextTimes=nextTimes;
m_nNextTimeIndex=0;
}
public long getTime() {
Assert.neqNull(m_nextTimes, "m_nextTimes");
long nNextTime=m_nextTimes[m_nNextTimeIndex];
m_nNextTimeIndex++;
if (m_nextTimes.length==m_nNextTimeIndex) {
m_nextTimes=null;
}
return nNextTime;
}
}
Mock Objects, cont’d
• Do whatever you need
• Often one mock object will support all tests
for a given object, but can create special
ones for certain tests
• Often, one mock object will support tests
for many objects that interact with it
Mock Object Frameworks
• EasyMock (http://easymock.org)
• jMock (http://www.jmock.org/)
• YMMV!
Object Mother (?)
• Sometimes you will need a complex data
structure set up. Refactor mercilessly.
• Especially if you need canned data that is
ancillary to the test, it is often worth while
to factor creation out into a static method
in a util class so you can use it as
necessary thereafter.
Testing Accessor
• Problem: there are private methods you
would like to test, or private members you
would like to inspect for your test
• You could make them public, but they
really are private
• Alternative: an inner class!
TestingAccessor
Example: TestingAccessor
//################################################################
// testing
private WallClock m_wallClock=DefaultWallClock.instance;
private IStepper m_getConStepper=DefaultStepper.instance;
private IStepper m_maintStepper=DefaultStepper.instance;
public class TestingAccessor {
public void setWallClock(WallClock wallClock) {m_wallClock=wallClock;}
public void setGetConStepper(IStepper stepper) {m_getConStepper=stepper;}
public void setMaintStepper(IStepper stepper) {m_maintStepper=stepper;}
public void setNextOverdueConnectionCheck(long tsNextOverdueConnectionCheck)
{m_tsNextOverdueConnectionCheck=tsNextOverdueConnectionCheck;}
public int getAllConnectionsSize() {return m_allConnections.size();}
public int getUnusedConnectionsSize() {return m_unusedConnections.size();}
public int getTotalConnections() {return m_nTotalConnections;}
public void cacheMaintenaceThread() {DBConnectionPool.this.cacheMaintenaceThread();}
public void doNotifyAll() {synchronized (m_oStateLock) {m_oStateLock.notifyAll();}}
}
public TestingAccessor getTestingAccessor() {
return new TestingAccessor();
}
Testing Database Interactions
• You should be thankful! All the database
classes are interfaces already!
• Create mocks and away you go
• Insert / update / delete – easy
Testing Database Interactions,
Cont’d
• Read – trickier
• Can use hard coded expectations
• Mocks will act as factories: statements return
record sets
–
load your mock statement with the mock record
set to return.
–
load your mock connection with the mock
statement to return.
• Can start out with mocks with hard coded
returns, but will probably refactor into more
general objects.
• Ex: Simulated Database Framework
Acceptance Tests With
Databases
• An acceptance test: Want to test the
"whole" app.
• Good for testing that the database really
likes the SQL we hardcoded in the unit
tests, and really responds the way we
expect
Acceptance Tests With
Databases, Cont’d
• Big question is, how can we automate? I built up
a toolkit as I went.
– BulkLoadData: reads CSV files and loads data into
DB (use Excel to edit)
– ExecuteSqlScript: processes a text file of SQL
commands.
• Used to create tables, etc.
– ExecuteDatabaseSetupScript: allows me to write little
scripts
• Knows about 4 commands, including BulkLoadData and
ExecuteSqlScript
– TestResource framework
Acceptance Tests With
Databases, Cont’d
• Big question is, how can we automate? I built up
a toolkit as I went.
– TestResource framework
• I can define test resources my test needs, setup/teardown
methods, and dependencies.
• Resources will set themselves up from any initial state (ex,
delete all rows in table and reload)
• Now, the acceptance test can just declare all the
resources it needs, and framework will set them
up. Just needs to mark which resources it dirties,
so they can be reset for subsequent tests.
Summary
•
•
•
•
•
Preaching about TDD
What is a Unit Test
Common Unit Testing Patterns
Unit Testing Database Interactions
Acceptance Tests With Databases
• Questions / demos!