Search
Tags
Archives
- April 2010
- January 2010
- November 2009
- January 2009
- May 2008
- February 2008
- November 2007
- October 2007
Syndication
You are currently browsing the archives for the "testing" tag.
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.
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.
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.
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.
Don’t make a mockery of testing
If you’ve worked on a Java team that valued test automation, you’ve probably been exposed to EasyMock or JMock.
While well intended, these tools imply that teams should focus their testing efforts on granular unit tests that provide maximum code coverage. Often these teams do this at the expense of integration tests. Since time is always finite, we suggest you spend the majority of your testing time on integration tests. Only after you’ve exhausted all integration testing possibilities should you be tempted to use mocks.
Unit testing Flex
This is part 3 of my exploration into Flex. In part 1 I wrote a simple weather forecast application. In part 2 I refactored the non-UI code into separate ActionScript classes. In this part I discuss unit testing those classes using FlexUnit. In short, FlexUnit allows you to run unit tests from the command line.