Skip to main content

Posts

Marionette Web driver and STF

If you were also stuck with Firefox 47 and Selenium 2.53 issue then this is right time to start experimenting with Marionette.   But Before delving into Marionette, let’s see what a web browser engine is. Web browser engine is a program which renders markup content (i.e. html, xml, images etc) and the format information (i.e. css, xsl etc). It is also known as layout or rendering engine. In simple words, web browser engine is responsible for how you are able to see a web page in a browser, email client or e-book reader. Some of the most popular web browser engines are - Webkit which is used in safari and chrome browsers Gecko used in Firefox, Thunderbird email client Marionette is WebDriver version for Mozilla’s Gecko engine. It can control both the browser (menu, function etc) also known as chrome (don’t confuse with google chrome browser ;-)) and the content within the browser (something which is of immense value for test automation). Marionette also follow...

Selenium Browser Testing with TestingBot

TestingBot is an online service which provides a Selenium Grid in the cloud. By utilizing TestingBot, you have immediate access to over 600 browser and device combinations  to run both Automated Selenium and Manual tests. Ranging from IE6 to Chrome dev builds, from Windows XP to Windows 10 and macOS Sierra. Instead of setting up and maintaining your own Selenium Grid with all possible browser combinations, you can rely on TestingBot to provide you with an extensive Selenium grid of both older and new browser versions. Because of this large Selenium Grid, you can easily run multiple tests simultaneously. For example; you can run the same test simultaneously on 40 different browser combinations, or run 40 different tests all on the same browser at once. This means your total test duration shortens dramatically, giving you early test feedback. Running Appium tests is also possible. TestingBot provides iOS Simulators and Android emulators to run your Appium tests. ...

Executing appium tests on iOS mobile app

Back to Appium Tutorial Index Assuming that you have completed installation of xCode and appium on OSx. Download iphone the sample app and unzip it Stop Appium app if it is running - Open iOS settings on appium app and specify > App Path, Force Device (if you need to), Platform version as following - Now appium is ready to install app on iPhone 6- Click the Inspector button > It would launch inspector and open given app on iPhone 6. You can click on any element and appium inspector would show corresponding details. This information can be used to build element locators for tests - You can also record use and throw scripts using Record button and modify it to develop production ready script Now you are ready to test sample ios app tests specified in testng.xml :)

Executing appium tests on iOS mobile web

Back to Appium Tutorial Index   To be able to work with ios simulator we would need - Appium app to launch appium server and analyze application elements xCode to launch various simulators to run tests on emulator / or real devices Let’s begin with Appium app installation on mac - Appium app provides ready to run version of appium server. Install appium client and start appium server as described in following steps - Install latest Appium client for ios from - http://appium.io/downloads.html (You may have issues downloading this file from chrome, FF seems to work without issues) Once download is over then Control-click appium.dmg > open with > DiskImageMounter.app DMG is a apple disk image. The disk image will be mounted. Then look for the mounted disk image in your finder (cmd + space), It will appear there. Right click and open. You should also drag it to Applications folder so that you can search it in finder (command + tab) in fu...

Executing appium tests on android mobile app

Back to Appium Tutorial Index Having learned how to execute appium tests on android mobile web now is the time to learn how appium tests can be executed on mobile app. Lets begin with installing app on emulator or device - Installing app on emulator/device: Following are the steps to install app on emulator or device on various operating systems - Windows: Execute the emulator (SDK Manager.exe->Tools->Manage AVDs...->New then Start) Start the console (Windows XP), Run -> type cmd, and move to the platform-tools folder of SDK directory. Paste the APK file in the 'android-sdk\tools' or 'platform-tools' folder. Then type the following command. adb install [.apk path] Example: adb install C:\Users\Name\MyProject\build\Jorgesys.apk Linux: Copy the apk file to platform-tools in android-sdk linux folder. Open Terminal and navigate to platform-tools folder in android-sdk. Then Execute this command - ./adb insta...

Where is my default Test Data

Importance of test data can not be emphasized enough whether we are writing automated or manual tests. With automated test we often deal with data objects. Data object is an object which encapsulates properties of data dealing with object. For example username and password could be encapsulated in to Credential object and passed on to required test methods. But many a times we require default test data which can be used to facilitate system under test reach certain stage. How do we provide such default test data so that it is readily available for use? One way to deal with this is to use constructor on data object class which would initialize the data object with default data. In the following example TeamAttributes data object is initialized with default values - Of course default values can also be read from a property file instead of being hardcoded as above :-) And now if any of your test want to use default data then they can just instantiate data object class as- ...

Where is my defect ID?

Don't you feel ecstatic when your automated tests find bug? After all tests finding bugs give us a sense of accomplishment, is not it? And this is followed by usual cycle of defect reporting, retesting and hopefully closure of defect. But at times defects are deferred to next or future releases. Which causes test method to fail for subsequent releases. And if you are dealing with a test suite having 100s of tests then it may become difficult to remember if there was a defect reported for a failing test? How do you deal with such situation. How about adding defect-id to @description tag of TestNG test. Hence it is reported on automated test report and we would know if defect exists for a failing test - How do you track defect-id of a failing test?