Tests for static libraries #5
Comments
|
Hi Drew, With xctool, you shouldn't have to pass TEST_AFTER_BUILD=1 anymore. It doesn't use any of the Instead you should just be able to do something like... Let me know if this doesn't work.... |
That's why I opened the issue :-) Maybe a formal bug report would clear it up? Reproduction stepsgit clone git@github.com:drewcrawford/DoesThisRun.git
cd DoesThisRun
bash /path/to/xctool.sh -project DoesThisRun.xcodeproj -scheme DoesThisRun -sdk iphonesimulator build testExpected resultsFailure of test: testExample Actual results |
|
Thanks for the repro case! This part looks suspicious... It should be installing the TEST_HOST app. |
|
I think it's because I have TEST_HOST set to BUNDLE_LOADER which is set to library's |
|
I was having the same issue. Updating to 0.1.2 fixed it. Thanks! |
|
I'm still hitting this in 0.1.7 As in #114, this is accompanied by a crash when passing the -freshInstall option. I've also tried switching the targets in the project and in the scheme so the test target is first, thinking xctool would pick it up as the install/uninstall entity, but to no avail. Thanks. |
|
The workaround suggested by @drewcrawford works for me as well. However, this really just a work around, since this is not the way xctool is expected to work. In my case, after applying the workaround, I can trigger the test by forcing a build of the test target (this moves the running of the tests from the test execution phase to the test target build phase): |
|
I just wanted to go on record, since I originally opened this issue, that the vanilla "xcodebuild test" command from Apple works great after upgrading to [REDACTED]. It doesn't have all the logging bells and whistles that xctool does, but I don't really need those. My advice is that if you actually want to test like the Xcode GUI test button does, upgrade to [REDACTED] and use the official CLI. If xctool's logging output is desired then it might be convenient to write a log parser that prints pretty colors, but I have no real plans to use xctool now. |
|
@drewcrawford I went back and tried the DoesThisRun example with the latest xctool, and it worked just fine. Output: https://gist.github.com/fpotter/6419671ab22a43cb5a76 xctool definitely does support testing static library projects. In fact, this was the test case I used most often during development. I noticed in your example output that xctool was trying to run You mentioned setting TEST_HOST or BUNDLE_LOADER settings to the lib's .a - I do know that won't work. The TEST_HOST is an app that gets launched and that your test bundle gets loaded into. Since we can't launch or install a .a, it makes sense that this would break in xctool. In Xcode, I noticed it works without error, but I think Xcode is just intelligently skipping over it. When I did set TEST_HOST and BUNDLE_LOADER to the .a in DoesThisRun, xctool failed exactly how you describe. We need better error messages here. Going to close since I think I understand the problem now. Will open a separate issue to add better error messages. |
|
Confirmed. GREAT! |
…d-error-to-system-out to master * commit '5487abb901dabc755161a13d28dc88fc9d76efd0': Append the failure error to system out
It seems that tests for static libraries aren't supported. xctool currently outputs
If you pass
TEST_AFTER_BUILD=1you getI currently work around this issue by modifying the "Run Script" phase of the test target in the following way:
and then passing the argument RUN_TESTS_WITH_IOS_SIM=YES.
Note that this workaround uses several completely undocumented SDK tools. I have reverse-engineered them enough to find the correct arguments, but I have no idea how stable this is for future SDKs.
The text was updated successfully, but these errors were encountered: