On 17 Jan 2007, at 04:10, Brian Stansberry wrote:
I don't think the JBC testsuite is the place to test how the AS
or
Hibernate use it. Those tests belong in Hibernate or the AS.
I do think the JBC testsuite should test the major known usage
patterns that people like Hibernate use (e.g. simulate a read
followed by a putForExternalRead) so any problems can be found
quickly. But you shouldn't need the AS to do that.
It would be great though if it were fairly easy to test a new
version of JBC against the relevant releases of AS/Hibernate. E.g.,
perhaps a target in the AS/Hibernate testsuites that is able to
execute the unit tests that involve JBC, along with some
infrastructure to pull in the desired JBC release.
True. The integration suite should not reside within JBoss Cache;
just that it needs to be "somewhere".
I'm not fundamentally disagreeing with what Manik said about
integration tests though -- I don't like http session replication
tests in the JBC testsuite, but that's different from tests of how
JBC uses AS resources. A lot of JBC code assumes the presence of
JEE resources; there should be tests of that code that are run in a
real JEE environment. The JDBCCacheLoader case is one; another
issue is the use of DummyTransactionManager in most unit tests in
lieu of testing in the AS with a real transaction manager.
True as well; we should not assume JBoss AS. (Anyone remember the
issues we saw when plugging in JBoss Transactions, even though
everything worked well with the DummyTM and the JBoss AS TM? Or some
while back when we saw weird behaviour with WebLogic's TM?)
We're not joined at the hip with JBoss AS. As Brian correctly
pointed out, there are some Java EE dependencies, but that's all.
For correctness, maybe we should even be using the RIs for such Java
EE deps during testing?
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> But thinking about this, should JBC be the one providing
> integration tests with Hibernate? Unlike JBDCCL where Cache
> is the client for AS, in Hibernate's case, it's Hibernate
> who's JBC's client and therefore, Hibernate should be the one tested.
>
>> From JBC's point of view, we don't know what we need to do
> to Hibernate to confirm that is working correctly, it's not
> really our domain. IMHO, this is Hibernate's domain and it's
> this project who should include integration tests with JBC versions.
>
> Galder ZamarreƱo
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> IT executives: Red Hat still #1 for value
>
http://www.redhat.com/promo/vendor/
>
> -----Original Message-----
> From: Ryan Campbell
> Sent: 16 January 2007 17:39
> To: Manik Surtani; Galder Zamarreno
> Cc: jbosscache-dev(a)lists.jboss.org; QA
> Subject: RE: [jbosscache-dev] Testing JDBCCacheLoader -
> Embedding AS inside a UT?
>
> The portal builds do something similar. We have exploded
> jboss instances on cruisecontrol, and pass in their paths via
> system properties.
>
> We don't have anything like this for hibernate, although this
> is pretty easy using <get/> and
repository.jboss.com.
>
>> -----Original Message-----
>> From: Manik Surtani [mailto:manik@jboss.org]
>> Sent: Tuesday, January 16, 2007 4:05 AM
>> To: Galder Zamarreno
>> Cc: jbosscache-dev(a)lists.jboss.org; QA
>> Subject: Re: [jbosscache-dev] Testing JDBCCacheLoader - Embedding AS
>> inside a UT?
>>
>> Wow. I'd hate to add the weight of downloading (on the fly?) an AS
>> version, starting and stopping it from within a unit test.
>>
>> As an immediate solution we could add this to the list of manual
>> release procedures so it gets done with every release, but as you
>> pointed out manual steps suck too.
>>
>> IMO, this falls into a category of integration tests (such as
>> testing
>> with Hibernate releases) which needs to sit outside of the usual
>> cruise control runs and the functional test suite.
>>
>> I propose a more formal integration test suite (maybe with it's own
>> cruise control target?) which:
>>
>> 1) Pulls down different versions of JBC and performs compat/interop
>> tests (we already have these) 2) Pulls down different Hibernate
>> versions and performs tests on these 3) Pulls down different AS
>> versions and performs tests, including the JDBCCacheLoader with
>> managed collections as well as other JBC 'use cases' such as SFSBs
>> and HTTP Sessions
>> 3.1) Different combinations of the versions in 2) and 3), to test
>> EJB3 entity beans
>> 3.2) Combinations including different JGroups versions
>>
>> So as you can see, we have a shit load of test combinations that can
>> come out of this. I do see the value here though, it will even make
>> QA's work in certifying JBC releases against AS versions and JGroups
>> versions (and even Hibernate versions) easier.
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik(a)jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik(a)surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>>
>> On 16 Jan 2007, at 00:42, Galder Zamarreno wrote:
>>
>>> I've been messing around with JDBCCacheLoader and I have realised
>>> that we don't currently have a unit test that can test the
>>> JDBCCacheLoader inside an AS. Ok, we have JDBCCacheLoaderTest that
>>> can work based on the cache-jdbc.properties and you could start AS
>>> manually and test it.
>>>
>>> This however is a manual process and when it comes to CC, only
>>> standalone JDBCCacheLoader is being tested.
>>>
>>> I think it'd be ideal to basically extend JDBCCacheLoaderTest to
>>> set
>>> it up to work with an AS (starting it/stopping it). This would give
>>> us even more confidence and coverage for the
>>> ManagedConnectionFactory area. I might not have time to do that
>>> before I commit my current work for BETA1 but definitely something
>>> worth bearing in mind.
>>>
>>> Another question would be of course, what AS version would be
>>> integrate against?
>>>
>>> There're various projects out there that have done something
>>> similar, first obviously AS itself and second messaging. What's
>>> your
>>> experience with this? What have we learnt about it? Shall we reuse
>>> some code for this? We would need a very limited AS version
>>> actually
>>> with JNDI, JDBC Connection Pooling, HS and HS driver.
>>>
>>> As you can see, this opens ups whole bunch of questions. Thoughts?
>>> Opinions? Critics?
>>>
>>> Cheers,
>>>
>>> Galder ZamarreƱo
>>> Sr. Software Maintenance Engineer
>>> JBoss, a division of Red Hat
>>>
>>> IT executives: Red Hat still #1 for value
http://www.redhat.com/
>>> promo/vendor/
>>>
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry