Begin book addresses mock object testing only (alternatives?)

[David Brown-48]

Hello Begin, Goodin and Meadors, having read (and reread) the Begin book, and in particular, the ch. 13 Unit testing only seems to cover the use of Mock objects. I don't dispute the need and usefulness of Mock objects but I would like to JUnit test my iBatis/MySql development using a live database. I know this is discussed briefly in the book but I don't see any real-world examples that apply to what I am trying to test. Please reply with links or directives to examples of DAO layer JUnit testing of iBatis against a live database. The most valuable example would test against two tables with references and contraints e.g. primary key auto-generation and a FK reference to the generated key. My current efforts only return test errors (not failures). Regards, David.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[Jeff Butler-2]

You could look at the Ibatis or Ibator builds - they both unit test with JUnit against a "live" database (hsqldb).

The Ibator build uses generated DAO layer, JUnit, hsqldb - seems like just what you are asking for.

Jeff Butler

On Wed, Jul 8, 2009 at 12:52 PM, David Brown <dbrown@...> wrote:

Hello Begin, Goodin and Meadors, having read (and reread) the Begin book, and in particular, the ch. 13 Unit testing only seems to cover the use of Mock objects. I don't dispute the need and usefulness of Mock objects but I would like to JUnit test my iBatis/MySql development using a live database. I know this is discussed briefly in the book but I don't see any real-world examples that apply to what I am trying to test. Please reply with links or directives to examples of DAO layer JUnit testing of iBatis against a live database. The most valuable example would test against two tables with references and contraints e.g. primary key auto-generation and a FK reference to the generated key. My current efforts only return test errors (not failures). Regards, David.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[Clinton Begin]

JPetStore also has unit tests that hit the database directly.

Clinton

On Wed, Jul 8, 2009 at 12:03 PM, Jeff Butler <jeffgbutler@...> wrote:

You could look at the Ibatis or Ibator builds - they both unit test with JUnit against a "live" database (hsqldb).

The Ibator build uses generated DAO layer, JUnit, hsqldb - seems like just what you are asking for.

Jeff Butler

On Wed, Jul 8, 2009 at 12:52 PM, David Brown <dbrown@...> wrote:

Hello Begin, Goodin and Meadors, having read (and reread) the Begin book, and in particular, the ch. 13 Unit testing only seems to cover the use of Mock objects. I don't dispute the need and usefulness of Mock objects but I would like to JUnit test my iBatis/MySql development using a live database. I know this is discussed briefly in the book but I don't see any real-world examples that apply to what I am trying to test. Please reply with links or directives to examples of DAO layer JUnit testing of iBatis against a live database. The most valuable example would test against two tables with references and contraints e.g. primary key auto-generation and a FK reference to the generated key. My current efforts only return test errors (not failures). Regards, David.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[David Brown-48]

Hello Jeff, thanks for the reply. I'm not sure what you mean by the IBatis builds (build IBatis from source?). In any case I accepted the Clinton Begin advice (challange) and I built the JPetstore. I'm not confident in the use of in-memory DBs even if it is hsql. And, my requirements are for: MySQL. This being said I re-configured the JPetstore app to use MySql. I ran all 3 .sql files to setup the MySql instance with a JPetstore database. I deployed the jpetstore.war to TC but invoking the url: http://localhost:8080/jpetstore only evokes the server 500 error (See included stacktrace). I did not have this issue with the hsql version of JPetstore. If the IBator build means something deployable or buildable on the command-line please advise, David.


org.apache.jasper.JasperException: An exception occurred processing JSP page /common/../common/IncludeTop.jsp at line 62

javax.servlet.ServletException: javax.servlet.jsp.JspException: Exception creating bean of class com.ibatis.jpetstore.presentation.CatalogBean: {1}




----- Original Message -----
From: "Jeff Butler" <jeffgbutler@...>
To: user-java@...
Sent: Wednesday, July 8, 2009 1:03:00 PM GMT -06:00 US/Canada Central
Subject: Re: Begin book addresses mock object testing only (alternatives?)

You could look at the Ibatis or Ibator builds - they both unit test with
JUnit against a "live" database (hsqldb).
The Ibator build uses generated DAO layer, JUnit, hsqldb - seems like just
what you are asking for.

Jeff Butler


On Wed, Jul 8, 2009 at 12:52 PM, David Brown
<dbrown@...>wrote:

> Hello Begin, Goodin and Meadors, having read (and reread) the Begin book,
> and in particular, the ch. 13 Unit testing only seems to cover the use of
> Mock objects. I don't dispute the need and usefulness of Mock objects but I
> would like to JUnit test my iBatis/MySql development using a live database.
> I know this is discussed briefly in the book but I don't see any real-world
> examples that apply to what I am trying to test. Please reply with links or
> directives to examples of DAO layer JUnit testing of iBatis against a live
> database. The most valuable example would test against two tables with
> references and contraints e.g. primary key auto-generation and a FK
> reference to the generated key. My current efforts only return test errors
> (not failures). Regards, David.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@...
> For additional commands, e-mail: user-java-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[Jeff Butler-2]

Yes - I mean building from source.  The Ibator build includes hundreds of tests that utilize DAO, JUnit, Spring (in some cases), and hsqldb.  If you are looking for code examples, then either of the builds offers a wealth of examples.  Both run from the command line.

Jeff Butler

On Wed, Jul 8, 2009 at 4:28 PM, David Brown <dbrown@...> wrote:

Hello Jeff, thanks for the reply. I'm not sure what you mean by the IBatis builds (build IBatis from source?). In any case I accepted the Clinton Begin advice (challange) and I built the JPetstore. I'm not confident in the use of in-memory DBs even if it is hsql. And, my requirements are for: MySQL. This being said I re-configured the JPetstore app to use MySql. I ran all 3 .sql files to setup the MySql instance with a JPetstore database. I deployed the jpetstore.war to TC but invoking the url: http://localhost:8080/jpetstore only evokes the server 500 error (See included stacktrace). I did not have this issue with the hsql version of JPetstore. If the IBator build means something deployable or buildable on the command-line please advise, David.


org.apache.jasper.JasperException: An exception occurred processing JSP page /common/../common/IncludeTop.jsp at line 62

javax.servlet.ServletException: javax.servlet.jsp.JspException: Exception creating bean of class com.ibatis.jpetstore.presentation.CatalogBean: {1}

----- Original Message -----
From: "Jeff Butler" <jeffgbutler@...>
To: user-java@...
Sent: Wednesday, July 8, 2009 1:03:00 PM GMT -06:00 US/Canada Central
Subject: Re: Begin book addresses mock object testing only (alternatives?)

You could look at the Ibatis or Ibator builds - they both unit test with
JUnit against a "live" database (hsqldb).
The Ibator build uses generated DAO layer, JUnit, hsqldb - seems like just
what you are asking for.

Jeff Butler


On Wed, Jul 8, 2009 at 12:52 PM, David Brown
<dbrown@...>wrote:

> Hello Begin, Goodin and Meadors, having read (and reread) the Begin book,
> and in particular, the ch. 13 Unit testing only seems to cover the use of
> Mock objects. I don't dispute the need and usefulness of Mock objects but I
> would like to JUnit test my iBatis/MySql development using a live database.
> I know this is discussed briefly in the book but I don't see any real-world
> examples that apply to what I am trying to test. Please reply with links or
> directives to examples of DAO layer JUnit testing of iBatis against a live
> database. The most valuable example would test against two tables with
> references and contraints e.g. primary key auto-generation and a FK
> reference to the generated key. My current efforts only return test errors
> (not failures). Regards, David.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@...
> For additional commands, e-mail: user-java-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[David Brown-48]

Hello Kevin, thanks for the reply (helpful and informative). I am using Spring for the JUnit testing but all via imports. And, I am using annotations: @Rollback, @Test and @Transactional. I have annotated: @Rollback(value=true) as this has been the problem: rollbacks. My problem is the record is inserted into the parent table that generates a key needed by a the child table record insert. Though Rollbacks are disabled the transaction gets committed and the newly generated key disappears leading to an exception.

I will create an all-new test class and use your abstract.

Thanks and regards, David.



----- Original Message -----
From: "Burke.Kevin" <Kevin.Burke@...>
To: user-java@...
Sent: Wednesday, July 8, 2009 12:57:26 PM GMT -06:00 US/Canada Central
Subject: RE: Begin book addresses mock object testing only (alternatives?)

David,

If you are using Spring to wire up your iBatis configuration, there is
an abstract Spring class for performing DAO tests that encapsulates
transaction management around each test. You can perform the necessary
iBatis calls, and Spring will rollback all of the test changes.

If you require more details on this class, see the Spring API Javadocs
(http://static.springsource.org/spring/docs/2.5.x/api/index.html)

Here is an example base class I use for all of my DAO tests. Simply
subclass this for each test class, ensuring that if you override the
onSetUp() or onTearDown() methods (instead of the jUnit setUp() or
tearDown() superclass methods), you also invoke the super.onSetUp() or
super.onTearDown() methods from within.  I use a separate
applicationContext file for these testsm as noted below.

Hope this helps,

-Kevin



------- Code Sample --------

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import
org.springframework.test.AbstractTransactionalDataSourceSpringContextTes
ts;

/**
 * Abstract base class for DAO tests that require rollback functionality
when testing
 * CRUD operations.
 * @author Kevin.Burke
 *
 */
public abstract class AbstractBaseDaoTestCase
                extends
AbstractTransactionalDataSourceSpringContextTests
{
        protected Log log = LogFactory.getLog( this.getClass() );
       

        public AbstractBaseDaoTestCase()
        {
                super();
        }
       
    protected String[] getConfigLocations()
    {
        String[] paths = new String[] {
        "classpath:applicationContext-db-test.xml"
          };
        return paths;
    }
   
    public Object getBean( String beanName )
    {
    return getApplicationContext().getBean( beanName );
    }

}


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[Burke.Kevin]

No problem.

The beauty of the Spring transactional manager is you don't have to
manage it.  It maintains a transaction for the entire test, so any
parent records created inside the test method via inserts are all part
of the same transaction as the child records. Hence, you should not
receive any foreign key errors.  Spring will automatically roll it all
back, without the need to denote transactional boundaries using
annotations.

This leaves you free to test your ibatis code without other moving parts
getting in the way.  

Glad to offer something back to the iBatis community for the help I
received from others!

-Kevin

-----Original Message-----
From: David Brown [mailto:dbrown@...]
Sent: July 8, 2009 5:42 PM
To: user-java@...
Subject: Re: Begin book addresses mock object testing only
(alternatives?)


Hello Kevin, thanks for the reply (helpful and informative). I am using
Spring for the JUnit testing but all via imports. And, I am using
annotations: @Rollback, @Test and @Transactional. I have annotated:
@Rollback(value=true) as this has been the problem: rollbacks. My
problem is the record is inserted into the parent table that generates a
key needed by a the child table record insert. Though Rollbacks are
disabled the transaction gets committed and the newly generated key
disappears leading to an exception.

I will create an all-new test class and use your abstract.

Thanks and regards, David.



----- Original Message -----
From: "Burke.Kevin" <Kevin.Burke@...>
To: user-java@...
Sent: Wednesday, July 8, 2009 12:57:26 PM GMT -06:00 US/Canada Central
Subject: RE: Begin book addresses mock object testing only
(alternatives?)

David,

If you are using Spring to wire up your iBatis configuration, there is
an abstract Spring class for performing DAO tests that encapsulates
transaction management around each test. You can perform the necessary
iBatis calls, and Spring will rollback all of the test changes.

If you require more details on this class, see the Spring API Javadocs
(http://static.springsource.org/spring/docs/2.5.x/api/index.html)

Here is an example base class I use for all of my DAO tests. Simply
subclass this for each test class, ensuring that if you override the
onSetUp() or onTearDown() methods (instead of the jUnit setUp() or
tearDown() superclass methods), you also invoke the super.onSetUp() or
super.onTearDown() methods from within.  I use a separate
applicationContext file for these testsm as noted below.

Hope this helps,

-Kevin



------- Code Sample --------

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import
org.springframework.test.AbstractTransactionalDataSourceSpringContextTes
ts;

/**
 * Abstract base class for DAO tests that require rollback functionality
when testing
 * CRUD operations.
 * @author Kevin.Burke
 *
 */
public abstract class AbstractBaseDaoTestCase
                extends
AbstractTransactionalDataSourceSpringContextTests
{
        protected Log log = LogFactory.getLog( this.getClass() );
       

        public AbstractBaseDaoTestCase()
        {
                super();
        }
       
    protected String[] getConfigLocations()
    {
        String[] paths = new String[] {
        "classpath:applicationContext-db-test.xml"
          };
        return paths;
    }
   
    public Object getBean( String beanName )
    {
    return getApplicationContext().getBean( beanName );
    }

}


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...