How to reduce the costs of tests of an cloud app? - ios

I want to build an IOS app (both iphone and ipad) which support iCloud and dropBox; And also I need to write tests for that.
How should I do that to reduce the cost of tests?
And is there any sample code in any language which would do that?

It depends what you are looking for. You can use a Continuous Integration tool like Jenkins that allow you to build and to test iOS applications. You can read this article which will give context about it. If you are looking for a cloud provider in order to reduce the costs because you don't want to buy a new infrastructure on your end, there is a provider which allow you to build/test iOS applications on the cloud. See here how you can do this.
If you just need a development environment for some time, maybe doesn't make sense to buy new infrastructure when you can rent a service for just the time you need it. You should consider what is your best choice.
You can also use Selenium as an option for your end-to-end tests.

Related

Is it advisable to host the core logic of a react native app in the cloud?

I am planning to build an iOS app with react native and I am super excited to do so.
Unfortunately the deadline is quite short, so I am considering to use an approach like this, which hosts the app bundle in the cloud for the production build of the application.
This may be beneficial, as an api will be build for the app and I could simply change the code of the deployed app if the api behaves otherwise than previously assumed.
As this seems like a good idea on first thought and I am quite sure it is a good idea in terms of testing and continuous delivery I am not sure if this works out in production and if the application will be accapted by apple.
So my question is if such an application would be approved by apple and if this kind of structure provides any problems on the users devices.
Yes, this tends to be good idea. Usually, application stores a lot of data (authentication, user data and so on) on it's own servers.

Multi-platform In-App-Purchase

How to go about designing a multi-platform app that offers In-App-Purchase?
I'm working with JUCE (Win/OSX/Lin/iOS/Andr).
I know that iOS allows IAP. So I'm guessing OSX also does. I would suspect Windows and Android also provide something similar. I doubt Linux provides anything as it is decentralised by nature.
So maybe I would have to write 4 separate IAP modules, and maintain 4 separate stores. Yuck! I don't want to do that. I recoil from duplication.
Is there any way to unify IAP across these different platforms?
The ideal solution would be single store to maintain, and a single C++ API to access it.
But is this even possible? I think Apple explicitly forbid any kind of store/monetising outside of their system. But http://soom.la/ seems to provide some work around for Unity3D.
The api will be same, but the platform specific functionality has to be separate. This way you have one repository and for a given platform build, pull the required code. Here is an example "Upload XML data to MySQL or NoSQL"

What's the basic difference in UIAutomation (Instruments) and PerfectoMobile Testing (iOS)

I am trying to find out if i can use UIAutomation (Instruments) for all my automation need. So far one of the show stopper i see is, UIAutomation is unable to switch the application while my application require to share a document between two application. Guys - What's the basic approach differentiation between UIAutomation & PefectoMobile.
BTW, I can switch between applications using Pefecto Mobile solution.
Thanks & Regards -
Perfecto Mobile is for testers that won't probably see the code, for example. They have access to devices that have the app/apps. From there, they will create automated scripts that will then perform almost the same thing as UI automation. The thing is that with UI Automation, you have to give accessibility to your elements in order to test something. I would say that UI Automation has a better performance overall. Think of it in this way:
UI Automation - Developers or persons that will have a closer relationship with the code.
Perfecto Mobile - Testers, that sometimes don't even know how iOS works internally. This is useful when you want to really separate things: developers develop, and testers test it.
Separating things is good, because a tester that never seen code, or how the app is suppose to work, gives a fresh perspective to the project. You can also argue that, normally, a tester ( a person that tests for living) will do a better job a testing than a developer.
I don't know anything about PerfectoMobile, but I can answer questions about UI Automation. UI Automation is just a tool, there is no service built behind it like it looks that PerfectoMobile provides. UI Automation comes as part of Apple's developer tools so you don't need to download or license anything else to use it. Once you have tests written in UI Automation, you can use a service like cisimple.com to run them in the cloud as part of a distributed continuous integration process, but that's not set up for you out of the box.
I've written some tutorials on UI Automation that might help you understand what it does so you can make you decision: http://cocoamanifest.net/articles/2011/05/uiautomation-an-introduction.html

Can BuildForge do what Hudson CI is currently doing?

I am looking for a comparison between IBM Build Forge (Rational) and Hudson CI.
At work we have full licenses for BuildForge but recently we started using Hudson for doing continuous integration and automating other tasks.
I used BuildForge very little and I would like to see if there are any special advantages of BuildForge over Hudson.
Also it would be very helpful to see a list of specific advantages of Hudson over BuildForge.
I not sure if it important or not, but I found interesting that Build Forge is not listed under continuous integration tools at wikipedia.
Thanks for bringing attention to the fact it was not on the wikipedia list of continuous integration applications. I have now added it. Build Forge has been a leader in providing continuous integration capabilities by use of it's SCM adapters for many, many years. Build Forge has a strength in supporting many platforms through its use of agents. These agents can run on Windows, Linux, AIX, Solaris, System Z, and many more -- they even give you the source code for the agents for free so you can compile it on just about any platform. The interface allows you to easily automate tasks that run sequentially or in parallel on one or multiple boxes. Selectors allow you to select a specific build server by host name or by criteria such as "any windows machine with 2gb of ram" from a pool of available agents. The entire process is fully auditable, utilizes role based permissions, and is stored in a central enterprise database such as DB2, Oracle, SQL Server, and others.
One of the most compelling reasons to use Build Forge is it's Rational Automation Framework for WebSphere. It allows a full integration into WebSphere environments to automate deployments and configurations of WebSphere through out of the box libraries. The full installation, patching, deployment of apps, and configuration of WAS and Portal can be performed using these libraries. To find out more, it is best to contact your IBM Rational representative.
You can use RAFW (IBM Rational Automation Framework for WebSphere) with BuildForge. It does not make sense to use RAFW with other ci servers, since RAFW requires BuildForge.
You have support for BuildForge and it integrates with other IBM software like ClearCase. Theoretically you have only to deal with one vendor if something in the chain does not work, but IBM has different support teams for their products and you might become their ping pong ball. :(
Hudson is open source (if you like that), that means you can get the source and modify it to serve you better. But the release cycle is very short (about 1 week, agile development). There is a more stable version with support available now (for cash of course) from the company of the main author of Hudson.
Hudson is currently main stream and is actively developed. I don't know how the usability of BuildForge is, but Hudson is good (not always perfect). The plugin concept of Hudson is a great plus, not sure if BuildForge has it as well.
Currently, we are using Hudson, but BuildForge was not looked at in detail.
You need to define what you would need continuous integration for (e.g. building, testing). Having used Hudson, I can vouch for its usefulness and effectiveness. There are many plugins that extend Hudson that can suit various needs. And you can't beat the price point (free).
You need to inquire as to why a BuildForge license was obtained at your place of employment. Perhaps someone on your team knows why this was done. If it isn't necessary for your needs, don't renew your BuildForge license and simply continue using Hudson.
Being a BuildForge/RAFW user, I have to object to one point stated above. It is perfectly possible to use RAFW without BuildForge. It is driven by a command line script, and you could use for example Hudson and RAFW together just fine.
A sample command would look like:
rafw.sh -e env -c cell -t was_common_configure_start_dmgr
The primary differentiators IMO:
Hudson/Jenkins is more readily extensible with the many existing plugins. It has a large active community and plenty information and documentation.
BuildForge can be configured with agents running on multiple machines and tasks can be assigned to run on a target agent. Reliable vendor support.

BDD and API calls you don't want to make during tests

I am working on a Rails app that allows you to create a configuration and then launch a server at EC2 with this configuration.
So far I've been using cucumber for BDD and was very happy with that. However, now I want to pick a configuration and actually launch the server. Due to cost and performance issues I don't want to actually launch a server every time I am running the cucumber features.
Are there any best practices for cases like this? I would like to keep the BDD up, but also don't want to spend too much time on working on an elaborate solution just to have feature descriptions for this. On the other hand I will have the same problems, when I will have to write Unit test for this.
When working on a rails app that required twitter integration, I found fakeweb to be extremely helpful. I've used it in conjunction with cucumber successfully.
I found that to support the BDD outside-in development style, I set fakeweb to disallow all web traffic and then added my faked-out web calls one at a time, as my tests failed. It seemed to fit right in with my BDD workflow.

Resources