Home > Archive > Extreme Programming > November 2005 > name this test pattern
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
name this test pattern
|
|
| Pawel Slusarz 2005-11-10, 3:58 am |
| Hi Folks,
Today I was shown the following test pattern which allows to test an object
in isolation from the database:
------------
public class MyObject {
public void methodToTest() {
String data = getData();
//do something with the data
}
protected String getData() {
String result = "default data";
//poll database
return result;
}
}
------------
import junit.framework.TestCase;
public class TestMyObject extends TestCase {
public void testMethodToTest() {
MyObject obj = new MyObjectNoDB();
obj.methodToTest();
//make assertions
}
}
class MyObjectNoDB extends MyObject {
protected String getData() {
return "test data";
}
}
-------------
I was told that it is a Mock Object technique. Mock objects I have seen so
far were never under test, so I'd be hesitant to give the same name to
MyObjectNoDB. The difference is that the mock objects I know of provide
environment for the object under test, and are never being tested
themselves.
Can anyone tell me anything about this pattern? I thought it was really neat
because it was so simple, but then I started to wonder if the longer way of
mocking a database connection wasn't fundamentally better somehow.
--
Regards,
Pawel "Paul" Slusarz
http://romaneseuntdomus.com
| |
| Andrew McDonagh 2005-11-10, 6:57 pm |
| Pawel Slusarz wrote:
> Hi Folks,
>
> Today I was shown the following test pattern which allows to test an object
> in isolation from the database:
>
> ------------
>
> public class MyObject {
> public void methodToTest() {
> String data = getData();
> //do something with the data
> }
> protected String getData() {
> String result = "default data";
> //poll database
> return result;
> }
> }
>
> ------------
>
> import junit.framework.TestCase;
>
> public class TestMyObject extends TestCase {
>
> public void testMethodToTest() {
> MyObject obj = new MyObjectNoDB();
> obj.methodToTest();
> //make assertions
> }
>
> }
>
> class MyObjectNoDB extends MyObject {
> protected String getData() {
> return "test data";
> }
> }
>
> -------------
>
> I was told that it is a Mock Object technique. Mock objects I have seen so
> far were never under test, so I'd be hesitant to give the same name to
> MyObjectNoDB. The difference is that the mock objects I know of provide
> environment for the object under test, and are never being tested
> themselves.
>
> Can anyone tell me anything about this pattern? I thought it was really neat
> because it was so simple, but then I started to wonder if the longer way of
> mocking a database connection wasn't fundamentally better somehow.
>
It doesn't really have a formal name - but its often referred to as
'Extract and over ride'
Because, usually (without tests) we would normally just use a db
connection and execute a query inline:
public class MyObject {
public void methodToTest() {
String data = callableStatement.execute(sqlQuery)
//do something with the data
}
}
But this is hard for testing, we'd either have to use a real database to
store the test data or fake the db connection and results in some way.
So its easier to hide all of that behind a simple protected method that
returns the actual data, rather than some SQL api object.
Take a look at this old thread...
http://www.codecomments.com/archive...5-3-411269.html
Andy
| |
|
| Andrew McDonagh wrote:
> It doesn't really have a formal name - but its often referred to as
> 'Extract and over ride'
>
> Because, usually (without tests) we would normally just use a db
> connection and execute a query inline:
>
> public class MyObject {
> public void methodToTest() {
> String data = callableStatement.execute(sqlQuery)
> //do something with the data
> }
> }
Parenthetically, that habit is "normal", but we all know it's hardly ideal.
http://c2.com/cgi/wiki?PerniciousIngrownSql
> But this is hard for testing, we'd either have to use a real database to
> store the test data or fake the db connection and results in some way.
This is why one Mike Feathers rewards his students for writing tests that
target code that touches no database, data files, or GUI controls. Defining
a "unit" test in terms of such isolated units powerfully decouples things.
--
Phlip
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Andrew McDonagh 2005-11-11, 6:58 pm |
| Phlip wrote:
> Andrew McDonagh wrote:
>
>
>
>
> Parenthetically, that habit is "normal", but we all know it's hardly ideal.
>
> http://c2.com/cgi/wiki?PerniciousIngrownSql
>
>
>
>
> This is why one Mike Feathers rewards his students for writing tests that
> target code that touches no database, data files, or GUI controls. Defining
> a "unit" test in terms of such isolated units powerfully decouples things.
>
100 % agreement for me...
now we just have to convince the rest....my current code base is littered...
| |
|
|
|
|
|