Unit testing needs only optional methods of protocol in Swift
There are plenty of approaches that can fix your problem. But the main issue is how you build your classes. So IMHO you should focus on that.

Recommendation 1:  You should build your classes with composition of protocols. Loggable, Runnable, Flyable etc. If you build your class with combination of many protocols, the problem would be solved. And since Swift enables default implementations for protocols you can write a shorter class that is build by protocols. In this case you can test these protocols and their implementations separately.

Recommendation 2: There is a code smell in this design. You say no need to test for most of the methods. But you still put them in the same interface. And inject a class that conforms to this interface. You should change the class structure or injection interface. As in first recommendation I offer you to separate those methods to several interfaces and inject each other separately. 

let controller = Controller(service: ABCProtocolMock(), anotherService: XYZProtocolMock())


Recommendation 3: Code Complete 2nd Ed. offers classes should have no more than 7 methods. If a class has more methods they should be separated through many considerations including SOLID. 

Recommendation 4: I don't support this solution, because its another hacky code smell. But as a lazy developer you can think about if only one method will be testable/replacable why do you inject a whole interface. You can just inject a small interface that provides that method only.

Recommendation 5: Using utility functions can be another hacky solution. Since you want to test just one method of the class and if this method's implementation can be abstracted from internals of your class. You can forward this method's implementation to a utility function and write unit tests for this utility function.

Recommendation 6: Another hacky solution is building your classes as NSObject childs, and using Method Swizzling for testing purposes

As I mentioned above I don't know what is your exact situation, but Recommendation 1-2-3 are the correct solutions for a solid rock architecture. Others are just hacks that can save your day, but through your situation you can prefer to choose one of them.

For this decision I can offer you to check; if this is a one-time issue you can use a hacky solution. But if this a common situation that effects your applications architecture you should definitely use Recommendation 1-2-3.