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.
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
