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