- The name of the workspace was “Demo”. I would expect the project to have the same name as the pod being written.
- The demo project contained the Podfile, requiring developers to cd into Demo, then run pod install. I would expect the Podfile to live in the root of the project.
- The demo project contained tests for the pod. I would expect the demo to be a demo and to have a test project that unit tests the pod being written.
Fixing the folder structure and naming is fairly straightforward. You can move the contents of the Demo folder one level up. This brings the Podfile to the root. The Podfile can also explicitly name the workspace.
You’ll have to update .travis.yml to build a different workspace and to reference the development pod in the same folder.
You can see this commit in ARTiledImageView that accomplishes the same.
The tests that are part of the Demo project are really integration tests. I’ve renamed those consequently with a bulk replace of file names and within the source code. You can see it in this commit in ARTiledImageView.
Let’s build a clean unit test project for the pod, independent of the Demo project.
Create a new empty project in XCode called “Tests” or, if you prefer, “UnitTests”.
Add a target.
Choose Cocoa Touch Unit Testing bundle.
Open Manage Schemes and make sure the scheme is Shared. Then edit the Test project’s scheme and check the Run box under the Build action.
The Podfile must now reference “Demo”, “Tests” and the “IntegrationTests” project. The syntax for that is a bit backwards, discussed in https://github.com/CocoaPods/CocoaPods/issues/1922.
Travis will build “Tests” and “IntegrationTests” in a matrix.
You can see the results of the above in this commit in ARASCIISwizzle.
This is a lot closer to the Rubygems-style organization where everything is accessible from the top and tests live at the same level as pod classes.