Before we finish this section, let’s create a README.
md file and an MIT license file from the Github page.
To create a README.
md click on the Add a README button, to add an MIT license file, click on the Create new file button and follow Github’s official guide here, it’s really simple.
Once you are done, type in the following command to sync with the remote repository.
> git pull.
2 files changed, 24 insertions(+)create mode 100644 LICENSEcreate mode 100644 README.
mdWell done, you have just completed another milestone!Implement the podIt’s time to write some Swift codes and implement our SwiftyLib.
As we mentioned earlier, all the implementation is going to happen in the SwiftyLib target.
In the project navigator, right click on the SwiftyLab target and select New File.
Choose Swift File as the new file template, click on Next …Name the file as SwiftyLib , make sure this file belongs to the SwiftyLib target and save it in the SwiftyLib folder as shown in the screenshot below.
Let’s edit the newly created SwiftyLib.
swift file:Our library is fairly simple! It has two functions to do the calculation.
Save the file.
Remember, whenever you edit files in the SwiftyLib target, in order to let other targets use them, don’t forget to build the SwiftyLib target! Click on the Build button or use the keyboard shortcut ⇧⌘R Shift-Command-R .
we just implemented our SwiftyLib library, let’s write some unit test cases.
Write unit testsUnit testing is crucial for making sure your library is robust, and since our library is pretty simple, writing unit tests is easy :)Edit theSwiftyLibTests.
swift :Here we only test the add() function.
Run the unit test by clicking on the Test task ????:The test case should be passed, switch to the reports navigator and check the code coverage:As you can see, the coverage is only 50%, because we didn’t write a unit test for the sub() function, let’s do that now!Now run the test again and our code coverage should be improved to 100%!At this point, we have a pretty robust pod, let’s save all our changes and push them to Github.
> git add .
> git commit -m "Added test cases"> git pushConfigure Travis CI and CodecovWhenever we push new changes to Github, we should test our pod and make sure all test cases are not broken.
Travis CI is a hosted, distributed continuous integration service used to build and test software projects hosted at GitHub.
We can leverage Travis to help us run test cases and submit the code coverage report to Codecov.
Codecov is a reporting tool that is intended to process any coverage report format into a format that is standard across Codecov.
You may change the configuration of how Codecov processes reports and expresses coverage information.
In order to let Travis pick up any change in our Github repo, sync up your Github account on Travis and enable our SwiftyLib repository.
Create a .
travis.
yml file in our project folder:Basically, it instructs Travis to run the unit tests on two different devices that run different iOS versions.
You can ask Travis to test on more devices, but make sure the version of iPhone simulator supports those devices, you can check the full list here.
Save the .
travis.
yml file and push it to Github, trigger a build on Travis, you should see that Travis runs the test cases for the commit you submitted.
Next, let’s ask Travis to send the code coverage report to Codecov.
Before we go too far, let’s take a look and see what Travis has done so far.
Travis executes the following script to run the test:> xcodebuild test -enableCodeCoverage YES -project SwiftyLib.
xcodeproj -scheme SwiftyLib -sdk $TEST_SDK -destination "platform=iOS Simulator,OS=$OS,name=$NAME" ONLY_ACTIVE_ARCH=YESNotice that the code coverage report is generated with the xcodebuild test command.
If we follow Codecov’s guide, we can simply push the code coverage report to Codecov with the commands below:> bash <(curl -s https://codecov.
io/bash) -t {CODECOV_TOKEN}you probably will see some weird report with unnecessary files being reported, but we only want to see the coverage report like the one we saw earlier in Xcode.
SlatherTo fix the problem, that is to let Travis send the accurate code coverage report to Codecov, let’s borrow another tool Slather.
With slather, we can specify how to collect the code coverage information accurately.
First, let’s create the configuration file to define how to collect the code coverage information, create a new file called .
slather.
yml :Here we tell slather to collect the code coverage information from SwiftyLib scheme and please ignore the codes from the unit tests.
Now edit .
travis.
yml and add an after_success section to upload the report that collected by slather to Codecov after the unit testing is completed.
If you take a look at the log from Travis, you will see that the reports are being collected by slather and sent to Codecov:You can check the code coverage details on Codecov:Excellent!.We reached another milestone, our pod is robust and protected by Travis and Codecov.
Publish the podFinally, it’s time to publish our pod!.First, install cocoapods .
> gem install cocoapodsThen create a podspec file that defines our pod, e.
g.
, where to find the source.
> pod spec create SwiftyLib.
Specification created at SwiftyLib.
podspecEdit the SwiftyLib.
podspec file:Check if SwiftyLib.
podspec is correct, fix issues if there is any> pod lib lint.
-> SwiftyLib (0.
0.
1)SwiftyLib passed validation.
Great!.Let’s save our changes to Github!> git add .
> git commit -m "Added SwiftyLib.
podspec"> git pushStart to distribute our libraryTag the correct version> git tag 0.
0.
1> git push origin 0.
0.
1Then push it!> pod trunk push.
Updating spec repo `master`—————————????.Congrats????.SwiftyLib (0.
0.
1) successfully published????.February 24th, 15:49????.https://cocoapods.
org/pods/SwiftyLib????.Tell your friends!—————————Notice that the version number should match the spec.
version defined in the SwiftyLib.
podspec .
Congratulations!.You just published the CocoaPods library to the open-source community!The project source code can be found in Github.
.