Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests

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 <emmanuel(a)hibernate.org&gt; > > On 13 mars 2012, at 20:19, Sanne Grinovero wrote: > > > Hi, > > I'm answering inline: > > > > On 13 March 2012 16:39, Guillaume SCHEIBEL < > guillaume.scheibel(a)gmail.com&gt; 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. > >