[fushunpoon]

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.

Cheers.

[fushunpoon]

Another question for you, Halle.

It would be very useful to be able to write automatic tests that verify any one particular language model recognises pre-recorded segments of speech. However, the only function that is able to perform this task, runRecognitionOnWavFileAtPath:, DOES NOT RETURN A HYPOTHESIS!

In order for a unit test to verify that a wav file is correctly interpreted as a the expected sentence, the only way I see it being possible is to capture NSLog into a file first (see http://parmanoir.com/Redirecting_NSLog_to_a_file) and then opening that file to make assertions afterwards.

The problem with that approach is that while I can stomach the horribleness, XCode relies on NSLog to be written to the console to provide accurate test reporting so even redirecting NSLog is not an attractive option.

Please return a hypothesis or something so that automated testing can be done. Thanks!

[fushunpoon]

Hi Halle,

I’m glad that it’s on the roadmap somewhere. It would make development with OpenEars much more manageable for everybody.

Cocoapods works by sticking all Objective-C sources of a Framework into its own fake Framework directory, and then generates you a workspace that would tie your project’s various targets up with the frameworks they depend on. The main challenge is to have OpenEars’ dependencies compiled and linking correctly with the rest of the sources. It doesn’t seem like a trivial task.

[fushunpoon]

Thanks for your feedback; I managed to re-organise my test target completely and added the OpenEars and Slt frameworks to the project separately. Now it’s possible to reference OpenEars in test targets.

Cheers!

Hok

[Author]

Posts