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
>
>
> ------------------------------------------------------------------------------
> 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
>
>
--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
------------------------------------------------------------------------------
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
