Hi, I'm implementing the MongoDBTestHelper and I have a question
Most of the methods implents are referencing a "Cache". Either for Infispan or for EhCache there is a specific implementation of Cache so should I implement mine because I think there isn't any cache into the mongodb-java-driver ? Guillaume 2012/3/14 Guillaume SCHEIBEL <guillaume.schei...@gmail.com> > Ok I see, according to what you said guys, I'll first remove all tests I > added and run/work with the core test suite. if some mongodb test will be > needed (I think about replica set management or map/reduce but that's for > later) I will create them into the module directly. > > I think I'll be able to make a new pull request this week (probably > tomorrow or friday). What is the best practice about that, making 1 commit > like OGM-123 mongodb support (with the dialect, the TestHelper, etc) or > making specific commits like I did (or tried to do) for the previous pull > request ? > > > Guillaume > > 2012/3/13 Emmanuel Bernard <emman...@hibernate.org> > >> >> On 13 mars 2012, at 20:19, Sanne Grinovero wrote: >> >> > Hi, >> > I'm answering inline: >> > >> > On 13 March 2012 16:39, Guillaume SCHEIBEL < >> guillaume.schei...@gmail.com> wrote: >> >> Hello, >> >> >> >> About unit tests during the development phase on OGM-mongodb, I'm >> wondering >> >> what is the best way. >> >> Actually, I've developped some specific tests (CRUD mainly) because I >> was >> >> not aware of the existing test suite. So my question is: should I >> remove >> >> all my tests and just use core test or should I let them to test >> specific >> >> points (like @Embdedded into @Embedded) ? >> > >> > I think it's a good idea to have custom tests as well, currently the >> > ones "inherited" from the core module are really testing only the core >> > bits. >> > Feel free to add more tests in your custom module, but maybe check you >> > don't have duplicates. >> > Also if they are not specific to your module, maybe you should add >> > them to the core module instead so that they help covering all >> > "dialects". >> >> My feeling is that most tests should be in core as the "TCK" to make sure >> each dialect is safe or see when it fails. So I would favor to move tests >> into core as much as possible. >> In your example, there is nothing MongoDB specific about @Embedded and we >> should make sure we indeed support that for all dialects. >> >> The tests that could stay in your won modules are tests that ensure that >> the embedded object is properly put in the document and not else where. >> That does not make much sense right now but I imagine that for collection >> of embeddable and when we support metadata driven datastore specific >> tuning, we will want to test such things. (ie collections of embeddable are >> in the document in mongo and outside in a different key in say Infinispan. >> >> > >> >> And am I wrong if I say that to launch the core test suite I just have >> to >> >> add a simple hibernate.properties into src/test/resources/ of the >> mongodb >> >> module and launch maven with the test goal ? >> > >> > You'll have to add a hibernate.properties, but also create an >> > implementation of org.hibernate.ogm.test.utils.TestableGridDialect >> > and edit org.hibernate.ogm.test.utils.TestHelper at line 42 to add >> > your knownTestDialects. >> > >> > To see how to implement a TestableGridDialect, I guess your best guide >> > is to look into the EHCache and Infinispan implementations for >> > examples. >> > >> > You're beta-testing these instructions, feel free to ask more details >> > I might have forgotten, so I can make a good wiki page out of this. >> >> Let's open a wiki page to document these discoveries that will help >> wannabe datastore contributors. >> Title: "How to write a Datastore in Hibernate OGM" in the hibernate ogm >> subspace. >> >> BTW, in eclipse and in intellij, you can say that you run a given (set >> of) test based on the classpath of a specific module. That will let you run >> the test with the mongodb settings stored in your hibernate.properties file. >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
