Pythons equivalent to pry

Since using Ruby the pry gem has always been the first to be added to any of my gemfiles. It was very useful when getting to grips with ruby and also invaluable when it came to debugging.

Recently I started a project which uses Python in its testing stack, being new to python the first thing I googled was “pythons alternative to pry”. A few different options are available but the one I went for and am still using is ipdb. https://pypi.python.org/pypi/ipdb

So how do you use ipdb? Firstly we must install the package using pip (package management system)

$ pip install ipdb

Now set a breakpoint, insert the following into the code where you would like to access the interactive shell and start debugging.

$ import ipdb; ipdb.set_trace()

Once the script has hit this line of code you can start inspecting. Some useful commands to note when inside the shell :

list (list the 11 lines of code surrounding your breakpoint)
n (next: continues execution, executes the current statement)
s (step:execute and step into function)
c (continue: continue to the next breakpoint)

More commands are available and there are plenty of ipdb cheatsheets that can be found online.

I predominately  use python to aide my testing; two packages I use a lot to assist with the creation of automated checks are pytest and behave. If you intend to use ipdb with these packages you must turn off the capture output, this needs to be set at execution:

$ pytest tests/tests_one.py -s
$ behave tests/features/feature_one.feature --no-capture

I am a big fan of sublime and adding a code snippet for ipdb saves you having to type the set_trace() function over and over. Add the following code to a new snippit in sublime and save as ipdb.sublime-snippet.

 <snippet>
 <content><![CDATA[import ipdb; ipdb.set_trace()]]></content>
 <!-- Optional: Tab trigger to activate the snippet -->
 <tabTrigger>ipdb</tabTrigger>
 <!-- Optional: Scope the tab trigger will be active in -->
 <scope>source.python</scope>
 <!-- Optional: Description to show in the menu -->
 <description>ipdb</description>
</snippet>

Hope you find this useful.

A simple way to rerun failed cucumber scenarios

In a recent project failing cucumber scenarios due to unreliable environments were a very common occurrence. I ran a set of tests and there were failures, then I ran them again a minute a later and they were all green! This became very frustrating. These failures where normally in the form of timeouts due to an ever increasing load on the app box. Obviously my first reaction was to speak to the team responsible for the environment and try to get the problems resolved but due to limited time and resource nothing could be done immediately.

So while I was waiting for further hardware to be thrown at the environment I decided to use the cucumber rerun formatter.

For this demonstration we need to have a feature which has a scenario that passes and a scenario that fails.

Feature: Rerun formatter

Scenario: Test that Passes
 Given I have 1 pound
 When I add 2 pounds 
 Then I should see 3 pounds

Scenario: Test that Fails
 Given I have 1 pound
 When I add 2 pounds 
 Then I should see 4 pounds

So lets try and rerun that failed scenario. On the command line add the formatters pretty and rerun so it looks like this:

$ cucumber features/retest.feature -f pretty -f rerun --out rerun.txt

After you have executed this you will have noticed that a rerun.txt file has appeared in the root directory of your project, if you open that you can see that the failed test has been recorded, now we need to rerun that failed test.

$ cucumber features/retest.feature -f pretty -f rerun --out rerun.txt || cucumber @rerun.txt

Notice that the cucumber will run through the 2 scenarios as normal then it will rerun the failed scenario. The || means that the cucumber will execute the rerun text file if a failure has occurred, if you replace the || with ; cucumber will execute the rerun every time.

$ cucumber features/retest.feature -f pretty -f rerun --out rerun.txt ; cucumber @rerun.txt

If you are experiencing problems with failing tests this rerun should not be the first thing you implement. Investigate the reason for the failures and try your upmost to get them fixed. I would only recommend using rerun for this kind of scenario if all else has failed.

 

How to install ChromeDriver on Centos 6.5 using vagrant

Recently I was asked to run some automated tests using vagrant and Centos 6.5, both technologies were new to me and at first glance this task was going to be a little difficult as ChromeDriver is not supported in Centos 6.5. Unfortunately there is very little documentation on how to get around this issue on the web, this is a post of my findings.

Getting started with Ruby, Cucumber and Capybara

Since I started in test automation I have always been asked by fellow testers ‘How can I set up my machine so I can start writing automated tests?’. When I first started out I also asked this very question.

There are lots of great resources out there which help to answer the above question but sometimes it can be like looking for a needle in a haystack. I have found many articles that are very technical and sometimes tailored towards users who have an existing development background, this post is for those guys who don’t.
Here is my guide to setting up a simple cucumber project on a mac, there will no doubt be other ways and possibility better ways, but this is how I have done it and I have found it to be very effective.