While I am running unit tests with XCTest in Swift, they run fine when code coverage is turned off. However once I try to enable code coverage, I have a failed build/test with 4 classes giving the following error message: Command failed due to signal: Segmentation fault: 11.
Here is what worked for me (as all the other suggestions did not work in my case). I was getting a segmentation fault 11 on a particular Swift class when trying to run unit tests with code coverage turned ON. It turns out that we had a ternary expression on a class's property like so:
let cellBorder : CGFloat = MyHelperClass.isIPad() ? 10.0 : 6.0
Making it a lazy var fixed the problem:
lazy var cellBorder : CGFloat = MyHelperClass.isIPad() ? 10.0 : 6.0
To be clear, the code compiled and worked fine until we tried turning on code coverage.
I also found this Open Radar and this guy's post that outlined the solution. Appears to be an Apple bug.
Without code, build settings, etc. it's hard to say for sure but one thing you should check is to make sure that you are using a #testable import flag in your unit test classes.
For instance with a project named MyApp at the top of your unit test class you would include with the following import #testable import MyApp.
You also want to check to ensure that you've followed the process for enabling coverage all the way through. That information is documented on Apple's developer portal:
Code Coverage | Apple Developer
See this bug report on similar issue. https://bugs.swift.org/plugins/servlet/mobile#issue/SR-1825
I got the same error when implementing a protocol which required an optional variable that I implemented as a lazy var.
In my case, i was building through the cli running the xcodebuild command with Release configuration and no provitionings configured, when i switched to Debug config build and tests worked just fine
Related
While I'm exploring Playground Book sample code, like this one, I find it to be very tedious to get the code to run because of Playground Book's limitations in where the code can run: only on iPad's Swift Playground.
There is no way to debug the "Sources" / Auxiliary code in iOS's Swift Playground, since all the source files are shown in un-editable plain text. You have to open the source files in Xcode to edit them, but then you can't compile or run them!
This is especially tedious for the sample code above, which uses PlaygroundValue, a persistence API that requires Playground Book format, so I still couldn't get the code to run by separating all source code into a separate Playground file to run on the Mac.
Since the sample code above is outdated, I find it to be near impossible to debug it right and get the code to run. You'd have to:
Deploy the code on iPad. Run the Book.
See many error messages on iPad.
Go back to Xcode on Mac and debug them one by one, manually.
Deploy the code on iPad again to run. Repeat the process.
Even after all the errors are resolved, you can still be faced with cryptic "Problem Running Playground" without any further concrete explanation.
What's your workflow to productively debug and deploy code with Playground Book? Current workflow seems impractical to me I think there must be a better way, but I'm not familiar enough with Playground Book and my online research doesn't yield any reasonable workarounds.
From a bug report / suggestion I sent to Apple, I got the following reply:
We’ve actually built tools to help debug the auxilliary sources and we did a presentation at WWDC 2018 that demonstrates it. Please view the presentation and get access to the tools here: https://developer.apple.com/videos/play/wwdc2018/413/
Upon further research, I found that they have recently released a Playgrounds Author Template:
The Swift Playgrounds Author Template is a starter Xcode project that will help you create, debug, and produce a Playground book. Using the template you can step through the code for your live view as if it were an app so that you can identify bugs more easily and develop an efficient workflow for developing your Playground books.
This template, requiring Swift 4.1 to run, includes three different targets:
PlaygroundBook
Book_Sources
LiveViewTestApp
You can use the LiveViewTestApp to fully debug your Playground Book right on your Mac with Xcode.
I am not aware of any possibility that does not require you to test the Playground on an actual iPad.
Anyway, you can make developing Swift Playgrounds less tedious by
Using iCloud to synchronize your mac version with the iPad.
Embedding your Playground in an Xcode project as described in one of my previous answers. That way, you can at least achieve autocompletion during development.
Linking your source files to another target, so that compile errors can be caught before running the Playground.
Anyway, you will still encounter mysterious "Problem Running Playground" errors from time to time
I'm trying to compile a project then the Xcode said that.
I hope to receive the answers for these concerns, here are the situation:
Xcode 8.3.2
Swift 3.0
All Frameworks are built via Carthage (Exclude Fabric & Crashlitics)
When I build in Debug configuration everything are ok, but when I change to configuration Release then the compile always failed.
I tried to change the Optimization Level to Fast, Single-File Optimization[-O] then the Xcode works well and I also can archive to ipa file.
I have some concerns, could you please review ?
+ How do I completely resolve this problem and keep the default Optimization Level value for configuration Release ?
+ If I change Optimization Level value to Fast, Single-File Optimization[-O], could I submit the binary file to App store review ? Does it violet Apple's tos ?
Thank you,
you can get this error when the compiler gets too confused about what's going on in your code. I noticed you have a number of what appear to be functions nested within functions. You might try commenting out some of that at a time to see if the error goes away. That way you can zero in on the problem area. You can't use breakpoints because it's a compile time error, not a run time error.
And it might be possible that you have used a custom frameworks so just remove that custom framework which shows error
I use XCode 7.2 and Swift 2.0, no extra pods for testing, just XCTestCase class. I don't have #testable import myApp and adding it doesn't fix my problem.
I have everything set up correctly to see code coverage for my Swift project (I have set it up following this post - How to use code coverage in Xcode 7? ).
And it works, when I run all tests (with Command-U). However, when I try to run a particular test class (e.g. CuriousUITests: XCTestCase) or a specific test (e.g. testMyFavouriteButton), the coverage shows as if none of the code is covered!
Why does that happen?
I want to be able to see code coverage when running just one test, so that after implementing a new test, I don't have to run all of my tests to see if it indeed does cover what I expected (It just takes too long to run them all).
Thanks for all your help!
da-na
I am running test cases in application with enabled code coverage data Xcode 7 Beta 2. But I am able to get only few files coverage data while my all test cases are running successfully.
Some files has covered all codes by unit test cases but still showing 3% code coverage.
For example:
This is the result of code coverage, as you can see on the right side, there is an info how many times these lines of code was called during tests. In this case - 0.
But...
here is a place in tests where we can see that this function was called indeed. How many times? oh... at least once. This number is delivered by info on the right side.
So the code above should be marked as called, and not be grayed out:-)
Can anyone explain this? Why does this happen?
IT WORKS.
Since Apple released #testable keyword to import your project into test target, you don't have to add your files to both target anymore:
So just remove every file from your test target:
Wherever you need access to your file from your test target just import your target using: #testable import MyApp
Do this for every file in your project.
Then code coverage will be working fine.
Read more from Swift 2 + Xcode 7: Unit Testing Access Made Easy!!!!
If you need to know how to work with code coverage read How to use code coverage in Xcode 7?
As #Gerd Castan mentioned earlier is: "So it appears to me that a tested method shows a coverage of 0 when there exists at least one target where this method is not tested."
Solution is simple. Do not let compiler think that this file is included in more that one target, instead import your module using #testable keyword.
I think I found out what XCTest coverage ist doing and it makes some sense:
My setup:
class1 compiled into target1
class2 compiled into target1 and into target2
Test setup:
import XCTest
#testable import target1
class MyTests: XCTestCase {
func testSomething() {
someMethodFromClass1()
someMethodFromClass2()
}
}
What I find is that class1 (compiled into target1) shows test coverage and class2 (compiled into target1 and into target2) shows no test coverage.
So it appears to me that a tested method shows a coverage of 0 when there exists at least one target where this method is not tested.
And this makes a lot of sense, because testing a method in a target doesn't say anything about how it behaves in a different target.
Apple wants us to test all targets.
Update
One more hint to back this theory:
go to the report navigator
and click on coverage.
If you have more than one target, you see your files grouped by target.
And if you have one file in two targets, you see your file twice.
If you have one file in both targets, the code coverage of this one file is shown for both targets. And (at least in my projects) one file has different blue lines in each target:
coverage in target 1:
coverage of same file in the same project in the same test run in target 2:
If you look at your test coverage in the source editor, apple has to decide which coverage it shows to you.
I think showing the target with the lowest coverage is the best apple can do in the source editor.
simple fix for a special case:
If your only second target is your test target: don't compile into your test target and use #testable import.
For all other cases you have to test each target.
I checked at Apple developers forums for the subject and after reading through various posts I guess I came across the solution.
In order for the thing to work it is necessary to:
Remove all your application source files from the test target
In your unit-test sources put #testable import <NameOfYourModule>
Re-build and re-run tests
I tested this out with my current project, and the results are much better.
Original solution recipe can be found at: http://natashatherobot.com/swift-2-xcode-7-unit-testing-access/
Also it seems that the functionality is a bit raw-ish, hence bugs possible, and Apple suggests submitting bug reports when things do not work as expected:
I've personally seen code coverage results for some very large projects. Right now the support works best for applications and frameworks. If that's what you're testing, then it would be best if you could file a bug report at https://bugreport.apple.com so that we can investigate your particular circumstances. For that matter, a bug report would be a good thing no matter what type of project you have. If possible, it's best to actually in the project with the report. If you can't do that, describe its setup in as much detail as possible. Pictures are good.
Original thread: https://forums.developer.apple.com/message/9733#9733
Bear in mind that there are multiple ways to cover code with tests, you may test all functions, or you may be covering all instructions in the functions, but you may not be covering all the execution paths that are possible.
Or Xcode coverage stuff may be broken, but it's hard to tell if you don't give details on what kind of coverage are you expecting it to check.
This happens because .swift file of your project selected for both targets by default.
Manually select and remove test target for files works for me.
I would like to create a library for iOS applications which uses UIKit. Furthermore I would like to create unit tests for this library. Unfortunately my tests do not work because of UIKit ([UIFont systemFontOfSize:12.0] to be precise).
According to Apple's Unit Testing Guide there are two types of test cases: logic tests and application tests. Application tests seem to be the correct type for tests involving UIKit related stuff but I did not find out about how to set up application tests for libraries. Has anybody ever had the same problem and was able to solve it?
Thanks a lot!
I found a solution to this. You must add a new target to your project that is simply an empty application. Then use that application as your test host following the instructions for doing this with a regular application like here:
Why does instantiating a UIFont in an iphone unit test cause a crash?