On Dec 23, 2017, at 23:03 , Daryle Walker <dary...@mac.com> wrote: > > The library doesn’t need DispatchData, just my test case (and only as posing > as a Data instance).
You *could* try moving the logic that’s inside your current enumerateBytes closure to a new method, and just call the method from the closure. Then, write another method in the test target, similar to the one that uses enumerateBytes, but manually breaks the original Data object into smaller ones (based on, say, an array of start indexes that a test can pass in), and feed those sequentially to the new method with the moved logic. That would test your boundary-crossing code, which seems to be the point here. (It would actually test it better, because you could automate testing of lots of boundary positions.) > It doesn’t seem I can do it without heroic measures by making a mixed > Swift/Objective-C test project. And even if that is possible, I don’t even > know if the Swift Package Manager supports it. Or, do this anyway. A mixed project is not "heroic measures”, it’s likely one file with 5 lines of Obj-C code. And surely you can test whether SwiftPM supports the mix in about 5 seconds, just with placeholder code in a single .m file. _______________________________________________ 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