Hi guys, I've spotted that JdbcMixedCacheStoreTest and others currently use TestObjectStreamMarshaller rather than VersionAwareMarshaller. Why is this? Easies of debugging with XStream based marshaller? To increase test coverage, I'd suggest using VAM rather TestObjectStreamMarshaller in tests as well. In the case of JdbcMixedCacheStoreTest, the extended test coverage comes from the fact that fromStream and toStream use start/multiple writes/finish marshalling pattern, which is different to RPC calls, where it's basically, start/one write/finish. I can see the point of dummy cache stores cos you avoid needing a database, files...etc, but I'm not sure whether about a dummy/test marshaller. The more the production marshaller is used, the bigger test coverage we have.

Regards,

Yes, it was for ease of debugging, and also to isolate the cause of problems. I think we should stick with the Test marshaller for such purposes, even if purely for the sake of component isolation during testing.

As for the coverage issues re: the VAM, there should be a separate set of unit tests for the VAM to ensure every known type is properly marshalled and unmarshalled by the VAM.

Cheers Manik On 3 Jun 2009, at 16:59, Galder Zamarreno wrote: > Hi guys, > > I've spotted that JdbcMixedCacheStoreTest and others currently use > TestObjectStreamMarshaller rather than VersionAwareMarshaller. Why is > this? Easies of debugging with XStream based marshaller? > > To increase test coverage, I'd suggest using VAM rather > TestObjectStreamMarshaller in tests as well. > > In the case of JdbcMixedCacheStoreTest, the extended test coverage > comes from the fact that fromStream and toStream use start/multiple > writes/finish marshalling pattern, which is different to RPC calls, > where it's basically, start/one write/finish. > > I can see the point of dummy cache stores cos you avoid needing a > database, files...etc, but I'm not sure whether about a dummy/test > marshaller. The more the production marshaller is used, the bigger > test coverage we have. > > Regards, > -- > Galder Zamarreño > Sr. Software Maintenance Engineer > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

On 4 Jun 2009, at 08:40, Galder Zamarreno wrote: > > > Manik Surtani wrote: >> Yes, it was for ease of debugging, and also to isolate the cause of >> problems. I think we should stick with the Test marshaller for such >> purposes, even if purely for the sake of component isolation during >> testing. > > Ok. > >> As for the coverage issues re: the VAM, there should be a separate >> set of unit tests for the VAM to ensure every known type is properly >> marshalled and unmarshalled by the VAM. > > I built a similar test for JBoss Marshaller called > JBossMarshallerTest. It know uses VAM rather than JBossMarshaller, so > that's effectively it. I need to double check whether all types are > now covered and I'll refactor it to better show it's job now. Great!

Cheers Manik -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org