Re: [Hibernate] RE: testing question
On Aug 8, 2005, at 8:48 PM, Steve Ebersole wrote: If anyone wants different name(s), speak now or forever hold your peace... I think it should have a name="" attribute so we keep a consistent "catalog" in the Configuration. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] RE: testing question
So I have this implemented locally. It actually uses the org.hibernate.mapping.RelationModel interface. It allows definition through the mapping file or programmatically via the Configuration. There are two basic usages: #1: #2: If anyone wants different name(s), speak now or forever hold your peace... Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, August 08, 2005 8:01 AM To: Hibernate devel Subject: RE: [Hibernate] RE: testing question Actually, probably even better: public interface DatabaseObject { public String sqlCreateString(); public String sqlDropString(); } ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, August 08, 2005 7:54 AM To: Hibernate devel Subject: RE: [Hibernate] RE: testing question Yes, but I was more thinking: public interface DatabaseObject { public String getCreateCommand(); public String getDropCommand(); } because the CREATE/DROP SQL commands explicit operate on a single database object... -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 7:49 AM To: Steve Ebersole; Hibernate devel Subject: Re: [Hibernate] RE: testing question And here MyTransactSQLTrigger would be a userprovided class that has String[] createSQL/dropSQL methods ? Sounds good. I was more thinking like: CREATE ... CREATE ... DROP .. but I guess both are usable. /max > If we just let them register something like the DatabaseObject mentioned > (keyed by dialect) I guess I'm fine with that. Maybe something like: > > > > > > > > > > > > > > Due to "export" feature, I guess DatabaseObject would really instead > need to expose the create/drop strings. > > -Original Message- > From: Max Andersen > Sent: Monday, August 08, 2005 6:36 AM > To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel > Subject: Re: testing question > > >> >> This is the same reason why I always get failures on the tests > relating >> to stored procedure support. >> > > These tests creates the SP's before testing - thus if you get errors > while > running > junit test then that is something that should be failing. > > How about simply extending hibernate with the possibility for user > provided additional DDL's ? > (been suggested before by users, but not had any compelling usecase for > > it...maybe our own > testing is ?) > > /max > >> I think we should come up with a unified way to approach this. So > I'll >> throw out my proposal as a starting point and see if anyone has better >> solutions. >> >> The basic idea is to have the individual tests in this category > register >> "additional db objects" with the base test case class; these would be >> used during setUp() and tearDown() processing. DatabaseObject might >> look like: >> >> interface DatabaseObject { >> void doCreate(Connection conn); >> void doDrop(Connection conn); >> } >> >> I am thinking of a new test base class that tests relying on non-table >> db-object creation could extend; or even add this functionality to the >> existing TestCase. It would add a single new method "DatabaseObject[] >> getAdditionalDatabaseObjects(Dialect dialect)" which it would call >> during setUp() processing. The reason for this instead of just >> overriding setUp()/tearDown() would be to only execute this stuff when >> we actually rebuild the session fatory. >> >> The simple option would be to have each test class do this work >> themselves in setUp() and tearDown() for each test execution even > though >> we are not necessarily creating/dropping the schema at that frequency. >> >> Anyway, thoughts? >> >> Steve >> > > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibe
[Hibernate] Why is cglib three JARs?
I didn't really understand that change. Why do we have several JARs now for CGLIB and why can't we have a single one? --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] RE: testing question
The problem is: statement.execute("CREATE OR REPLACE FUNCTION allEmployments \n" + "RETURN SYS_REFCURSOR \n" + "AS \n" + "st_cursor SYS_REFCURSOR; \n" + "BEGIN \n" + "OPEN st_cursor FOR \n" + " SELECT EMPLOYEE, EMPLOYER, \n" + " STARTDATE, ENDDATE, \n" + " REGIONCODE, EID, VALUE, CURRENCY \n" + " FROM EMPLOYMENT; \n" + " RETURN st_cursor; \n " + "END;\n"); in testEntityStoredProcedure() You reference a column EMPLOYMENT.EID that does not exist. Oracle does not throw exceptions on failed stored-procedure/function creation. It simply returns warnings. I modified this test to fix this bit... -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 6:36 AM To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel Subject: Re: testing question > > This is the same reason why I always get failures on the tests relating > to stored procedure support. > These tests creates the SP's before testing - thus if you get errors while running junit test then that is something that should be failing. How about simply extending hibernate with the possibility for user provided additional DDL's ? (been suggested before by users, but not had any compelling usecase for it...maybe our own testing is ?) /max > I think we should come up with a unified way to approach this. So I'll > throw out my proposal as a starting point and see if anyone has better > solutions. > > The basic idea is to have the individual tests in this category register > "additional db objects" with the base test case class; these would be > used during setUp() and tearDown() processing. DatabaseObject might > look like: > > interface DatabaseObject { > void doCreate(Connection conn); > void doDrop(Connection conn); > } > > I am thinking of a new test base class that tests relying on non-table > db-object creation could extend; or even add this functionality to the > existing TestCase. It would add a single new method "DatabaseObject[] > getAdditionalDatabaseObjects(Dialect dialect)" which it would call > during setUp() processing. The reason for this instead of just > overriding setUp()/tearDown() would be to only execute this stuff when > we actually rebuild the session fatory. > > The simple option would be to have each test class do this work > themselves in setUp() and tearDown() for each test execution even though > we are not necessarily creating/dropping the schema at that frequency. > > Anyway, thoughts? > > Steve > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] RE: testing question
Actually, probably even better: public interface DatabaseObject { public String sqlCreateString(); public String sqlDropString(); } ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ebersole Sent: Monday, August 08, 2005 7:54 AM To: Hibernate devel Subject: RE: [Hibernate] RE: testing question Yes, but I was more thinking: public interface DatabaseObject { public String getCreateCommand(); public String getDropCommand(); } because the CREATE/DROP SQL commands explicit operate on a single database object... -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 7:49 AM To: Steve Ebersole; Hibernate devel Subject: Re: [Hibernate] RE: testing question And here MyTransactSQLTrigger would be a userprovided class that has String[] createSQL/dropSQL methods ? Sounds good. I was more thinking like: CREATE ... CREATE ... DROP .. but I guess both are usable. /max > If we just let them register something like the DatabaseObject mentioned > (keyed by dialect) I guess I'm fine with that. Maybe something like: > > > > > > > > > > > > > > Due to "export" feature, I guess DatabaseObject would really instead > need to expose the create/drop strings. > > -Original Message- > From: Max Andersen > Sent: Monday, August 08, 2005 6:36 AM > To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel > Subject: Re: testing question > > >> >> This is the same reason why I always get failures on the tests > relating >> to stored procedure support. >> > > These tests creates the SP's before testing - thus if you get errors > while > running > junit test then that is something that should be failing. > > How about simply extending hibernate with the possibility for user > provided additional DDL's ? > (been suggested before by users, but not had any compelling usecase for > > it...maybe our own > testing is ?) > > /max > >> I think we should come up with a unified way to approach this. So > I'll >> throw out my proposal as a starting point and see if anyone has better >> solutions. >> >> The basic idea is to have the individual tests in this category > register >> "additional db objects" with the base test case class; these would be >> used during setUp() and tearDown() processing. DatabaseObject might >> look like: >> >> interface DatabaseObject { >> void doCreate(Connection conn); >> void doDrop(Connection conn); >> } >> >> I am thinking of a new test base class that tests relying on non-table >> db-object creation could extend; or even add this functionality to the >> existing TestCase. It would add a single new method "DatabaseObject[] >> getAdditionalDatabaseObjects(Dialect dialect)" which it would call >> during setUp() processing. The reason for this instead of just >> overriding setUp()/tearDown() would be to only execute this stuff when >> we actually rebuild the session fatory. >> >> The simple option would be to have each test class do this work >> themselves in setUp() and tearDown() for each test execution even > though >> we are not necessarily creating/dropping the schema at that frequency. >> >> Anyway, thoughts? >> >> Steve >> > > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] RE: testing question
Yes, but I was more thinking: public interface DatabaseObject { public String getCreateCommand(); public String getDropCommand(); } because the CREATE/DROP SQL commands explicit operate on a single database object... -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 7:49 AM To: Steve Ebersole; Hibernate devel Subject: Re: [Hibernate] RE: testing question And here MyTransactSQLTrigger would be a userprovided class that has String[] createSQL/dropSQL methods ? Sounds good. I was more thinking like: CREATE ... CREATE ... DROP .. but I guess both are usable. /max > If we just let them register something like the DatabaseObject mentioned > (keyed by dialect) I guess I'm fine with that. Maybe something like: > > > > > > > > > > > > > > Due to "export" feature, I guess DatabaseObject would really instead > need to expose the create/drop strings. > > -Original Message- > From: Max Andersen > Sent: Monday, August 08, 2005 6:36 AM > To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel > Subject: Re: testing question > > >> >> This is the same reason why I always get failures on the tests > relating >> to stored procedure support. >> > > These tests creates the SP's before testing - thus if you get errors > while > running > junit test then that is something that should be failing. > > How about simply extending hibernate with the possibility for user > provided additional DDL's ? > (been suggested before by users, but not had any compelling usecase for > > it...maybe our own > testing is ?) > > /max > >> I think we should come up with a unified way to approach this. So > I'll >> throw out my proposal as a starting point and see if anyone has better >> solutions. >> >> The basic idea is to have the individual tests in this category > register >> "additional db objects" with the base test case class; these would be >> used during setUp() and tearDown() processing. DatabaseObject might >> look like: >> >> interface DatabaseObject { >> void doCreate(Connection conn); >> void doDrop(Connection conn); >> } >> >> I am thinking of a new test base class that tests relying on non-table >> db-object creation could extend; or even add this functionality to the >> existing TestCase. It would add a single new method "DatabaseObject[] >> getAdditionalDatabaseObjects(Dialect dialect)" which it would call >> during setUp() processing. The reason for this instead of just >> overriding setUp()/tearDown() would be to only execute this stuff when >> we actually rebuild the session fatory. >> >> The simple option would be to have each test class do this work >> themselves in setUp() and tearDown() for each test execution even > though >> we are not necessarily creating/dropping the schema at that frequency. >> >> Anyway, thoughts? >> >> Steve >> > > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] RE: testing question
And here MyTransactSQLTrigger would be a userprovided class that has String[] createSQL/dropSQL methods ? Sounds good. I was more thinking like: CREATE ... CREATE ... DROP .. but I guess both are usable. /max If we just let them register something like the DatabaseObject mentioned (keyed by dialect) I guess I'm fine with that. Maybe something like: Due to "export" feature, I guess DatabaseObject would really instead need to expose the create/drop strings. -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 6:36 AM To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel Subject: Re: testing question This is the same reason why I always get failures on the tests relating to stored procedure support. These tests creates the SP's before testing - thus if you get errors while running junit test then that is something that should be failing. How about simply extending hibernate with the possibility for user provided additional DDL's ? (been suggested before by users, but not had any compelling usecase for it...maybe our own testing is ?) /max I think we should come up with a unified way to approach this. So I'll throw out my proposal as a starting point and see if anyone has better solutions. The basic idea is to have the individual tests in this category register "additional db objects" with the base test case class; these would be used during setUp() and tearDown() processing. DatabaseObject might look like: interface DatabaseObject { void doCreate(Connection conn); void doDrop(Connection conn); } I am thinking of a new test base class that tests relying on non-table db-object creation could extend; or even add this functionality to the existing TestCase. It would add a single new method "DatabaseObject[] getAdditionalDatabaseObjects(Dialect dialect)" which it would call during setUp() processing. The reason for this instead of just overriding setUp()/tearDown() would be to only execute this stuff when we actually rebuild the session fatory. The simple option would be to have each test class do this work themselves in setUp() and tearDown() for each test execution even though we are not necessarily creating/dropping the schema at that frequency. Anyway, thoughts? Steve --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] RE: testing question
If we just let them register something like the DatabaseObject mentioned (keyed by dialect) I guess I'm fine with that. Maybe something like: Due to "export" feature, I guess DatabaseObject would really instead need to expose the create/drop strings. -Original Message- From: Max Andersen Sent: Monday, August 08, 2005 6:36 AM To: Steve Ebersole; [EMAIL PROTECTED]; Hibernate devel Subject: Re: testing question > > This is the same reason why I always get failures on the tests relating > to stored procedure support. > These tests creates the SP's before testing - thus if you get errors while running junit test then that is something that should be failing. How about simply extending hibernate with the possibility for user provided additional DDL's ? (been suggested before by users, but not had any compelling usecase for it...maybe our own testing is ?) /max > I think we should come up with a unified way to approach this. So I'll > throw out my proposal as a starting point and see if anyone has better > solutions. > > The basic idea is to have the individual tests in this category register > "additional db objects" with the base test case class; these would be > used during setUp() and tearDown() processing. DatabaseObject might > look like: > > interface DatabaseObject { > void doCreate(Connection conn); > void doDrop(Connection conn); > } > > I am thinking of a new test base class that tests relying on non-table > db-object creation could extend; or even add this functionality to the > existing TestCase. It would add a single new method "DatabaseObject[] > getAdditionalDatabaseObjects(Dialect dialect)" which it would call > during setUp() processing. The reason for this instead of just > overriding setUp()/tearDown() would be to only execute this stuff when > we actually rebuild the session fatory. > > The simple option would be to have each test class do this work > themselves in setUp() and tearDown() for each test execution even though > we are not necessarily creating/dropping the schema at that frequency. > > Anyway, thoughts? > > Steve > --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] Re: testing question
exactly -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl Andersen Sent: Monday, August 08, 2005 6:40 AM To: Hibernate devel Subject: Re: [Hibernate] Re: testing question The trick below doesn't work well when you run the unittest standalone (which I do constantly from inside eclipse) /max >> The reason for this instead of just >> overriding setUp()/tearDown() would be to only execute this stuff when >> we actually rebuild the session fatory. > > I worked on the CaveatEmptor tests and I do this using the TestSetup > decorator: > > public static Test suite() { > > TestSuite suite = new TestSuite(); > > suite.addTestSuite( UserTest.class ); > suite.addTestSuite( ItemTest.class ); > suite.addTestSuite( CategoryItemTest.class ); > suite.addTestSuite( AuditTest.class ); > suite.addTestSuite( NestedSetTest.class ); > > return new HibernateTestSetup(suite); > } > > > public class HibernateTestSetup extends junit.extensions.TestSetup { > > public HibernateTestSetup(Test test) { > super(test); > // Enable automatic schema generation for unit testing, if not > already set in configuration > HibernateUtil.getConfiguration().setProperty > (Environment.HBM2DDL_AUTO, "create-drop"); > } > > protected void setUp() throws Exception { > super.setUp(); > HibernateUtil.rebuildSessionFactory(); > } > > protected void tearDown() throws Exception { > super.tearDown(); > HibernateUtil.getSessionFactory().close(); > } > > } > > This setup/teardown is executed once for the suite I'm wrapping. > > > > --- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & > QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > ___ > hibernate-devel mailing list > hibernate-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Re: testing question
The trick below doesn't work well when you run the unittest standalone (which I do constantly from inside eclipse) /max The reason for this instead of just overriding setUp()/tearDown() would be to only execute this stuff when we actually rebuild the session fatory. I worked on the CaveatEmptor tests and I do this using the TestSetup decorator: public static Test suite() { TestSuite suite = new TestSuite(); suite.addTestSuite( UserTest.class ); suite.addTestSuite( ItemTest.class ); suite.addTestSuite( CategoryItemTest.class ); suite.addTestSuite( AuditTest.class ); suite.addTestSuite( NestedSetTest.class ); return new HibernateTestSetup(suite); } public class HibernateTestSetup extends junit.extensions.TestSetup { public HibernateTestSetup(Test test) { super(test); // Enable automatic schema generation for unit testing, if not already set in configuration HibernateUtil.getConfiguration().setProperty (Environment.HBM2DDL_AUTO, "create-drop"); } protected void setUp() throws Exception { super.setUp(); HibernateUtil.rebuildSessionFactory(); } protected void tearDown() throws Exception { super.tearDown(); HibernateUtil.getSessionFactory().close(); } } This setup/teardown is executed once for the suite I'm wrapping. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Re: testing question
This is the same reason why I always get failures on the tests relating to stored procedure support. These tests creates the SP's before testing - thus if you get errors while running junit test then that is something that should be failing. How about simply extending hibernate with the possibility for user provided additional DDL's ? (been suggested before by users, but not had any compelling usecase for it...maybe our own testing is ?) /max I think we should come up with a unified way to approach this. So I'll throw out my proposal as a starting point and see if anyone has better solutions. The basic idea is to have the individual tests in this category register "additional db objects" with the base test case class; these would be used during setUp() and tearDown() processing. DatabaseObject might look like: interface DatabaseObject { void doCreate(Connection conn); void doDrop(Connection conn); } I am thinking of a new test base class that tests relying on non-table db-object creation could extend; or even add this functionality to the existing TestCase. It would add a single new method "DatabaseObject[] getAdditionalDatabaseObjects(Dialect dialect)" which it would call during setUp() processing. The reason for this instead of just overriding setUp()/tearDown() would be to only execute this stuff when we actually rebuild the session fatory. The simple option would be to have each test class do this work themselves in setUp() and tearDown() for each test execution even though we are not necessarily creating/dropping the schema at that frequency. Anyway, thoughts? Steve --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Re: testing question
On Aug 8, 2005, at 1:08 PM, Steve Ebersole wrote: The reason for this instead of just overriding setUp()/tearDown() would be to only execute this stuff when we actually rebuild the session fatory. I worked on the CaveatEmptor tests and I do this using the TestSetup decorator: public static Test suite() { TestSuite suite = new TestSuite(); suite.addTestSuite( UserTest.class ); suite.addTestSuite( ItemTest.class ); suite.addTestSuite( CategoryItemTest.class ); suite.addTestSuite( AuditTest.class ); suite.addTestSuite( NestedSetTest.class ); return new HibernateTestSetup(suite); } public class HibernateTestSetup extends junit.extensions.TestSetup { public HibernateTestSetup(Test test) { super(test); // Enable automatic schema generation for unit testing, if not already set in configuration HibernateUtil.getConfiguration().setProperty (Environment.HBM2DDL_AUTO, "create-drop"); } protected void setUp() throws Exception { super.setUp(); HibernateUtil.rebuildSessionFactory(); } protected void tearDown() throws Exception { super.tearDown(); HibernateUtil.getSessionFactory().close(); } } This setup/teardown is executed once for the suite I'm wrapping. --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] testing question
In working on this functionality to test the support for "database generated" values, I ran across an interesting issue with unit testing this functionality. Basically, the only real way to test this in a consistent fashion across all databases is to apply triggers to the database in use for testing (after schema generation). This is the same reason why I always get failures on the tests relating to stored procedure support. I think we should come up with a unified way to approach this. So I'll throw out my proposal as a starting point and see if anyone has better solutions. The basic idea is to have the individual tests in this category register "additional db objects" with the base test case class; these would be used during setUp() and tearDown() processing. DatabaseObject might look like: interface DatabaseObject { void doCreate(Connection conn); void doDrop(Connection conn); } I am thinking of a new test base class that tests relying on non-table db-object creation could extend; or even add this functionality to the existing TestCase. It would add a single new method "DatabaseObject[] getAdditionalDatabaseObjects(Dialect dialect)" which it would call during setUp() processing. The reason for this instead of just overriding setUp()/tearDown() would be to only execute this stuff when we actually rebuild the session fatory. The simple option would be to have each test class do this work themselves in setUp() and tearDown() for each test execution even though we are not necessarily creating/dropping the schema at that frequency. Anyway, thoughts? Steve --- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel