Skip to main content

Posts

Testing WEB Sevices and Automating SOAP Services

Web Services are server and client applications to interact with rest of the world over HTTP, or sometimes over SMTP. It is written for accepting requests and giving appropriate answers for each requests. It is assumed that it returns the same response if there is no changing in the request and the condition. Therefore testing and automating Web Services are very easy. You just need to know sending and receiving data and condition, then the rest of the jobs is playing with data and assertions. Information about the  Web Services  should be present in  Web Services  documentations and it should be understandable to the people from third party system.  Web applications take to the next step with the  Web Services  because you can open your system to rest of world without requiring language specific restrictions. This makes integrity of applications very easy. To be able to integrate two or more system, you just know that you are sending some data and receiving data.  I had a t

Page-Object Pattern for Selenium Test Automation with Python

Page-object model is a pattern that you can apply it to develop efficient automation framework. With the page-model, it is possible to minimize maintenance cost. Basically page-object means that your every page is inherited from a base class which includes basic functionalities for every page. If you have some new functionalities that every page should have, you can simple add it to the base class. Base class is like the following: In this part we are creating pages which are inherited from base page. Every page has its own functionalities written as python functions. Some functions return to a new page, it means that these functions leave the current page and produce a new page. You should write as much as functions you need in the assertion part because this is the only part you can use the webdriver functions to interact with web pages . This part can be evaluate as providing data to assertion part.   The last part is related to asserting your test cases against to the

Mobile Test Automation: Appium with Python Client

Appium is an open source tool for mobile test automation, you can automate functional test cases for Android and iOS application. As in my some previous posts, I explained Calabash and I just used Ruby for writing test cases because Calabash only supports Ruby and as I know they have plan to support Java. However Appium doesn't have this language constriction. Since it uses Webdriver, it supports the languages which are supported by Webdriver. It means that Java, Objective-C, PHP, Python, C#, Clojure, Perl, JavaScript with Node.js and plus Ruby are supported. You just install the language client you want to test and then write your test cases. Check for the client for your favourite languages from Appium page . Install Appium: npm install -g appium Install Appium Client: npm install wd Install Python Appium Client: pip install Appium-Python-Client Ensure that you have Python installed, recommend to have 2.7 or above: python --version Ensure that you have

Effective Testing: Using LOGCAT for Android Testing

If you tend to use tools effectively, testing is easy and enjoyable. For mobile testing there are lots of challenges and to be honest if you don't push yourself to improve your ability as every developer does you can not test the mobile application good enough. Instead of testing mobile application manually, we can automate the stories whenever the stories are prepared by business analyst with writing cucumber files and then we can start writing the code of automation and finally we can run it when the stories are developed by developer for agile development environment. This is iteration based approach, means you can repeat this steps for each iteration. At the end of the milestone you can run your whole automation code and see the result. For the remaining time you can still test application by using Exploratory Testing techniques to find-out any bugs.  The important point is to make your job effective and efficient. For this you should automate or scripted some repetiti

Fix for Calabash-android Run INSTRUMENTATION_FAILED exception

When you set-up a new android devices or update your .apk file, you may possible get INSTRUMENTATION_FAILED exception: android.util.AndroidException: INSTRUMENTATION_FAILED: com.package.name/sh.calaba.instrumentationbackend.CalabashInstrumentationTestRunner at com.android.commands.am.Am.runInstrument(Am.java:1093) at com.android.commands.am.Am.onRun(Am.java:371) at com.android.internal.os.BaseCommand.run(BaseCommand.java:47) at com.android.commands.am.Am.main(Am.java:100) at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method) at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:251) To fix this issue you can follow the instruction below: Create new folder Copy your .apk file into the newly created folder go to your newly created folder and run this command to create calabash-android project calabash-android gen run calabash-android via your new devices calabash-android run latest.apk features ADB_DEVICE_ARG=192.168.56.101:5555 resign .apk

Tools for Screenshot Comparison Testing: Huxley, Wraith, Selenium-Wraith

Testing the user interface (UI) testing may be the most difficult part of test automation. When we think from the perspective of users there are not hundreds but there may be thousands of different users' environment but it is clear that simulating and testing UI related cases for all possible users' environment is impossible! However we can cover easily the %80 of them by using statistical data taken from analytics tools as Pareto Analysis says 20% of reasons cause the %80 of all problem. If you are doing some kind of internet business, there are two important factors for user environments which are operating system and browsers for normal internet users.  Therefore analytic tools should give us feedback about operating system and versions of operating system; browsers and versions of browsers. To get a general trend we can look at the w3shcool.com statistic but sure it is more convenient to take your own statistic depends on your user profile. In general approach

Running Capybara Under Chrome, Poltergeist or Firefox

As a default Capybara runs under Firefox but if you want to change your driver you have to change your javascript driver to your new driver. But you also must define your driver as registered Capybara driver. For example if you want to run with Chrome and change your driver to chrome but not define it, it gives some errors like following irb(main):007:0> visit "http://www.amazon.com" Capybara::DriverNotFoundError: no driver called :chrome was found, available drivers: :rack_test, :selenium, :poltergeist from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/session.rb:77:in `driver' from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/session.rb:226:in `visit' from /Library/Ruby/Gems/2.0.0/gems/capybara-2.4.1/lib/capybara/dsl.rb:51:in `block (2 levels) in ' if you add the following line into your env.rb module, you will successfully run under Chrome driver. Capybara.register_driver :chrome do |app| Capybara::Selenium::Driver