Yes, you would create a new test target and add all the GUI stuff as a member of the test target. Of course, you will want to exclude them from other targets. You shouldn’t need to do any library linking since it is a common codebase. Simply include the classes and put the glue code in the App Delegate.
Keary Suska Esoteritech, Inc. > On Dec 13, 2019, at 7:35 AM, Robert Walsh via Cocoa-dev > <cocoa-dev@lists.apple.com> wrote: > > Thanks - I just finished doing that. I stubbed out a simple main that has > enough smarts to use this TcpClient the way it will be used in the real app, > and I was able to connect to an instance of the server to which the command > line tool needs to connect. This server is running on another machine, not > on localhost. I was able to make this connection without needing to grant > any entitlements to the command line tool, so the problem occurs only when > trying to run the unit test. In short, the unit test case is allowed to > start a server and accept connections (from telnet, for example), and the > class being tested is allowed to connect to an external server when not being > run within the test case. So far, though, the class being tested cannot > connect to the server when both are used inside the test case. > > I can probably move forward by testing this particular class the old > fashioned way through manual inspection and then mocking it in other classes > where it will be used. > > If, though, I want to go the dummy test app route, would I create another > target that is a GUI app, either link to a static library containing the > testable classes or include them as compile targets, and then create a unit > test bundle that targets that GUI app? > > Rob > > > ________________________________ > From: Keary Suska <cocoa-...@esoteritech.com> > Sent: Friday, December 13, 2019 12:18 PM > To: Robert Walsh <rwa...@envisionware.com> > Cc: Cocoa-Dev (Apple) <cocoa-dev@lists.apple.com> > Subject: Re: Permission Denied trying to connect to localhost in unit test > > I would first test to see if you can access networking at all—i.e. connect to > a public HTTP server and see if it works. If it doesn’t, then you are > probably running against the entitlements issue. I suspect that the “dummy > target” indicated is simply a GUI app wrapper built just for testing but not > for deployment. Should be easy enough because it doesn’t have to do anything > in the GUI. > > Keary Suska > Esoteritech, Inc. > > >> On Dec 13, 2019, at 4:42 AM, Robert Walsh via Cocoa-dev >> <cocoa-dev@lists.apple.com> wrote: >> >> The errno is 13 (which I think is just a generic Permission Denied). >> >> I am connecting to localhost. >> >> I did find this post in the Apple Developer Forums >> (https://forums.developer.apple.com/thread/52211): >> How do I unittest a command line application? |Apple Developer >> Forums<https://forums.developer.apple.com/thread/52211> >> Yes, you can add the unit testing bundle, but it won't let you set Target to >> be Tested.. Right. That’s because the machinery to load your test bundle >> within a process only works if the process is based on a GUI framework (like >> Cocoa or Cocoa Touch). >> forums.developer.apple.com >> >> >> A command line tool typically does not use a GUI framework and thus the test >> machinery is unable to load your bundle into that tool. >> >> However, you can test without an app target. If you set the Target to be >> Tested popup to None, Xcode will load your test bundle into its built-in >> ‘test runner’ tool, xctest. >> >> This works well for most but there are some gotchas. Specifically, if the >> code you’re using requires entitlements then you won’t be able to test it >> like this because there’s no way to give those entitlements to xctest. The >> standard workaround for that is to add a dummy test target app to your >> project. >> >> >> Assuming the problem is that I need to add the App Sandbox -> Outgoing >> Connections (Client) entitlement to the command line target (since I can't >> add any entitlements to the test target; clicking "+ Capabilities" brings up >> a dialog saying that capabilities are not support for this target), how do I >> create "a dummy test target app?" As I said before, I created the test >> target by using the Unit Test Bundle template, and I don't see any other >> relevant choices. >> >> >> Rob >> >> >> ________________________________ >> From: Jens Alfke <j...@mooseyard.com> >> Sent: Thursday, December 12, 2019 1:58 PM >> To: Robert Walsh <rwa...@envisionware.com> >> Cc: Cocoa-Dev (Apple) <cocoa-dev@lists.apple.com> >> Subject: Re: Permission Denied trying to connect to localhost in unit test >> >> >> >> On Dec 12, 2019, at 7:42 AM, Robert Walsh via Cocoa-dev >> <cocoa-dev@lists.apple.com<mailto:cocoa-dev@lists.apple.com>> wrote: >> >> I am writing a command line application in Objective-C that needs to make a >> TCP connection to a server. In a unit test for the TcpClient class I am >> writing, I have a simple TCP server that listens for connections in a >> thread. When I try to connect to this socket from the client socket class, >> connect() fails and perror reports Permission Denied. >> >> That's odd. I've written plenty of macOS networking code and not seen this >> problem. What is the errno value? >> >> The only thing I can guess is that the Xcode test-runner process is being >> sandboxed to prevent outgoing networking, but I've definitely run TCP >> connections from XCTests without problems. Are you connecting to "localhost" >> / 127.0.0.1, or using an explicit IP address? >> >> —Jens >> _______________________________________________ >> >> 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/cocoa-dev%40esoteritech.com >> >> This email sent to cocoa-...@esoteritech.com > > _______________________________________________ > > 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/cocoa-dev%40esoteritech.com > > This email sent to cocoa-...@esoteritech.com _______________________________________________ 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
