I ran into the most puzzling issue this past week. While working with the new MMDrawerController package on Github (written by some friends here at Mutual Mobile), I ran into a situation where the test runtime believes that there are 2 separate classes, both named “MMDrawerBarButtonItem”.
The failing source code for the project is on Github in WhosWorkingOnWhat at commit c19a6a7de5cda609c75b70d93aed91687fdfcf00. You can uncomment the code in that commit to see that the log shows that there are 2 subclasses of UIBarButtonItem with the same name “MMDrawerBarButtonItem”.
What’s happening in testNavBarLeftButton is that the code under test assigning an instance of one class named “MMDrawerBarButtonItem” to the leftBarButtonItem. The test is then trying to confirm that an instance of the correct class has been assigned to the left button, but when the test compares it with [MMDrawerBarButtonItem class], it is getting the second class with that name, and therefore failing the assertion!
This is a most peculiar bug, and so far has me completely stumped. Any ideas on how my tests are managing to create 2 classes with the same name?
Last week one of the senior iOS engineers ran into a similar problem on his project, and determined the cause and a workaround. The problem is caused by the combination of CocoaPods and OCUnit Application tests.
CocoaPods was used to add a 3rd party library. In my case, it is MMDrawerController, in his it was something else. Then in order to test code that interacts with that 3rd party library, the Podfile was updated to add the same library to the unit test target. And voila, when tests are run, 2 instances of the classes in the 3rd party library will exist in the combined product code + unit test code test target.
Normally the compiler and linker would detect this duplication, but no errors are generated when the duplicates exists separately in the product target and the unit test target, which then get combined when running the unit tests.
My workaround was to simply stop using CocoaPods. My friends solution involved putting dependencies into a separate static library. There’s probably a better solution, and I’ll update this when it is identified.