Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Need help with the testing framework
[CDO] Need help with the testing framework [message #431419] Wed, 08 July 2009 17:10 Go to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Hi.

I just implemented the SQL query, but now also want to test it.
I took a look at HibernateQueryTest, but don't really understand what's going on.
Especially the line CDOSession session = openModel1Session();
It seems to create the database and the session.
In HibernateQueryTest it creates a database by using Hibernate, but in my case (in the plugin
org.eclipse.emf.cdo.tests.db it seems to create a H2 database. That is fine, but I would like to
know where that magic happens (and I am not able to find it myself). What if I want to test it with
Derby instead of H2? Where is the switch?
I also don't find the database on my harddrive, so it seems it is automatically deleted after the
test. Could you point me to the location where that happens. Cause I want to turn the deletion off
for a moment.

Regards,
Kai
Re: [CDO] Need help with the testing framework [message #431420 is a reply to message #431419] Wed, 08 July 2009 17:20 Go to previous messageGo to next message
Kai Schlamp is currently offline Kai SchlampFriend
Messages: 344
Registered: July 2009
Senior Member
Ok, I found the location of the database. It's created in /temp and is not deleted after a test run.
But I still wonder how for example to run the test with Derby or HSQLDB instead.

Kai Schlamp wrote:
> Hi.
>
> I just implemented the SQL query, but now also want to test it.
> I took a look at HibernateQueryTest, but don't really understand what's
> going on.
> Especially the line CDOSession session = openModel1Session();
> It seems to create the database and the session.
> In HibernateQueryTest it creates a database by using Hibernate, but in
> my case (in the plugin org.eclipse.emf.cdo.tests.db it seems to create a
> H2 database. That is fine, but I would like to know where that magic
> happens (and I am not able to find it myself). What if I want to test it
> with Derby instead of H2? Where is the switch?
> I also don't find the database on my harddrive, so it seems it is
> automatically deleted after the test. Could you point me to the location
> where that happens. Cause I want to turn the deletion off for a moment.
>
> Regards,
> Kai
Re: [CDO] Need help with the testing framework [message #431427 is a reply to message #431420] Thu, 09 July 2009 09:00 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan WinklerFriend
Messages: 301
Registered: July 2009
Location: Germany
Senior Member
Kai,

I have to admit that I don't understand every single bit of the magic
behind the scenes, either ;)

That said, be sure to check out the project org.eclipse.eml.cdo.tests.db
There you'll find different AllTestsDBxxx classes which configure the
different databases (and also there the paths etc. are set).

Generally, the test framework has a list of all relevant test classes in
AllTests. This class is extended by the AllTestsDBxxx classes which set
up the context of repository and network configurations. The neat thing
about this is, that you can easily test different configurations (e.g.,
different databases) with one test run, just by configuring the
respective scenarios.


The line you mentioned -- CDOSession session = openModel1Session() -- is
a shortcut for setting up the whole CDO client stack, connect to the
server, open the session and register the model1 package (which is
contained in the .cdo.tests.model1 project).


I hope this helps a bit...

Cheers,
Stefan



Kai Schlamp schrieb:
> Ok, I found the location of the database. It's created in /temp and is
> not deleted after a test run.
> But I still wonder how for example to run the test with Derby or
> HSQLDB instead.
>
> Kai Schlamp wrote:
>> Hi.
>>
>> I just implemented the SQL query, but now also want to test it.
>> I took a look at HibernateQueryTest, but don't really understand
>> what's going on.
>> Especially the line CDOSession session = openModel1Session();
>> It seems to create the database and the session.
>> In HibernateQueryTest it creates a database by using Hibernate, but
>> in my case (in the plugin org.eclipse.emf.cdo.tests.db it seems to
>> create a H2 database. That is fine, but I would like to know where
>> that magic happens (and I am not able to find it myself). What if I
>> want to test it with Derby instead of H2? Where is the switch?
>> I also don't find the database on my harddrive, so it seems it is
>> automatically deleted after the test. Could you point me to the
>> location where that happens. Cause I want to turn the deletion off
>> for a moment.
>>
>> Regards,
>> Kai
Re: [CDO] Need help with the testing framework [message #431429 is a reply to message #431427] Thu, 09 July 2009 09:21 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6457
Registered: July 2009
Senior Member
Guys,

That's all correct. I just wanted to add, that most test cases don't
need to pre-register model1 anymore. This should be good, too:

CDOSession session = openSession();

Registering packages in advance is usually only needed in UIs, where for
example an editor must present the list of available classes *before*
instances are created/attached.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Stefan Winkler schrieb:
> Kai,
>
> I have to admit that I don't understand every single bit of the magic
> behind the scenes, either ;)
>
> That said, be sure to check out the project org.eclipse.eml.cdo.tests.db
> There you'll find different AllTestsDBxxx classes which configure the
> different databases (and also there the paths etc. are set).
>
> Generally, the test framework has a list of all relevant test classes in
> AllTests. This class is extended by the AllTestsDBxxx classes which set
> up the context of repository and network configurations. The neat thing
> about this is, that you can easily test different configurations (e.g.,
> different databases) with one test run, just by configuring the
> respective scenarios.
>
>
> The line you mentioned -- CDOSession session = openModel1Session() -- is
> a shortcut for setting up the whole CDO client stack, connect to the
> server, open the session and register the model1 package (which is
> contained in the .cdo.tests.model1 project).
>
>
> I hope this helps a bit...
>
> Cheers,
> Stefan
>
>
>
> Kai Schlamp schrieb:
>
>> Ok, I found the location of the database. It's created in /temp and is
>> not deleted after a test run.
>> But I still wonder how for example to run the test with Derby or
>> HSQLDB instead.
>>
>> Kai Schlamp wrote:
>>
>>> Hi.
>>>
>>> I just implemented the SQL query, but now also want to test it.
>>> I took a look at HibernateQueryTest, but don't really understand
>>> what's going on.
>>> Especially the line CDOSession session = openModel1Session();
>>> It seems to create the database and the session.
>>> In HibernateQueryTest it creates a database by using Hibernate, but
>>> in my case (in the plugin org.eclipse.emf.cdo.tests.db it seems to
>>> create a H2 database. That is fine, but I would like to know where
>>> that magic happens (and I am not able to find it myself). What if I
>>> want to test it with Derby instead of H2? Where is the switch?
>>> I also don't find the database on my harddrive, so it seems it is
>>> automatically deleted after the test. Could you point me to the
>>> location where that happens. Cause I want to turn the deletion off
>>> for a moment.
>>>
>>> Regards,
>>> Kai
>>>


Previous Topic:[CDO] Little patch for setting up the CDO sources workspace
Next Topic:Bug in validation with ecore model in 3.5 : "containment or bidirectionnal reference must be un
Goto Forum:
  


Current Time: Fri Dec 06 18:50:08 GMT 2019

Powered by FUDForum. Page generated in 0.01769 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top