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