Automated testing software for your web app

At bitmechanic we’ve always been passionate about software test automation. One issue we’ve run into consistently with our clients is the difficulty of adding browser based acceptance tests to our applications. As more and more code moves into the browser (Javascript, CSS, etc) the need for browser based testing has increased.

Selenium is an excellent open source tool for testing web application, but it lacks a few features out of the box. We have recently released a web testing tool called regressr that addresses a few of these gaps.

(more…)

How to use Google App Engine Java with Maven

We all want to use Google App Engine with Maven, but Google stopped deploying GAE/J releases to their Maven repository for some reason. This article explains how to use Maven with App Engine. It also explains how to setup a local Maven repository. These instructions assume you’re using Linux.

(more…)

OpenID, Google App Engine, and Yahoo

If you want to use OpenID with Google App Engine / Java, try this library: dyuproject

It includes a standard Servlet Filter that restricts access to the URL prefix you specify. It also uses an internal HTTP library that is GAE compliant.

I was able to get it working with my app in about 30 minutes. For Google that is. Yahoo was a different matter.

(more…)

trac plugin for Gliffy released

We like trac and we like Gliffy. So we figured, why not combine them?

(more…)

In praise of scrumy

For the last month we’ve been using a new web based task board called scrumy. So far my opinion is that it’s the best solution I’ve seen for managing distributed agile dev teams.

(more…)

Continuous Integration for QUnit tests

In my last blog entry I wrote about how to unit test Javascript using QUnit. I this entry I’ll explain how to run those tests on your continuous integration server using JUnit and HTMLUnit.

(more…)

TDD in Javascript with QUnit

These days you’d be hard pressed to find a web application that isn’t using JQuery, Prototype, or YUI. Over the last few months I’ve had several conversations with fellow developers about how to test applications using these frameworks.

Fortunately each of these frameworks includes a unit test runner. In this article I dive into QUnit, the test harness for JQuery based web applications.

(more…)

Consider having two backlogs

One of the tenants of agile development is transparency: for example, Scrum teams only work on items chosen by the product owner from the product backlog. If there are technical deficiencies in the code base it is up to the team to make the case to the customer or product owner. If the case is sufficiently unconvincing, then they don’t get to do the work.

Is this really the best way to balance technical and business objectives?

(more…)

Disprove that the site doesn’t work

I was working at a client site this week and overheard a conversation that made my ears perk up.

Manager: Did you test the site?
Developer: Yeah. I clicked around through it and looked at the pages.
Manager: Did you try hitting the back button on all the pages?
Developer: (sheepish) No..
Manager: That’s not testing. You need to think about it backwards. Assume that the site doesn’t work and then try to disprove your hypothesis.
Developer: (confused) Huh..
Manager: I know it sounds weird. But try it. Assume it doesn’t work and then try to disprove yourself.
Developer: (cowed) Ok.. I don’t know if I can get to that today. Probably not tomorrow.
Manager: What else is on your plate?
Developer: Well, I have to do xyz for Bob, and abc for Tina. (etc etc)

To help put this in context, the developer apparently had made a site-wide change to a web application with hundreds of JSPs. He had touched almost every page. Now he is asked to “disprove that the site doesn’t work”, which if my logic works is equivalent to “prove the site works”.

Of course this isn’t possible.

Now in fairness to the manager, it appears he’s really asking the developer to do two things:

• Spend more time testing
• Be more creative in thinking of ways to test the system

The developer is probably thinking a few things:

• It appears you will hold me responsible if a regression slips in. Oh God I wish I hadn’t been tasked with this code change.
• Manual testing is really boring and I’m not totally sure what to look for.
• I have other stuff I have to do that is both more tangible and more interesting.

How can the manager be more supportive?

• Acknowledge the difficulty of the verification problem.
• Diffuse the responsibility. Regression testing is a huge job. It shouldn’t be the sole responsibility of this developer.
• Most importantly: Make test automation a core engineering practice in the group and encourage the developer to write tests to automate the cases he was thinking of. For example WebDriver now supports Firefox navigation automation (clicking back/next buttons). This work would be more interesting for the developer, and re-usable.

Asking the developer to perform a logical impossibility is not management.

Collaboration vs Interruption

There was a comment on the extremeprogramming Yahoo! group last week that I found insightful.

When two people share a common task to completion, communication between them is considered collaboration.
When two people work on a task in series, communication between them is often considered interruption.

I see this frequently on web application teams with a division between design and development. The two disciplines operate on separate tracks. Designers do visual comps of the screens and hand those off to the developers to implement. Invariably the developer needs assistance or clarification from the designer, who is now working on designing some other screen. The designer has to context switch, and may feel that time is being taken away from their current task.

This supports a few patterns of agile/lean development:

• Interdisciplinary teams. Build small teams with all the skills needed to implement a feature from start to finish.
• Work vertically in small batches. Develop one small feature from end to end. Then repeat.
• Optimize at the team level. Don’t try to sub-optimize the utilization of each team member. Let the team figure out how to best get the work done and measure their team velocity.