In other words, you bootstrapped the process, right? You generated a class that had encodeWithCoder:, wrote out the results, then went back and coded initWithCoder:, using the written out stuff to pull it back in? That's what I was thinking, too. I was just wondering if there was some way to make an app that could create/edit these saved objects directly at the binary level so I could make sure of the intermediate results from option #1! Otherwise, if the test failed, how would you know which half failed, the initWithCoder: part, or the encodeWithCoder: part? I think I'll do #2. Thanks for the help!
On Nov 19, 2012, at 12:18 PM, Sean McBride wrote: > On Sun, 18 Nov 2012 21:26:09 -0600, William Squires said: > >> What's the recommended procedure for (unit) testing the initWithCoder: >> and encodeWithCoder: methods of a class that conforms to NSCoding protocol? > > I do two things: 1) a test that encodes then immediately decodes, then > compares the original with the copy. 2) I create files on disk with > serialized data, then build new objects from them by deserializing. If/when > your format changes, you then have a collection of old formats to test too. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng s...@rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com