Consider public access

[ashfurrow]

Right now, Alamofire uses the default access control qualifier, internal. Other targets in a project, such a unit tests, might want to access these internal classes, too (to make requests, for instance). I'm a bit unsure which classes, extensions, and functions should be public and which ones left internal.

Related to #42.

[mattt]

Unit tests work just fine as-is. Are you running into any specific issue with access control?

[ashfurrow]

I'm not sure how your unit tests are set up – on my project, I have the Alamofire.swift file included in my framework target, which is linked against for the unit testing target. In my framework target, I was able to access the Alamofire class, since its public, but the methods in the extensions, like request and response are internal, so I couldn't access them.

It's kind of an edge case, anyway, since I don't expect many people need Alamofire in their unit tests (I was just performing a sanity check when I ran into this problem). A possible solution would be including the Alamofire file in the unit test target, too.

[mxswd]

I would include all framework sources in the tests target instead of linking a test target against a framework. This way you can still access the internal members of the, would be, framework.

[mattt]

As of 9f7c365, Alamofire is structured for use as a framework, rather than a drop-in file. The access control is such that the unit tests target in the provided test harness is able to successfully run all of the tests.