Re: [castor-dev] Problems setting up test framework

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