On 19 Jan 2009, at 11:08 PM, Michael McCracken wrote:
> On Mon, Jan 19, 2009 at 12:33 PM, Christiaan Hofman <cmhof...@gmail.com
> > wrote:
>>
>>
>> On Mon, Jan 19, 2009 at 7:09 PM, Christiaan Hofman <cmhof...@gmail.com
>> >
>> wrote:
>>>
>>> On 19 Jan 2009, at 6:51 PM, Maxwell, Adam R wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 01/19/09 08:16, "Christiaan Hofman" <cmhof...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On 19 Jan 2009, at 4:56 PM, Gregory Jefferis wrote:
>>>>>
>>>>>> On 2009-01-19 04:31, "Michael McCracken" <michael.mccrac...@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>>> On Sun, Jan 18, 2009 at 8:58 PM, Gregory Jefferis
>>>>>>> <jeffe...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 2009-01-19 01:42, "Christiaan Hofman" <cmhof...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 19 Jan 2009, at 2:20 AM, Gregory Jefferis wrote:
>>>>>>>>>
>>>>>>>>>> On 2009-01-19 00:39, "Adam R. Maxwell" <amaxw...@mac.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>> I don't think that's possible, but I don't know too much
>>>>>>>>> about unit
>>>>>>>>> tests. I'd rather say that the tests should be designed to be
>>>>>>>>> independent of the prefs.
>>>>>>>>
>>>>>>>> Yes and no. I think that there could be sensible reasons to
>>>>>>>> want
>>>>>>>> to test
>>>>>>>> the effect of a preference on program behaviour.
>>>>>>>
>>>>>>> This is possible- you can remove the application domain prefs
>>>>>>> (the
>>>>>>> ones the user sets) from NSUserDefaults:
>>>>>>> [[NSUserDefaults standardUserDefaults]
>>>>>>> removePersistentDomainForName:@"edu.ucsd.cs.mmccrack.bibdesk"]
>>>>>>>
>>>>>>> this is probably a good idea to do - so the tests are always
>>>>>>> testing
>>>>>>> the same thing, and if we need to test the effects of a pref,
>>>>>>> you
>>>>>>> just
>>>>>>> set it in the test.
>>>>>>
>>>>>> Hmm, it turns out that clears all user defaults from the
>>>>>> preferences
>>>>>> file -
>>>>>> ie it hoses ~/Library/Preferences/
>>>>>> edu.ucsd.cs.mmccrack.bibdesk.plist !
>>>>>> So it 'works' ... permanently. Any further suggestions? I'm
>>>>>> finding
>>>>>> the
>>>>>> NSUserDefaults docs a bit opaque.
>>>>>>
>>>>>
>>>>> All I can think of is to save a dictionaryRepresentation
>>>>> containing
>>>>> all keys and values, so you can afterwards use
>>>>> setPersistentDomain:forName: to reinsert everything. But I'm not
>>>>> sure
>>>>> if that's safe, because dictionaryRepresentation will contain both
>>>>> values that have actually been set and values that came from the
>>>>> defaults. Also, how does the unit test report an error? It's
>>>>> important
>>>>> that the test will reach the last step even when a test fails!
>>>>
>>>> This sounds like a guarantee that doing a nightly build will wipe
>>>> out my
>>>> prefs at some point, and I really don't want that to happen! I'm
>>>> not
>>>> sure
>>>> there's a good way to do this, since you can't control
>>>> synchronization,
>>>> and
>>>> OFPreference is adding an additional layer. Is there any way to
>>>> use a
>>>> different bundle identifier for the tests?
>>>
>>>
>>> Add a script phase to the unit test target that changes the
>>> CFBundleIdentifier inside the Debug built product. This could also
>>> make sure
>>> the corresponding pref file is removed.
>>>
>>> defaults write "${BUILT_PRODUCTS_DIR}/BibDesk.app/Contents/
>>> Info.plist"
>>> CFBundleIdentifier edu.ucsd.cs.mmccrack.bibdesk.test
>>> defaults delete edu.ucsd.cs.mmccrack.bibdesk.test
>>>
>>> Christiaan
>>>
>>
>> The defaults CLT does not seem to accept it like this, here's a
>> corrected
>> script
>>
>> BUNDLE_IDENTIFIER=edu.ucsd.cs.mmccrack.bibdesk.test
>> BIBDESK_INFO="${BUILT_PRODUCTS_DIR}/BibDesk.app/Contents/Info"
>> defaults write "$BIBDESK_INFO" CFBundleIdentifier $BUNDLE_IDENTIFIER
>> plutil -convert xml1 "${BIBDESK_INFO}.plist"
>> rm -f ~/Library/Preferences/${BUNDLE_IDENTIFIER}.plist
>>
>> If we want, we could revert this in another script phase after the
>> test.
>
> The test-only bundle ID is a good idea. I didn't realize that my
> sample code would actually remove the prefs for more than the running
> app, sorry about that - the docs are indeed a little thin on this
> point.
>
> To answer the question about removing the 'default' prefs, though -
> those are in a different domain, the NSRegistrationDomain, so I'm
> pretty sure that the method I wrote about only kills the user prefs
> domain.
>
> -mike
>
>> Christiaan
>>
I never fully got the various domains (in particular the volatile
domains and suites). But anyway, this is now not relevant for this
problems.
I just committed my idea above, with some additions to avoid BD from
showing any windows when launches for the tests. It works well.
Christiaan
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
