Fork me on GitHub

Saturday, September 26, 2009

Setup script and shell command for Pylot

I gave a talk at PyCon India on "Testing Web Applications using Python" which featured my favourite toolkit Windmill, WebDriver, Twill and Pylot. Think Pylot impressed the audience (Great work by Corey Goldberg :) and they started trying it out immediately. Unfortunately before figuring out that they have to download it from Pylot website, I think a vast majority of them searched at PyPi and tried using easy_install. As a result one of the questions I got was unavailability of any installation medium for Pylot. Seizing the chance for me to learn how to create a setup.py based installer I jumped on the task of creating an installer for Pylot. Also to make the usage of the tool easier I have added a command line command pylot which works the same way as using python run.py to run pylot tests.

So how to use this? Pretty simple. I have changed the directory structure a bit (Hope Corey doesn't get pissed off :). The pylot directory remains same except there will be a parent directly with setup.py. You can run the set up command as usual "sudo python setup.py install" (Yes mostly you may need to do sudo depending on where your python dist-packages are). Once you do this you will get pylot-runner into path and add pylot to the packages. Now you should be able to run any pylot test case with a pylot-runner. All the commandline options hold same as before "pylot-runner --agent=377 --xmlfile=awesome_website_tests.xml". Your results will be created in the same folder as where the xml test case is.

This is my first script of setup.py. Let me know if there are better ways to do this stuff. Also I will convert the installer into an egg based one but it will take few days for me to do it.

Gotcha - I have created, installed and tested this on my linux system and it works amazing. So I haven't added anything specific to windows which includes the recorder. I may do this along with converting this installer to egg but it may take sometime. The wxpython Gui gets bundled though. Only the recorder is left behind...

Download for Pylot with setup script and shell command - http://miscellaneous-downloads.googlecode.com/files/pylot_with_setup_and_command.tar.gz

Thursday, September 17, 2009

Functional Test suite in C# or Java... Why?

Every time I see a functional test suite being developed in a static language, I get to the same question. Why? I feel odd when I hear people that the development language is C# or Java and so the functional test suite testing the web application or REST interface also needs to be in the same language. I understand and accept the reason for unit test as TDD is a design activity and it is better to be in the same language. But functional tests? Why?

I also feel sorry for people in the team who spend time mangling a static language to build test suites and framework to make the whole thing work. Also the slowness of the feedback cycle as most popular static languages are compiled and so functional test suite also needs to go through the same cycle.

So here are my reasons to choose a cool funky dynamic language to write your application level test suite.
  • Easier development cycle. Typically dynamic languages have more essence to ceremony ratio. They are lightweight. They don't have the type noise which static languages have as we don't need that kind of information in our functional tests a lot. Also dynamic languages being less ceremonious is easier to pick up and start working.
  • No wastage in compiling time. Most of the dynamic languages (Actually all I know) are not compiled and so donot have that long compile cycle. Typically functional test suites don't run as an application and donot have the same considerations as them. For functional tests, the quicker they run better the feedback cycle.
  • Easier to build abstractions. It is easier to build abstractions like frameworks, DSLs or Fluent Interfaces in dynamic languages. Less noise, more essence and better abstractions :)
  • Better drivers and libraries - Almost all the drivers I know are in dynamic languages. Watir, Selenium, WebDriver (Use with JRuby or python :), Celerity. Also you have frameworks like Rspec, Cucumber and Robot framework already available to build your test suite better. You have HttpDrivers, XmlParsers, JSonParsers or whatever infrastructure or libraries you need are available as well.
  • Easier to experiment with. Dynamic languages are lightweight to work with. They also typically come with a REPL which is a good place to learn and experiment. If you want to know how to play with a REST based service, fire up the REPL. Import a Http library and start sending requests.
  • They have a great community to work with. Difficult to substantiate but I can challenge that Ruby and Python community are way ahead in catching up with new stuff than .Net or Java. Also if you see Github and find the major languages of open source projects hosted there :).
May be there are more reasons. If you can think of any add them to the comments to discuss.

If you are a developer or a tester in a team (I don't differentiate between both of these roles :), do yourself and your team a favor. If your development itself is a dynamic language, you lucky dog :). Else choose a suitable language of choice to write functional or end to end tests. Don't get into the dogma of using the same language as development language.