Okay, so it occurred to me that the
OpenEarsEventsObserver class registers itself for
NSNotifications on the main thread when it’s initialised, which is how it hears about events. This is asynchronous whereas unit test execution is just synchronous.
The solution was to use so that we assert that the value _eventually_ becomes the one we are looking for. The timeout needs to be set to at least 1s, so that the delegate has a chance to receive the message: in the delegate method I assign onto a property that I’m asserting over.
You can still use
runRecognitionOnWavFileAtPath:: the documentation claims that it’s ‘synchronous’, which may have been the thing that misled me.
So good stuff that that’s working.
Halle, I noticed that OpenEars can’t be tested in a Logic Test with this method (see the definitions of Application and Logic tests here.
Is there a way to make OpenEars recognition work without having the application host our tests (i.e. setting
TEST_HOST to the application binary)? In principle I think checking whether a WAV test resource is recognised correctly is pure enough to be a ‘Logic’ test rather than an ‘Application’ test.
I’ll be happy to provide some example code if it helps you debug this.