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

[Guillaume SCHEIBEL]

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.scheibel at 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 <emmanuel at 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.scheibel at 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.
>>
>>
>