I am using the Rhomobile framework to develop an application that is supposed to run on different mobile phones. The tutorial mentions how to write tests for the example model: Person. In fact, the framework provides a command-line tool rhogen spec to generate the dummy tests for the models. How would I go about writing tests for the controller class: PersonController? I was thinking of something similar to how one would do it in Rails, but rspec is unknown to me, and the methods post and redirect_to doesn't seem to work.
In BDD when you want to specify the behavior of the application (this is what controllers are responsible for) - you would normally aproach that with a StoryBDD framework - use for example Cucumber . Rspec is SpecBDD and regards a different level of abstraction - it is for specifying how classess communicate with each other and what they do.
You can find many tutorials on Cucumber's github page. This one could be helpful
Related
Problem Statement: Being in Test Automation arena for quite some time, I always ran into this puzzle of how to design one integrated Test Strategy to run automated scripts across all the 3 UI layers which most latest apps support
Mobile App - Hybrid
Wed App - accessed through browsers
Desktop Apps
More Details
Any modern application supports all the above listed platforms and their are diverse tools to test each platform
Desktop - QTP, AutoIt libraries ....
Web - Selenium and selenium extensions like Protractor so on, QTP ...
Mobile App - Appium so on ..
But how do we design an effective Test Automation Framework which will involve writing the functional test case flow at one place - language agnostic and make it work across any platform that we want to execute on?
I have summarized my work so far as an answer below. Please feel free to throw around any ideas !!
The best way to achieve this as per my analysis is to write language agnostic cases in BDD Style using Cucumber and have separate implementations based on the platform the tests need to run
I have summarized the complete architecture below.I have named it Panacea Framework :) I have blogged low level details here
As noted above, you can use Cucumber for writing your tests - it has versions for Ruby, Java, JavaScript, and many other language flavors. The Cucumber/BDD approach does give you high-level language independence for the Cucumber Scenarios, but you still have to write your step definitions in your language of choice.
The Cucumber framework can run tests against any application: mobile app, mobile web, or desktop applications, regardless of the language those applications are written in (we use ruby/cucumber with various plugins to test across all three).
The support elements of Cucumber will need some customization for any broad-reaching framework (env, hooks, etc.) so that you can get good reports and make things as easy as possible for testing, but the basics are already there.
You'll need support for actually driving the tests at the low level (i.e., making clicks, swipes, etc. work): that would be selenium-webdriver, or Watir if you prefer. There may well be other approaches. There are language-specific plugins for Selenium, so for ruby, you just add the selenium-webdriver gem.
All tests can be run locally (I have implemented a series of shell scripts/functions to make this easy). Then you can use Jenkins to run Basic Acceptance Tests on a regular basis, and also for automating the CI Pipeline.
In addition, you can use Appium and friends to automate your tests across Apple and Android with simulators or using real devices.
It's all open-source which is nice (if you like that sort of thing) and it meets your criteria. Most importantly its available now (and it works for us).
design one integrated Test Strategy to run automated scripts across all the 3 UI
BDD is not intended to be 1 to 1 with your test code implementation, otherwise, the business team won't take ownership. Instead, link an identifier using spec/test properties to match up tests to the BDD definition.
You need page objects to be as compositional as they exist in the real application. This allows developers to create derivative tests (positive/negative) testing than just having a bag of helpers. Example: a view contains 1 or more components, so, a feature spec could look like:
web desktop:
it('', () => {
// protractor sample:
const view = new View();
const sidebar = await view.newRecord();
const apiresult = sidebar.save({neverset: true});
apiresult.then((data) => fail('expected bad request not a 200 from api.'), () => {});
}
hybrid (media queries):
If you are building a hybrid app define multiple configs for chromeOptions { args: ['--window-size=1920x1080'] } so you can test your various media query stock sizes.
native + desktop:
I would put my bet on the webdriver protocol, https://www.w3.org/TR/webdriver/#privacy , to be the magic sauce you are looking for. Chrome browser or some mobile simulator will interpret the protocol to actions inside the mobile simulator. Checkout how electron uses the webdriver protocol to test a desktop app: http://electron.atom.io/docs/tutorial/using-selenium-and-webdriver/#setting-up-with-webdriverjs
In either of the interface viz., Web App or Mobile App or Desktop(Standalone App), the main bottleneck is the maintenance effort if not designed properly.
I would use Page Object Pattern and maintain page classes and abstract the behaviour of the app from Tests.This way it makes my work easy.
Separation Of Concerns. Single Responsibility Principle.
I am working on my first MVVMCross application and I am trying to set up a good testing framework. I have looked at the testing Stuart is doing in his TwitterSearch app but I have found nothing that explains his approach or any other approach to testing MVVMCross. Has anyone come across a good post/tutorial on the proper way to test an MVVMCross application? Other than just code that a newb (like myself) may not completely understand...
I'm not sure what you are asking...
What do you mean by a 'proper way'?
Is this a question about mechanics of "how to write a unit test?" Or a question about "how many unit tests to write; Which components to test; How deep to go; etc?"
For the mechanics:
I personally use NUnit for testing (from NuGet)
I include this in a .net4.5 class library project.
I use Moq for most of my Mocking (from NuGet)
There are a few MvvmCross objects I manually mock - as shown in that TwitterSearch message
There's an MvvmCross base test class which provides IoC/ServiceLocation - but I generally only use this when I need to use real MvvmCross classes - e.g. when the class under test inherits from MvxViewModel
I only run tests within Resharper in Visual Studio
There are plenty of other approaches, including some people choose to run tests on devices - e.g. using the excellent MonoTouch Nunit test runner.
There are also plenty of people interested in BDD testing - e.g. things like Frank, Calabash (coming in Xamarin Test Cloud) and the Windows Phone Test Framework that I wrote - https://github.com/Expensify/WindowsPhoneTestFramework :)
For the philosophy, I have no strong opinion, but I like this answer:
https://stackoverflow.com/a/153565/373321
I too get paid to write code
I am building my first iPhone app, and I want to get started with unit testing.
Been reading up on it and there are two sides to it. logictests and applicationtest.
logictest seems to me like regular unit testing.
applicationtesting sounds to me like gui-interaction testing.
Is that correct? Should i do both or is logictest sufficient?
I am considering just testing CRUD operations of objects in my logictest
I find Apple's distinction artificial and limiting. By using a different test framework (GTM in my case, or you might try GHUnit) you can just write tests without asking yourself, "Where does this test belong?" I write tests against view controllers that are not interaction tests.
I'm writing my first OS X Objective-C framework, but I do not know how to test it. How can I execute methods and classes in framework for testing purposes?
Chris Hanson's excellent set of articles on setting up unit testing for Frameworks in Xcode is a wonderful reference for testing frameworks. Their content has been largely incorporated (and supplanted) by the article, Automated Unit Testing with
Xcode 3 and Objective-C, on Apples' Dev site.
Make a unit test bundle target, and create test case classes in that bundle. You'll link against the OCUnit framework to get the base classes for your tests; there are a few OCUnit tutorials around, which you can find on Google.
For harder-to-test tasks, such as drawing in views, the easiest way is to make a test app and check the results yourself.
You can find several articles about unit testing on the blog of Chris Hanson.
One possibility would be to create a new executable target that depends on and calls the framework you're using.
What frameworks exist to unit test Objective-C code? I would like a framework that integrates nicely with Apple Xcode.
Xcode includes XCTest, which is similar to OCUnit, an Objective-C unit testing framework, and has full support for running XCTest-based unit tests as part of your project's build process. Xcode's unit testing support is described in the Xcode Overview: Using Unit Tests.
Back in the Xcode 2 days, I wrote a series of weblog posts about how to perform some common tasks with Xcode unit testing:
Unit testing Cocoa frameworks
Debugging Cocoa framework unit tests
Unit testing Cocoa applications
Debugging Cocoa application unit tests
Despite using OCUnit rather than XCTest, the concepts are largely the same.
Finally, I also wrote a few posts on how to write tests for Cocoa user interfaces; the way Cocoa is structured makes it relatively straightforward, because you don't have to spin an event loop or anything like that in most cases.
Trust, but verify.
Unit testing Cocoa user interfaces: Target-Action
Unit testing Cocoa user interfaces: Cocoa Bindings
This makes it possible to do test-driven development for not just your model-level code but also your controller-level and even view-level code.
Check out GHUnit by Gabriel Handford:
"The goals of GHUnit are:
Runs unit tests within XCode, allowing
you to fully utilize the XCode
Debugger. A simple GUI to help you
visualize your tests. Show stack
traces. Be installable as a framework
(for Cocoa apps) with a simple (or
not) target setup; or easy to package
into your iPhone project."
I started using the Google toolbox testing rig for iPhone, and its working out great for me.
google-toolbox-for-mac
Check out OCUnit. Apple's developer network has a great introduction.
Note that the Google Toolbox for Mac (GTM) project simply extends/augments Apple's SenTestingKit framework (which is, itself based on OCUnit). As they say on the project site:
GTM has several enhancement to the
standard SenTestingKit allowing you to
do UI unit testing, automated binding
unit testing, log tracking, and unit
testing on the iPhone, as well as
tools for doing static and dynamic
testing of your code.
Note the following comment about user-interface testing:
GTM has extensive support for user
interface unit tests. It supports
testing both the imaging and/or
internal state of almost all of the
standard Cocoa/UIKit UI objects, and
makes it easy for you to extend this
support to your own UI objects.
See their "Code Verification and Unit Testing" page for instructions on how to use it.
I came to the conclusion that GHUnit is the most advanced testing framework for Objective-C. I have done a roundup of testing frameworks on my blog. It is the most flexible in terms of deployment (iphone, simulator or mac os native) and assert capabilities. Because it is based on GTM, it inherits all of GTM's advantages over SenTestingKit but also adds a lot more. Another bonus is that it is being maintained very actively.
I have conducted effort to integrate OCMock into GHUnit, it works great!. You can get the code on github.
I realize this is an old question, but if you prefer BDD-style testing (rspec, Jasmine, etc.) over xUnit-style testing (Test::Unit, JSUnit, JUnit, etc.), then you may consider checking out Cedar. Cedar brings BDD-style testing to Objective-C, now that the language supports closures.
We're happily using Cedar for our iOS projects at Pivotal Labs, and we're actively working on improving it. Any feedback or suggestions are welcome at cedar-discuss#googlegroups.com
I would also recommend using coverage tools to see which part of the code are covered with unit tests and which are not. Basic line and branch code coverage can be generated with the GCOV tool. If you want to generate nice HTML coverage reports there are LCOV and ZCOV which do just that.
I recommend gh-unit, it has a nice GUI for test results.
http://github.com/gabriel/gh-unit/tree/master
The Unit Testing support bundled within xcode (for its simple setup) combined with ocrunner (for some autotest/Growl goodness) is currently my favorite Obj-C Unit Testing setup.
here is a whole lot of them
List_of_unit_testing_frameworks in Objective-C
Sen:te (the creator of the testing framework included with Xcode) explains how to use OCUnit with an iPhone project: simple-iphone-ipad-unit-test.
Matt Gallagher of Cocoa with Love has a very good article on unit testing.
I would suggest looking into Kiwi, an open source BDD testing framework for iOS:
Kiwi
Check out the project's WIKI to start or get Daniel Steinberg's book "Test Driving iOS Development with Kiwi"
test-driving-ios-development
I use SimpleUnitTest works with iPhone and iPad libs.
http://cbess.blogspot.com/2010/05/simple-iphone-ipad-unit-test.html
It comes with a unit test Xcode template to easily add a unit test class. Wraps GTM.
You can literally drop it into an active project and start adding unit tests within 3 minutes (or less).
Specta is a modern TDD(Test Driven Development)/BDD(Behavior Driven Development) framework which runs on top of XCTest. It supports unit testing for iOS and Mac OS X projects.
I hope u can use 'SenTestKit', from which u can test each and every method.