I haven't been able to find any up to date info on using the OCUnit tests with Xcode 4, even though it is a redesigned feature.
Apples own documentation in the Organizer is from 2005 (OS X 10.3).
I thought I just go ahead and try set it up myself.
1: Made a new test target. (TestUnit)
2: Made sure all Base SDK settings in project and targets is set to iOS 4.3.
3: Added a test Class
4: Made sure the framework search path pointed to the framework folder
(4.1?) Manually added the SenTesting framework to my testTarget
When I set my scheme to the "TestUnit iOS 4.3 Simulator" and try and run it an error pop up says "The selected run destination is not valid for this action.".
I have no idea if the above is the correct way to add OCUnit testing to Xcode 4, so if someone has a resource or could point out the steps I would be grateful.
Thank you in advance.
In Xcode 4 'longpress' on the run button until a drop down comes out and select test.
The following steps worked for me to add unit testing to an iPhone project running in the simulator:
Add a Cocoa Touch Unit Testing target to the project. Adding the target added a unit testing class to the project.
Modify the application's scheme to run the unit tests. This involved adding the unit testing target to the Test step of the scheme. I used the application's scheme to unit test instead of the unit test scheme Xcode adds when you add the unit testing target.
Choose Product > Test.
You do not need to add the SenTesting framework to your project. Also, make sure the Test Host build setting is blank if you're unit testing an iPhone app running in the simulator. The simulator does not support application-hosted unit tests.
In addition, to avoid the "The selected run destination is not valid for this action" message when you are in the UnitTest target, open its Biuld scheme and select Run
Related
In the latest beta 6 of Xcode 12, I'm having errors popping up when trying to resume a SwiftUI preview. The main error appears to be Cannot find type 'ASAuthorizationAppleIDButton' in scope. The code compiles perfectly fine when building or running on the simulator, and no errors show up. Only when I try to run a preview do things not work. Other errors I see are:
Type 'SignInAppleButton' does not conform to protocol 'UIViewRepresentable'
Cannot find type 'ASAuthorizationControllerDelegate' in scope
Cannot find 'ASAuthorizationAppleIDProvider' in scope
Cannot find type 'ASAuthorization' in scope
I have import AuthenticationServices at the top of my files. An important note is that the same project works perfectly fine without any errors on Xcode 12 beta 1.
A short term solution I've found is to remove all code using ASAuth (subsequently Signin with Apple) and switching from Firebase CocoaPods to their new Firebase Swift package manager. This makes previews work. Prior to switching from CocoaPods, I would get strange linker errors after removing ASAuth code.
My assumption is that I need to implement SwiftUI's new Signin with Apple button, but I don't know how to use it based on the little documentation provided by Apple.
This is the site my code references almost exactly the same: https://www.alfianlosari.com/posts/building-authentication-in-swiftui-using-firebase-auth-sdk-and-sign-in-with-apple/
I am pretty new to CI/CD and mm currently struggling with getting VSTS to find my xUnit tests. My solution is a pure experiment, to try and isolate the problem and to learn. Before getting into my setup and what's been done so far, the result is this line in the VSTS build log:
Warning: No test is available in C:\agent\_work\1\s\Quotifier.Models.xUnit.Test\bin\Release\netcoreapp2.0\Quotifier.Models.xUnit.Test.dll. Make sure that installed test discoverers & executors, platform & framework version settings are appropriate and try again.
From having googled the message I interpret it as VSTS not being able to find an xUnit test adapter. Is that a correct assumption? Also, I see the terms "test adapter", "test runner" and "test explorer" alot. Are these terms the same thing? Having checked out this article it seems they are indeed the same thing. Can anyone clarify?
Now, for my setup ...
The xUnit test project is a .NET Core 2 class library referencing NUget packages xunit and xunit.runner.visualstudio (2.2.0). The test project is also referencing a shared class library called "Quotifier.Models" which contains the tested code.
To make it easier to diagnose I am running a local (on prem) build agent on my PC. This enables me to investigate the file structure.
The build step of my build definition was initially a "Visual Studio Build" that built the whole solution. I can see that the resulting binaries ends up in
C:\agent\_work\1\s\Quotifier.Models.xUnit.Test\bin\Release\netcoreapp2.0.
Among the binaries are also xunit.runner.visualstudio.dotnetcore.testadapter.dll. Is this the xUnit test adapter VSTS can't find?
More googling tells me that the typical place for the test adapter to be found is in the $(Build.SourcesDirectory)\packages folder and, so, that's what the test step's "Path to custom test adapters" should be set to. That gave me this log entry:
Warning: The path 'C:\agent\_work\1\s\packages' specified in the 'TestAdapterPath' does not contain any test adapters, provide a valid path and try again..
I also checked that local folder and, indeed, the xunit NUget packages does not end up in there. Can anyone guess as to why?
Assuming the xunit.runner.visualstudio.dotnetcore.testadapter.dll is indeed the test adapter VSTS is looking for, I thought I should try and help it a bit. So I created a seperate MSBuild step and specified the output path via the "MSBuild arguments":
/p:OutputPath="$(build.binariesdirectory)/$(BuildConfiguration)/test-assemblies".
I then set the test step's "Path to custom test adapters" property to point at that same folder. With that I'm back to the original warning in the log:
Warning: No test is available in C:\agent\_work\1\b\release\test-assemblies\Quotifier.Models.xUnit.Test.dll. Make sure that installed ... bla ... bla
Now, to summarize ...
running xUnit test projects out of the box doesn't work with VSTS
The xUnit NUget packages does not end up in the /**/packages folder
I am assuming the xunit.runner.visualstudio.dotnetcore.testadapter.dll is the test adapter needed. Is this assumtion correct?
I'm out of ideas for now so any hints, links or suggestions will be greatly appreciated.
Use "dotnet test" to run Your NetCore-UnitTests.
The task is called ".NET Core" and has a command dropdown where you select build/restore/test etc... You also need to add "NET Core Tool Installer" if you are using a hosted agent
And your xunit-packages are not supposed to end up in "packages"-directory. The netcore2 projects handle nuget-packages differently and will reference them from the local nuget-cache
I'm writing Robot Framework tests for a Plone project.
Here is the code.
I want tests to be executed on Sauce Labs, but with two different OS's:
iOS
Android
I'm starting by replacing the current default tests (Firefox / WinXP) with iOS, using the following parameters in my .travis.yml's matrix:
- TARGET=test ROBOT_DESIRED_CAPABILITIES="platform:OS X 10.8,browserName:iPad,version:6,tunnel-identifier:$TRAVIS_JOB_ID"
Tests are now failing with the following issues:
Could not proxy http://localhost:3001/wd/hub/session, exception: java.net.ConnectException: Connection refused
I have no idea why. I have read all the stuff in example.product and I didn't find any differences.
Here are my builds at Travis CI, which show the errors.
And you can find my Sauce Labs results here.
Currently, you have to run your test ZServer (by settings ZSERVER_PORT environment variable) at some port supported by Sauce Labs: https://saucelabs.com/docs/connect#localhost
I have a working example at: https://github.com/datakurre/example.product
I filed a request for SauceLabs to add support for port 55001 used by Plone, and the port will be included in the next SauceConnect-release.
Update: There was an another issue. p.a.robotframework defines Selenium version for Sauce Labs, currently 2.31.0 (UPDATE: next release will not set the default value). I asked this from Sauce Labs and it seems that selenium version should not be set for mobile tests at all.
I have now a working p.a.robotframework example at: https://github.com/datakurre/example.product/tree/p.a.robotframework
To reset Sauce Labs Selenium version set by p.a.robotframework, you could set an environment variable ROBOT_SELENIUM_VERSION=" " for mobile Travis builds as in https://github.com/datakurre/example.product/commit/4deafc843b89a66da8cf6a85955a2b936ada79b4
Technically ROBOT_SELENIUM_VERSION="" should be enough for p.a.robotframework to use the default Selenium version of Sauce Labs, but when I tested that in .travis.yml, Travis didn't set that environment variable at all and it didn't override p.a.robotframework's default. Anyway, the next p.a.robotframework-release (>= 0.6.2) will set no selenium-version for Sauce Labs by default.
Background:
Sauce Labs documentation related to Selenium version: https://saucelabs.com/docs/additional-config#selenium-version
p.a.robotframework code for defining SELENIUM_VERSION-variable for Robot Framework and forcing selenium-version Selenium desired capabilities string for Sauce Labs: https://github.com/plone/plone.app.robotframework/blob/master/src/plone/app/robotframework/saucelabs.robot#L25
Finally robotsuite, which is used used to wrap Robot Framework tests for zope.testrunner, passes all ROBOT_-prefixed environment variables for Robot Framework test runner without the prefix, effectively overriding the default set in p.a.robotframework.
I have created a new build definition for TFS 2010. After building my C# solution I would like it to execute a couple of unit tests. These unit tests require an XML input file, so I have a [DeploymentItem] attribute to the test methods which provides the relative path the XML files. If I run the unit tests from within Visual Studio they pass ok.
When the unit tests get run following a build (via my build definition), they fail with: "Microsoft.BizTalk.TestTools.BizTalkTestAssertFailException: Input file does not exist..."
It would be great if I could get to a trace of what the build agent was trying to do, to help with troubleshooting.
Does anyone know how to get such a trace output? I guess I could increase the verbosity of the trace output from the main solution under test but I don't think that would give me any indication of where the build agent was looking for the test input XML or why?
Thanks
Rob
I found it! Needed to click the "View Log" link from the screen that's displayed following the build. I had been looking at the default view of "View Summary"
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development.
(Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?).
(App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
For now, I combined QA and UAT. (This may be split later on.)
I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!