Hi Ralf,
On 16.01.2010 10:18, Ralf Joachim wrote:
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
Having said that I think I know what causes your tests to fail.
Regards
Ralf
Michael Schröder schrieb:
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!
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
