Emmanuel,
The unit test in question is functional, in that it extends SearchTestCase. The test
requires verification that searchFactoryImplementor.getWorker() is never called by
FullTextIndexEventListener. Mockito is used in the current test
1) to mock both SearchFactoryImplementor and Worker, and
2) to verify that searchFactoryImplementor.getWorker() is never called
A bona fide data model with annotations, a Hibernate session, CRUD operations, are
performed by the test as well. Only the above listed items are mocked.
Mockito makes the above trivial to implement, hence its usage. If that is palatable then
I will leave the test as-is and introduce Mockito as a dependency.
Tom
On Tue, Mar 29, 2011 at 8:48 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
Hi Tom,
Most tests in HSearch are more integration / functional tests than true unit tests. Since
we can tests everything with in-memory components it ends up quite fast and more
"real life".
If you feel that there is no way to reproduce the issue at hand in a functional test, is
that:
- because you can't reproduce
- because it would require too much work?
All in all, if you need Mockito, we can add it as a test dependency. but if we can find a
way to test the problem with a functional / integration test that would be preferable.
Emmanuel
On 28 mars 2011, at 21:12, Tom Waterhouse wrote:
> I've completed a unit test for HSEARCH-679. Testing the issue was made
> easier using mock objects, as I needed to mock SearchFactoryImplementor and
> Worker to determine if indexing work was created during transaction commit.
>
> The mocking library I've used recently is Mockito, and is the library used
> for the test. I don't know that mocks have been used to this point for
> Hibernate Search testing. Mockito/mocking is acceptable?
>
> You can see the test I created as an attachment to HSEARCH-679.
>
> Tom
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev