TEST THE RISK!

If you are working on shell most of the time Aliases are very helpfull and time saving. For testing purposes you can use Alias for getting ready your test suites. In this post, I want to explain both running Selenium and Capybara on console and creating aliases for each.  This post is for Windows machines, if you are using Unix-like see   this post . Creating Scripts for Selenium and Capybara First of all, it is assumed that you have installed Selenium and Capybara correctly and they work on your machines. If you haven't installed, you can see my previous posts. I am using the Selenium with Python and the Capybara with Ruby. You can use several different language for Selenium but Capybara works only with Ruby.  Create scripts in a directory called scripts (in your home folder, like as  ~/scripts ) for your automation tool as following, save them as capybara.rb, sel.py :  Creating Aliases Depends on your favourite shell, you need to add the alias to .bashrc bash

I think the most challenging part of test automation is nowadays having Continuous Integration and one step more is having Continuous Deployment. These two terms have been a buzzwords around the software community, and everyone is talking about them but there are very few companies that can apply these. The reasons behind this can be listed as: Mis-understanding of agile and scrum Lack of "real" test engineers and Lack of Dev-ops culture  Lack of stable test environments  Lack of vision in the software industry, which saving the day is more critical than saving the future Out-of-budget, not investing on good people but investing in tools On the other hand, there are lots of open-source tools that you can just build and configure your own CI, and maybe next step goes to continuous deployment. In this post, I want to explain how you can set up CI on a Windows server. I will use the following tools/technology and language: Ruby, Gem (many Gems), Capybara, Cucumbe

I faced an selenium error like " stale element reference " when I changed Capybara's driver to Chrome which was not occurred in webkit and firefox. This error occurs when referencing an element which is not in DOM. Chrome gives this but it doesn't appear when I use Firefox because the dynamic object is appear after the Javascript execution finishes which means that Chrome doesn't wait until javascript execution ends .  You can escape this error by checking your scenario if there is an element requiring in the DOM which is destructed by an action in the scenario or if you have loop and the DOM is updating for each iteration the object you look for changes. However in  my case, scenario is passing with FF but not Chrome which because the Chrome is passing the next step as soon as Javascript execution starts.  I just call waiting function and then assign the variable. Finally scenario is passing for both browsers.        stale element reference: element is

One of the biggest challenge in test automation is updating existing codes. Because of the update in the development, it is very prone to have some changes for the attributes of ui elements and less likely to have some change in behaviour in actions. The second option is most of the time called as bug, otherwise if the business is changed, it could be called as a new feature. For any reasons that cause the automation code gives failures you need to update something. Sometimes I need to refresh my mind :) For easy maintenance, one of the good approach keep your codes modular. It means that each module should responsible for one job and a update problem should be solved by applying just one change in your system. Using Capybara plus Cucumber gives you this features but if you are using them professionally. For this framework, business rules are kept on Cucumber so you can update business rules from your .feature files but related update should reflect to the code. In thi

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

BDD, which is stand for behaviour driven development, is created by Dan North . BDD is developed on the top of TDD, which is stand for test driven development to remove the gap of unit testing and acceptance testing. In TDD, every unit is started to be written right after defining the expectations from the units, by the unit testing. However by BDD, regarding the agile story, every unit is specified and tested in terms of desired behaviour. This 'desired behaviour' is what exactly business requires in agile stories.  BDD can be applied by the help of some tools to interpret the business 'desired behaviour' to test code. There are some tools that help this aim such as Behat  for PHP, JBhave  for Java world, and the most famous one Cucumber  for the Ruby world. In this post I want to give some points on how to effectively we can use Cucumber for a Calabash project to automate some agile stories for sample android application. Cucumber takes some keywords lik

In my previous post I explained the Cucumber Capybara and Calabash and behaviour driven development. In this post I want to explain how we can implement and run cucumber and calabash for automating test cases for android applications. If you have not set-up your environment yet, you can read this post . You should also have an android virtual devices or a real devices that is connected to your computer in debugging mode. Your android version should be higher than 2.2.  If your system is ready for testing, you can clone the repository that I created for mobile test automation purposes. Sure, it may be more sophisticated if a real android developer develop something but from this application you can have a fresh starting. git clone https://github.com/gunesmes/calabash_android_automation.git You can check the images on the github so that get information what the application is looking like. Just open the project file and  look at the two important files in feature directory: cala

In Poltergeist mode or headless mode, it is different from Selenium since there is no browsers which you can track failure visually. The advantages of Poltergeist are: it is faster, it demands less source when we compare to Selenium, and eventually it is more suitable for Continues Integration (CI). Installation and further information about Poltergeist you can visit git page . Running Capybara with terminal may help you to get quick result. By this way you can check if button, field, or any object can be reachable easily and this method may help you to reduce failure issue on your CI and get you more realistic results. You can just paste the following commands into your terminal, it will go to home page of Amazon.

For any automation frameworks, handling pop-ups is somehow difficult. By opening a pop-up window, the window changes so you can not control the new window with existing webdriver since it is already assigned to main windows when it was initiated.  Normally automation framework can not work if you don't switch to pop-up windows. For Capybara you can easily handle it by assigning the webdriver to new pop-up window. Then you can perform your test case as same way what you have done and when you are done with the pop-up, close the pop-up and then switch back the webdriver to the main window.      main = page.driver.browser.window_handles.first     popup = page.driver.browser.window_handles.last     page.driver.browser.switch_to.window(popup) Since iframe is a part of another source which is used to display another webpage in a webpage, you must handle it exactly same  as pop-up windows.       page.driver. browser.switch_to.frame(iframe_name) However, for iframe you must

Testing the CSS of an object is sometimes needed. If you want to check the background-color, size, clip, ... of the objects, you must control the CSS code of the element. Capybara let you check it very easily with executing javascript from console by sending command to console of the browser. There are two function that can be used for sending command to console as follows: page.evaluate_script() page.execute_script() You can send your code as below. It tries to creates members object and then adds new profiles to members . With this way we can check if metrics of is shown as described format. # from javascript add 10 more user to the community and totally there should be 11 members # check the boundary, more button should be still not exit page.execute_script("window.members = App.Communities.models[0].attributes._members") for i in 1..number.to_i page.execute_script("members.add(new App.Models.Profile({_res:'profiles.#{i}'}))") end In th

Test automation scripts should be simple. This doesn't mean that software product code should be complex. Actually,when everything is simple then the life will be simpler. However sometimes we need to explain something in a complex way. Most of the time, simple is difficult. There may be different reasons behind the complexity but it is clear that if we knew it clearly, we would explain it simply. Let's look at what Albert Einstein says:  "If you can't explain it simply, you don't understand it well enough." As the subject is how simplicity can be applied to test automation, I will focus on simple but efficient test scripts. To enable to write simple test scripts, we must clarify undefined, non-clear, dependent factors on every case/stories. This kind of approach is called as determinism in philosophy. According to the Princeton University dictionary, determinism means as:  " determinism ((philosophy) a philosophical theory holding that al

When you write test scripts, you may want to get quick result if the entered command is working as what it is expected. The easiest way of controlling the command is to try it on simultaneously from your terminal. Using Capybara via terminal is very easy and fast.  Just copy and paste what is written in your env.rb file and see the result. However basically you can type the following lines after typing irb for Ruby execution window.  require 'capybara/dsl' include Capybara::DSL Capybara.default_driver = :selenium And then you can type your commands like as below, actually you can do what you are doing in your Ruby file:  irb(main):004:0> visit "http://www.amazon.com" irb(main):005:0> fill_in "twotabsearchtextbox", :with => "nexus 5" irb(main):006:0> find(:xpath, "//*[@class='nav-submit-input']").click()

Using Examples in Cucumber is a great thing for testing world! Examples is a keyword and you can define a set of variable to repeat your case with the whole set of data in the examples block.  We can re-write the examples which checks the login page of amazon.com with Examples feature of Cucumber. Check the following code: In the  amazon_login.feature file we are reading <username> , <password> and <message> variables from the Examples. This means that the scenario which has the steps used these variables will run 2 times, which is the number of row in the examples. There should some changing in the Capybara, Ruby file.  "(.*?)" this means the function takes a string parameter but we are sending table variable so we need to change  (.*) for string variable in table and  (\d+) for integer variable in table.     As you can see from the result there are  3 scenarios ( 3 passed) and 9 steps ( 9 passed) . This means that " Scen

For a company which uses agile development methodology, test automation is very critical. However meaning of test automation in agile is little bit different from the automation activities in waterfall or V-model development methodology. In agile a user story should be automated before the feature is developed and when it is ready then automated test cases can be run to test user stories. For agile test automation, using only selenium is not enough or is not the best approach because of the written test cases. There should be another tool used for writing test cases which automation script can understand and perform what test cases/user stories explain. Cucumber is the tool what I want to explain. With Cucumber we can write test cases and with language called Gherkin which is very easy and understandable for everyone. So we just need to learn the keywords like " Given, When, Then, Examples, Scenario, Scenario Outline , ..." they are not too many, for more information a