Little cheat to speed up your WebDriver tests

While most examples for Selenium WebDriver use creating new instance of browser on setUp() and closing it on tearDown(), it is not that fast really. So, in most cases, you only need to clear cookies and open homepage. Fortunately, WebDriver allows this. Such a little cheat will significantly decrease the time your tests take to run.

You can clear cookies by driver.manage.delete_all_cookies (Ruby bindings). In Watir-WebDriver there is also cute clear_cookies() method. Just create a new instance of WebDriver before all the tests and clear cookies in setUp(). That's it.


Continuous integration for iOS app with Cucumber, Frank and Bamboo

It's been a while since I had written latest post and it's just because I have too little time and too little readers, so I wasn't sure it worthies spending time. But after this post by Marlena Compton I've decided to keep it on.

So, this post is about building continuous integration for iOS application with Cucumber + Frank as acceptance testing framework and Bamboo as CI server.


User-Agent in padBuster.pl

Quick note for those, who perform penetration testing of ASP.NET applications and try to exploit Padding Oracle Attack with padBuster.pl, but always receive 403 Forbidden response from either WebResource.axd or ScriptResource.axd. This is most probably because of incorrect User-Agent or, actually, it's absence. To fix, you need to add user-agent to LWM. Just change the following code of makeRequest() function from
$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
$lwp = LWP::UserAgent->new(env_proxy => 1,
                            keep_alive => 1,
                            timeout => 30,
       requests_redirectable => [],
                            agent => 'Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20110406 Firefox/4.0',
or whatever UA you need.
I actually think this should be added to padBuster.pl as an option.


Continuos Integration of Android apps

While looking for a way to implement this, I've found several how-tos, but they all used Maven, which didn't look great for me for several reasons. That's why I decided to set it up with myself. Here is the short manual if you are interested.
  1. Install Apache Ant
  2. Install Android SDK and its components (Tools and Platform Tools)
  3. Install Jenkins (formerly Hudson)
  4. Install Android Emulator Plugin for Jenkins and configure it with path to Android SDK
  5. Install Python Plugin for Jenkins
  6. Download android-junit-report.jar and place it to your tests lib/ directory (we need this as long as default Android test-runner doesn't generate XML report needed by Jenkins).
  7. Download build script and change variables section to fit your project (directories to application and tests, path to Android SDK, target version of Android, package name, use emulator or real device etc.). You don't need to add any modifications to AndroidManifest.xml or create build.xml - script will do this for you
  8. Create new job
  9. Add Python script as build step and paste modified version of build script there
  10. Try it!
That's supposed to be all. If you have any problems, feel free to comment/open issues at GitHub. Hope this will help you.


Security Kit on GitHub

I was planning to do this a long time ago, but this, that and the other delayed me. Finally, I've registered at GitHub and added repository for Security Kit. In short, that's the module for Drupal CMS which provides with few options to improve the security of your Drupal-based site. It aims to simplify the process of setting up security features which exist in modern browsers (CSP, Origin, X-Frame-Options etc.).
Present situation in web security indicates that regardless huge number of hacks and all these talks about "every site needs to be secured", the number of vulnerabilities does not decrease. Just take a look at XSSed. So, browser companies decided to add more built-in features to harden the web. They are mostly implemented with HTTP response headers and all the website owner/admin has to do is to add one.
Still, many people have no idea about such things or they don't know how to do this. That's the reason of creating Security Kit and, previously, SafeClick (which is so highly tailored, just for Clickjacking, so I decided to move it to Security Kit and close it).
Even though Drupal recently migrated to Git from CVS (thanks!), I plan to develop SecKit on GitHub along with other projects, which I hope I will soon finish (at least to make them public).

P.S. I do really hope and expect collaboration.


Verify methods for PHPUnit (like Selenium)

If you have ever used Selenium RC + PHPUnit and used in your tests a lot of verfiy* assertions (i.e. non-strict assertions), you should have seen that they are actually look like:

try {
} catch (PHPUnit_Framework_AssertionFailedError $e) {
  array_push($this->verificationErrors, $e->toString());

When you have around 100 verifications the code becomes a mess. That's when you should write your own verify* methods and instead use them.

I thought it would be useful for other PHPUnit + Selenium testers, so here is an example I of verifyEquals() as I guess it's the most used method:

class PHPUnit_Selenium_Verifications extends PHPUnit_Extensions_SeleniumTestCase {

   * Non-strictly asserts that two variables are equal.
   * @param  mixed   $expected
   * @param  mixed   $actual
   * @param  string  $message
   * @param  float   $delta
   * @param  integer $maxDepth
   * @param  boolean $canonicalize
   * @param  boolean $ignoreCase
  public static function verifyEquals($expected, $actual, $message = '', $delta = 0, $maxDepth = 10, $canonicalize = FALSE, $ignoreCase = FALSE) {
    // try assertion
    try {
      $this->assertEquals($expected, $actual, $message, $delta, $maxDepth, $canonicalize, $ignoreCase);
    // print exception and line number of assertion
    } catch (PHPUnit_Framework_AssertionFailedError $e) {
      array_push($this->verificationErrors, $e->toString(), "  on "  . __LINE__ . " line.");

Now you can just use $this->verifyEquals() instead of try-catch constructions.
I will keep on adding other methods if somebody finds this useful.

UPD: PHPUnit has built-in verifyCommand() method, which resolves all the problems.