[castor-dev] Problems setting up test framework

[Michael Schröder]

Hi, my name's Michael, I'm one of the students working on the new
cascading feature. To that end, I'm currently trying to restructure
our tests but I keep running into problems...

Backstory: Previously, we patched ourselves into the cpactf package
(test2860; see the corresponding JIRA issue) but that hasn't been
working out so well, so Werner suggested we create our own package
(cascading-it) and make use of the Spring framework, like the JPA
extensions tests do (in jpa-extensions-it).

So I pretty much copied their stuff and tried to understand it and to
trim it down to for our purposes. I've attached a patch of the current
state of my efforts. I think it's pretty self-explanatory if you take
a quick look at the directory structure. (Note: the test functions in
the files are all the same because I know for sure that that one
works.)

Using "mvn clean test" all tests should and do finish successfully,
but here are the problems:

1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?

2) @Transactional doesn't work. The tests run because all ids are
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...

3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")


I hope it's not all just dumb mistakes, but it's getting late and I'm
pretty much stuck. Thanks in advance for all advice!

[Ralf Joachim]

Hi Michael,

I would help you to get things working with cpactf if you would let me
know what kind of problems you are facing to get your tests working with
cpactf framework.

I will not support adding this tests to yet another test module or any
other test module that is based on spring (jdo-extension-it,
jpa-extension-it) in any way. I already explained this to Werner end of
last year and will vote against such an additon.

Having said that I think I know what causes your tests to fail.

Regards
Ralf

Post by Michael Schröder
Hi, my name's Michael, I'm one of the students working on the new
cascading feature. To that end, I'm currently trying to restructure
our tests but I keep running into problems...
Backstory: Previously, we patched ourselves into the cpactf package
(test2860; see the corresponding JIRA issue) but that hasn't been
working out so well, so Werner suggested we create our own package
(cascading-it) and make use of the Spring framework, like the JPA
extensions tests do (in jpa-extensions-it).
So I pretty much copied their stuff and tried to understand it and to
trim it down to for our purposes. I've attached a patch of the current
state of my efforts. I think it's pretty self-explanatory if you take
a quick look at the directory structure. (Note: the test functions in
the files are all the same because I know for sure that that one
works.)
Using "mvn clean test" all tests should and do finish successfully,
1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...
3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")
I hope it's not all just dumb mistakes, but it's getting late and I'm
pretty much stuck. Thanks in advance for all advice!
------------------------------------------------------------------------
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
Syscon Ingenieurbüro für Meß- und Datentechnik GmbH
Ralf Joachim
Raiffeisenstraße 11
72127 Kusterdingen
Germany

Tel. [phone]
Mobil: [phone]
Fax [phone]

Internet: www.syscon.eu
E-Mail: ***@syscon.eu

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Werner Guttmann]

Hi Ralf,

Post by Ralf Joachim
Hi Michael,
I would help you to get things working with cpactf if you would let me
know what kind of problems you are facing to get your tests working with
cpactf framework.
I will not support adding this tests to yet another test module or any
other test module that is based on spring (jdo-extension-it,
jpa-extension-it) in any way. I already explained this to Werner end of
last year and will vote against such an additon.

If you decide to vote against anybody wishing to use Spring and its very
useful testing support, you are basically rendering all the work by
Lukas and all the other students here in Vienna 100% useless. In other
words, without Spring and especially its spring-test package, many of
the things done would not have been possible.

First, please explain to Lukas and Michael (and many others such as
Alexander and Peter), WHY you'd vote against and other integration tests
being written with the help of spring test ? Is there anything wrong
about how this code is written ? Does the quality of the tests and/or
the test coverage not meed your standards ? Or is it simply that you
dislike spring-test being used ? I'd really like to hear your concerns here.

Second, please do NOT impose your preferences to not use Spring in your
professional environment on anybody else, much in the same way as I have
never asked you to start using Spring as a prerequisite, which
personally I would not want to. It's your choice, and you seem to have
your reasons. When I engage with student here in Vienna (like I did in
the past two years), I want them to be productive. Actually, I want them
to be as productive as possible. And this means that they should be able
to use technology and support packages that ease their work and make the
more productive so that they can focus on their task(s) at hand, and
avoid environmental issues as much as possible. And using the CPACTF
framework for most of their would/work does create a lot of issues for
them. Just to give you some ideas:

a) Does the CPACTF freamwork have support for JPA interfaces ?
b) Does it cater for concurrency ?
c) Is it widely used, and hence does it nicely integrate with
transactions, atomicity of tests, etc. ?
d) Does it integrate nicely with a test-driven approach where the
environment created in a descriptive manner, e,g, through a Spring
application context ?

All those issues have been discussed between mentors, university
personnel and the students. And when it comes down to efficiency and
productivity and familiarity, Spring test and its support for writing
easy-to-understand test cases that help you to achieve (nearly) full
test coverage became one of our building blocks.

Third, me and others at Indoqa spent a lot of time trying to understand
the benefits (and initial fallbacks of Spring test when starting to use
it more and more) in environments where persistence frameworks such as
Hibernate, JPA and Castor (sometimes) are used, and it was with the help
of spring-test that we managed to reduce the complexity of writing good
and concise integration tests in this area. If you were to have a look
at the base classes of spring-test in this area, especially it's support
for

- transactions (@Transactional, ....)
- auto-rollback
- integration of JdbcTemplate and ORM tool within one test case

I personally would like to kick out the CPACTF test framework
immediately. And I have mentioned this before numerous times. It's
simply my personal opinion.

Problem is that I do not have the time (and money) to rewrite all
existing test cases to base upon spring test. Even though I would want to.

But as already mentioned above, any new integration tests could and
should base on spring-test, for all the reasons mentioned above.

Regards
Werner

Post by Ralf Joachim
Having said that I think I know what causes your tests to fail.
Regards
Ralf

Post by Michael Schröder
Hi, my name's Michael, I'm one of the students working on the new
cascading feature. To that end, I'm currently trying to restructure
our tests but I keep running into problems...
Backstory: Previously, we patched ourselves into the cpactf package
(test2860; see the corresponding JIRA issue) but that hasn't been
working out so well, so Werner suggested we create our own package
(cascading-it) and make use of the Spring framework, like the JPA
extensions tests do (in jpa-extensions-it).
So I pretty much copied their stuff and tried to understand it and to
trim it down to for our purposes. I've attached a patch of the current
state of my efforts. I think it's pretty self-explanatory if you take
a quick look at the directory structure. (Note: the test functions in
the files are all the same because I know for sure that that one
works.)
Using "mvn clean test" all tests should and do finish successfully,
1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...
3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")
I hope it's not all just dumb mistakes, but it's getting late and I'm
pretty much stuck. Thanks in advance for all advice!
------------------------------------------------------------------------
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Lukas Lang]

Hey Michael,

first of all I must state that it's great to see you making progress!
As Ralph already said in his previous response, it would be nice if you could provide more information. However, I will try to spot possible mistakes (see comments inline).

Post by Michael Schröder
Using "mvn clean test" all tests should and do finish successfully,
1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?

Maven itself always loads dependencies from the local repository (.m2). Your POM depends on castor-jdo, which should contain changes made by you recently. I think this is where castor-orm comes in. Unfortunately, this is a dependency cycle because castor-orm depends on a previous version of Castor (this has become a real pain since the last two years). You could try to exclude transitive dependencies of castor-orm using the <exclusions> element.

Post by Michael Schröder
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...

Several Spring application context files in your patch declare a "myDataSource" bean, being configured by property replacement without declaring a "propertyPlaceholderConfigurer". If you want to use environment variables (from your shell) you should do so.
To verify correct behavior of your transactional test environment, could you try accessing the database within a transactional test using the SimpleJdbcTemplate?

Post by Michael Schröder
3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")

I think this could be either a problem with "Working Directories" and relative paths in Eclipse/POM, or simply the database has not yet been created by Maven (the maven-sql-plugin more precisely). In the second case, just run a "mvn clean install -Dmaven.test.skip=true" to execute the maven-sql-plugin resulting in a clean Derby instance in the target folder. Maven, however, does not allow the execution of a single plugin...this could be fixed using profiles.

Unfortunately, the combination of Eclipse/Maven/Castor is not able to handle paths correctly as I mentioned above. You can fix that by setting the Working Directory of your Eclipse test execution (Tab "Arguments") to the module your test is located (e.g. "${workspace_loc:castor/jpa-extensions-it}").

Hope that helps. If not, let us know!

Regards,
Lukas
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Michael Schröder]

Thanks for the answers, we'll look into that.

Ralf: you said you think you know what causes our tests to fail, could you
elaborate?

As for the problems we had with the cpactf package, they were mainly:

1) whenever we ran more than a single test class, only the first one would
finish succesfully and the rest would fail with various errors. Running them
individually, they all work as expected.

2) Sometimes we got hammered with IllegalStateExceptions (they happened
literally after every single test run), which we could only resolve by
restarting Eclipse.

3) An additional annoyance was that sometimes when some of the tests failed
with errors, the ones after that couldn't get a lock on the database so we
had to wait for some timeout function to finish before continuing, which
would take about a minute or two per test (stopping them early was not
possible).


Personally, I don't care one way or the other how our tests are organized,
just that they run, realiably, and without too much overhead.

Post by Lukas Lang
Hey Michael,
first of all I must state that it's great to see you making progress!
As Ralph already said in his previous response, it would be nice if you
could provide more information. However, I will try to spot possible
mistakes (see comments inline).

Post by Michael Schröder
Using "mvn clean test" all tests should and do finish successfully,
1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?

Maven itself always loads dependencies from the local repository (.m2).
Your POM depends on castor-jdo, which should contain changes made by you
recently. I think this is where castor-orm comes in. Unfortunately, this is
a dependency cycle because castor-orm depends on a previous version of
Castor (this has become a real pain since the last two years). You could try
to exclude transitive dependencies of castor-orm using the <exclusions>
element.

Post by Michael Schröder
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...

Several Spring application context files in your patch declare a
"myDataSource" bean, being configured by property replacement without
declaring a "propertyPlaceholderConfigurer". If you want to use environment
variables (from your shell) you should do so.
To verify correct behavior of your transactional test environment, could
you try accessing the database within a transactional test using the
SimpleJdbcTemplate?

Post by Michael Schröder
3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")

I think this could be either a problem with "Working Directories" and
relative paths in Eclipse/POM, or simply the database has not yet been
created by Maven (the maven-sql-plugin more precisely). In the second case,
just run a "mvn clean install -Dmaven.test.skip=true" to execute the
maven-sql-plugin resulting in a clean Derby instance in the target folder.
Maven, however, does not allow the execution of a single plugin...this could
be fixed using profiles.
Unfortunately, the combination of Eclipse/Maven/Castor is not able to
handle paths correctly as I mentioned above. You can fix that by setting the
Working Directory of your Eclipse test execution (Tab "Arguments") to the
module your test is located (e.g.
"${workspace_loc:castor/jpa-extensions-it}").
Hope that helps. If not, let us know!
Regards,
Lukas
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Michael Schröder]

Ok, the cascading-it tests now run in Eclipse (setting the working directory
did the trick) but I'm still having troubles with @Transactional:

I've added a propertyConfigurer to spring-config-create.xml (plus the
corresponding db.properties file) and added the dataSource to the
transactionManager. This seems to work: If I access the db directly via
SimpleJdbcTemplate, transactional now rolls back as expected. But with
castor: no chance.

I think this is because the jdoManager and the transactionManager use a
different dataSource (the one defined in jdo-conf.xml and myDataSource,
respectively), so I kind of understand why it doesn't work. What do I need
to do, to set that whole thing up properly?

Also, it was my understanding that, as long as I don't specify a dataSource
for the transactionManager explicitly, it would just use the one of the
jdoManager... but that's apperently not the case, otherwise this would have
worked already.


(note: attached patch only includes the new changes)

Post by Lukas Lang
Hey Michael,
first of all I must state that it's great to see you making progress!
As Ralph already said in his previous response, it would be nice if you
could provide more information. However, I will try to spot possible
mistakes (see comments inline).

Post by Michael Schröder
Using "mvn clean test" all tests should and do finish successfully,
1) It doesn't seem to use the current state of it's parent castor
source, so the changes we've made to our trunk aren't there. (That's
why autostore is set to true, so the tests can run without making use
of our cascading feature.) I guess you can configure that in the
pom.xml?

Maven itself always loads dependencies from the local repository (.m2).
Your POM depends on castor-jdo, which should contain changes made by you
recently. I think this is where castor-orm comes in. Unfortunately, this is
a dependency cycle because castor-orm depends on a previous version of
Castor (this has become a real pain since the last two years). You could try
to exclude transitive dependencies of castor-orm using the <exclusions>
element.

Post by Michael Schröder
different, but if you were to e.g. make create2() use the same ids as
create() you'll get an error. The test classes are all
AbstractTransactionalJUnit4SpringContextTests and I'm pretty sure the
transactionManager gets injected correctly (at least everything's done
exactly like in jpa-extension-it). I've got to be missing something
here...

Several Spring application context files in your patch declare a
"myDataSource" bean, being configured by property replacement without
declaring a "propertyPlaceholderConfigurer". If you want to use environment
variables (from your shell) you should do so.
To verify correct behavior of your transactional test environment, could
you try accessing the database within a transactional test using the
SimpleJdbcTemplate?

Post by Michael Schröder
3) It doesn't work with JUnit in Eclipse. It can't find the database.
(I used to get something along the lines of "schema TEST doesn't
exist" but now all I'm getting is "Database target/test not found")

I think this could be either a problem with "Working Directories" and
relative paths in Eclipse/POM, or simply the database has not yet been
created by Maven (the maven-sql-plugin more precisely). In the second case,
just run a "mvn clean install -Dmaven.test.skip=true" to execute the
maven-sql-plugin resulting in a clean Derby instance in the target folder.
Maven, however, does not allow the execution of a single plugin...this could
be fixed using profiles.
Unfortunately, the combination of Eclipse/Maven/Castor is not able to
handle paths correctly as I mentioned above. You can fix that by setting the
Working Directory of your Eclipse test execution (Tab "Arguments") to the
module your test is located (e.g.
"${workspace_loc:castor/jpa-extensions-it}").
Hope that helps. If not, let us know!
Regards,
Lukas
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email