Any frameworks available for writing test cases to Support iOS applications developed using Appcelerator Titanium?
There are quite a few frameworks for Unit Testing:
MockTi
Titanium-Jasmine
Ti-Mocha
Ti02
TiUnit
TiShadow
But the most of those frameworks listed above are either discontinued or don’t work anymore. And the frameworks that are still working mostly run in the Titanium container/runtime. This means the Titanium project needs to be build and run first which makes the execution process of your tests very slow. Besides that, most of them don’t provide mocking the Titanium namespace (e.g. manipulating/mocking Ti.Network).
We’re using the TiUnit toolset for our Unit Testing in combination with Istanbul (test/code coverage). TiUnit covers our needs within Unit Testing:
Fast and execution outside of the Titanium container/runtime
Mocking all dependencies (e.g. required CommonJS modules)
Generating a mock for all functions, constants and properties in the
Ti namespace (Ti)
Callback, L macro and $ testing
More information can be found on the TiUnit github page
We recommend ti-mocha (https://github.com/tonylukasavage/ti-mocha) which suited, test cases, supports asserts, skips, advanced validations and many more features.
Related
There are three basic layers of testing:
Unit test — making sure each function/unit of code works as expected
Functional test — making sure units interact with each other as expected
Integration test — making sure our app integrate with other app/api/services as expected
I can handle cases 1. and 2. using Xcode's iOS Unit Testing Bundle and iOS UI Testing Bundle I don't know how to write tests from point 3.
I would like to write to tests to check if me app correctly integrate with backend, BLE device, etc.
Note that I have already written unit tests which I run using CI.
Integration test should not be run in CI because it depends on external environment. I would like to run its only manually.
How to handle it in Xcode? Second Unit Testing Target? Any advice? How are you dealing with it in yours systems?
Depending on the style of integration test that you are after you may want to use dedicated a unit or UI tests target.
From your question I'm guessing the style you want to have leans towards black box testing with other real systems. If that's the case a dedicated UI tests target would do the job.
With UI tests you can do stuff like opening other apps on the device and test how your app interacts with them. For example, this post shows how to write a UI test that uses the Messages app to test Universal Links.
I'd reach for using a dedicated unit tests target only if you need to control part of the code in your app, for example stubbing network requests. But that doesn't really fit with the definition of integration test you have given.
How I do I automate Xamarin.iOS unit test project.
For Android, I found this link which worked fine.
https://developer.xamarin.com/guides/android/troubleshooting/questions/automate-android-nunit-test/
Is there any references like this for Xamarin.iOS too?
At the time of writing this, I don't believe what you'd like to do is possible. If I take your meaning, you'd probably like to say "Run All" with some test runner (presumably in XS or VS) and then get the results immediately, but that's not how it works with Xamarin.iOS. I'm sure you've already glanced at Xamarin's iOS testing quick-start, but if not here that is.
You have to set up a Unit Test app that uses the Touch.Unit framework, fire up the test app, and "touch" the tests you'd like to run. My experience doing this has not been so great. The runner itself seems buggy and you're limited with in what other tools you can use (e.g., mocking frameworks won't work, assertions made with Shouldly won't register). I guess it's better than nothing, though!
I have used Appium in Mobile automation with IOS and Android. I wanted to know about advantages that offers Calabash and if there are common point in generated scripts of both tools?
I have followed this link : Appium VS Calabash
I have hands on in mobile automation quite a long time. let me tell my point of view on both tools.
both also have advantage and disadvantage find below:
I have used calabash and appium both for automation. Appium has more advantages than calabash.
Advantages of Appium over Calabash:
1. You can write your code in multiple language like Java,Python, C#, php etc. However, Calabash restrict to use RUBY only.
Appium comes with many predefined methods such as OpenNotification(), StartActivity(), InstallApp etc. Calabash does not provide such predefined methods.
Appium set up is very easy as compared to Calabash.
In calabash, it installs the app on the device every time you run the test. However, In appium you have a feature where in you don't need to install the app every time. It works with previously installed app on the device.
Appium works with both native and hybrid app.
There are many advantages of appium. I hope this helps.
Try them both for yourself.
I found calabash easier to get started. I had a complete user flow test working from setup to working test in Calabash in half the time it took for Appium.
I don't like using xpath. It makes tests brittle and subject to breakage if something in the layout changes. Appium requires mainly the use of xpath. Calabash allows you to drive actions and interactions through the selection of elements by their text . I prefer this because that same text is normally in the designs and/or requirements.
Some comments in other posts are not accurate. Calabash does not require the install of the app every time unless you don't look beyond the surface. There is a simple means to enable/disable it. I have logic that runs either way based on passing an argument. Calabash has more than enough existing methods to interact with your app. It has a built in debug that allows you to tinker with element interaction and those same calls can be copied and reused in your test code. Using it with getgauge.io provides reporting akin to the built in Cucumber but is easier to run multi-threaded and easier to write your feature/spec files.
Be fair to both tools and yourself. Create a simple project in each and try for yourself. Don't make a decision solely based on someone else's opinion.
There is no common part in the automation scripts since Calabash uses query for interacting elements but Appium uses selenium find functions.
The best part of the Calabash is that you can use cross-platform frameworks for automating ios and android application with same feature file and most part of automation code. However the worst part is that Calabash is Ruby only.
Look at this post for more details about the differences of Calabash and Appium.
Since you have already read the differnces , Few things to note that Calabash can also be used with Xamarin which is also a good tool to test hybrid apps and you can run the same script for ios and android apps with some minor changes.Also it has been now integrated into visual studio,so microsoft support is inevitable and some users might feel comfort factor.Lambda expressions are also a plus.A major setback with the Calabash however that it only uses ruby.
Appium on the other hand can support various languages which is plus and you can use webdriver as well.However it struggles with hybrid apps but you can overcome that functionality by using google chrome mobile view to find coordinates to click.one thing for sure is that sause labs have many bugs to fix in Appium yet.
I've got an Erlang project comprising a bunch of different applications. I'm using Common Test to do some of the testing.
apps/foo/suites/foo_SUITE.erl
apps/bar/suites/bar_SUITE.erl
I'm starting to see duplication of utility code in those suites.
Where should I put my utility code so that it can be shared between the two suites?
I've considered adding another application:
apps/test_stuff
...but I can't make the CT suites depend on this without making the application under test depend on this (or can I?). I don't want to do that, because test_stuff is only needed when testing.
I have a similar problem with my eunit tests, both between applications (apps/foo/test vs. apps/bar/test), and where I'm using similar functionality between the eunit and CT tests in the same application (apps/bar/suites vs apps/bar/test). Can I use the same solution for this case as well? Or do I need to ask another question about that?
Do you think ct:require/1,2 could help you so that foo and bar SUITE would require test_stuff before it gets executed? For more information http://www.erlang.org/doc/man/ct.html#require-1
It depends on how you are packaging your final releases. For example, I use rebar for relase management. I have Cowboy fetched along with other dependencies for testing purposes, but in my reltool.config, I omit it, so it doesn't get packaged with the final product. I use rebar to run Common Test, and it's able to add Cowboy to the path without having it bundled as a lib with everything else or added as a dependency to the app I'm testing.
However, if you have another process which infers your release configuration from your dependencies, you'll have to find a way to exclude your test code when you generate a release.
I would like to perform the following iPad/iPhone testing scenario automatically:
Tap Edit box A
Type text "abcd"
Verify button B is high-lightened
I understand UIAutomation 4.0 allow you to write a simple JavaScript to perform the above steps. However, UIAutomation does not have test infrastructure ready. For example it lacks testing macros to show if any tests failed and does not have a clear way to run setup and shutdown for each test cases.
That is why I look back to XCode unit testing. Logic tests won't work for me. How about Application tests?
Basically, I am looking for something that can do GUI testing and at the same time has test infrastructure. It is even better if it can be integrated to continuous build environment.
Check out Zucchini. It's just come out and I saw a demo at a recent YOW! conference. It's basically a BDD testing framework that uses coffeescript for scripting and runs against an actual device. It's also fully runnable from CI servers which makes it perfect for agile teams.
I haven't run it myself yet, but it seems to exactly what I'm looking for and No I don't work for PlayUp :-)