I don’t think you can test a method that returns nothing, as a passing test would reveal nothing useful.
As this method only calls the Pushofy module, the tests are probably better to go in there. It also feels to me that all of this code is related to pushing the notification so is best placed inside of Pushofy.
Also, you might like to consider how you test when the Apple push notification service fails, as remote API calls are never 100% reliable. You could then test how your ‘push’ method copes with a successful and failing call to Pushofy?
You can use test doubles to unit test methods that have side effects but no return value.
You can stub out the instantiation of Pushofy::ConnectionToAppleServer.ssl_connect and then verify that it receives the correct method invocations like write and flush.