Synchronize standard user defaults after clearing filter testcases key.
Add "error" attribute to testcase element in JUnit reporter if test result is error.
Convert all float values to double values.
Merge pull request #317 from facebook/nekto/convert_float_to_double

Convert all float values to double values.
Merge pull request #315 from facebook/nekto/synchronize_defaults_fix

Synchronize standard user defaults after clearing filter testcases key.
Merge pull request #316 from facebook/nekto/add_error_element_to_junit

Add "error" attribute to testcase element in JUnit reporter
Code cleaning.
Merge pull request #320 from facebook/nekto/code_cleaning

Code cleaning.
Use __CFPREFERENCES_AVOID_DAEMON = YES to fix pref clobbering

From @fpotter:

The problem is that preference values are causing SenTestinkgKit + XCTest to prematurely run tests... when all we wanted to do was query the tests in the bundle.

Here's what happens ...

    otest-query loads the test bundle.
    the test bundle links SenTestingKit, so dyld goes a ahead and loads SenTestingKit.
    SenTestingKit has an initialization function (i.e. marked with __attribute__((constructor))), so dyld runs that.
    The initialization function checks to see if the SenTest preference value is set. If so, it starts running tests immediately. (At this point, we haven't even gotten back to otest-query yet - it's still waiting for the bundle to finish loading).
    As soon as SenTestingKit has finished running the tests, it exits. We never return to otest-query.

So, the idea here was to clear the value of the SenTest preference before loading the test bundle. That should work... but it seems to fail intermittently, and I think I now know why.

You would assume the prefs values are read/written from ~/Library/Preferences/<app name>.plist. You would also think that prefs values are never synchronized until you explicitly call /synchronize/. That's what I thought, anyway.

As it turns out, there's actually a system service called cfprefsd that manages preferences and reading/writing them from the Preferences directory. It also caches preference values. If we're running otest-query processes in parallel, and they're each reading/writing via this daemon... it'd be expected for them to eventually stomp on each other.

But, there seems to be a way to disable the daemon usage, so I think we should do that. If you set __CFPREFERENCES_AVOID_DAEMON=YES in the environment before running otest-query, we'll be guaranteed that it won't read data from cfprefsd. That should give us more deterministic behavior. Also, I bet this makes it so that defaults are only synchronized when we explicitly call synchronize.
Merge pull request #321 from LegNeato/master

Use __CFPREFERENCES_AVOID_DAEMON = YES to fix pref clobbering