[Building Sakai] Trunk broken: search unit tests

[John Bush]

yeah, I'll address this.  Its actually an intermittent thing, it
happens something and sometimes it doesn't it has to do with the fact
that mockito doesn't like to test stuff that's multithreaded, I just
haven't have time yet to figure out a way around that.
John Bush
602-490-0470

** This message is neither private nor confidential in fact the US
government is storing it in a warehouse located in Utah for future
data mining use cases should they arise. **


On Wed, Jun 19, 2013 at 5:50 AM, David Horwitz <david.horwitz at uct.ac.za> wrote:
> Hi All,
>
> it looks like search is failing on its unit tests on current trunk:
>
> sticsearch.ElasticSearchTest)  Time elapsed: 9.71
> sectestRefreshSite(org.sakaiproject.search.elasticsearch.ElasticSearchTest)
> Time elapsed: 10.596
> sectestRefresh(org.sakaiproject.search.elasticsearch.ElasticSearchTest)
> Time elapsed: 5.798
> sectestRebuild(org.sakaiproject.search.elasticsearch.ElasticSearchTest)
> Time elapsed: 3.583 sec  <<< ERROR!
> org.mockito.exceptions.misusing.WrongTypeOfReturnValue:
> Boolean cannot be returned by getId()
> getId() should return String
> ***
> If you're unsure why you're getting above error read on.
> Due to the nature of the syntax above problem might occur because:
> 1. This exception *might* occur in wrongly written multi-threaded tests.
>    Please refer to Mockito FAQ on limitations of concurrency testing.
> 2. A spy is stubbed using when(spy.foo()).then() syntax. It is safer to stub
> spies -
>    - with doReturn|Throw() family of methods. More in javadocs for
> Mockito.spy() method.
>
>         at
> org.sakaiproject.search.elasticsearch.ElasticSearchTest.testRebuild(ElasticSearchTest.java:471)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>         at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>         at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>
>
> Seeing n ightly skips test I can't tell if this a general problem (but
> certainly looks like it), or how long its been arround
>
>
> David
> ________________________________
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the author.
> If you are not the intended recipient of the e-mail you may not use,
> disclose, copy, redirect or print the content. If this e-mail is not related
> to the business of UCT it is sent by the sender in the sender's individual
> capacity.
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"