Blogs

The big thing around the office for the past year or so now has been PhoneGap. It’s gaining in popularity every day, and recently we’ve had applications starting to trickle into application stores other than the iPhone one! We now have one application out in the Nokia Ovi store, and one on the BlackBerry App World. I’m pretty excited to see PhoneGap getting a lot of mention all over the place, but this also puts more pressure on the PhoneGap team to have a solid framework that works consistently across all of the platforms that we support currently: iPhone, Android, BlackBerry and (some) Nokia models.

Mobile Spec running on a BlackBerry simulator

With PhoneGap being an open-source project, it is sometimes difficult to devote a lot of time to it all at once, and development coming in from user contribution is huge. One thing that is certain about open-source projects, especially ones where there are many contributors and an open development philosophy is used, is that having a set of tests is fairly essential. If developers wants to hop in and help out, in any way that that may be, they need to be sure that the changes they make don’t break the entire application. This becomes even more important as a project gets bigger.

So after that long-winded introduction, I want to point people’s attention to the new Mobile Spec that we have started to work on. You can find it on GitHub. Joe, our main PhoneGap Android developer, has his own fork of it that he’s started to fill up with tests, so we’ve made and are currently making progress on it. Yes! I love automatic regression testing - call me a geek, but I can’t help but have a warm fuzzy feeling inside knowing that test cases for something I’m working on are constantly trickling in . Obviously, the spec is in its infancy stages, but it’s a big win. The more we put into it, the easier it will be to develop for it down the road, and the more it solidifies the stability of PhoneGap overall.

Since day 1, PhoneGap’s goal has been for PhoneGap to cease to exist. That is, if all of the big players in the mobile space suddenly decided to work together and unify their third-party application development process, then PhoneGap wouldn’t need to exist as a project. Related to this, the PhoneGap JavaScript API is mostly based off of the HTML 5 specification - open standards are good and healthy for the developer community. What I’m getting at is that the Mobile Spec we’re putting together - maybe / potentially / hopefully - may end up being a decent test suite for the HTML 5 spec, or at least the mobile portion of the spec. Or maybe I’m just too optimistic

We’ve opened this thing up to the community and we want to hear what you guys think. Have a beef with the API? Fork the mobile spec on GitHub, change it to what you think it should be, and then send us a pull request. We’ll definitely have a look.

Here’s to many forks! Cheers!

Hi again everyone,

I’m a big fan of test-driven development, so I figured, what better way to evangelize than to blog about it? I’m mostly going to talk about TDD within the context of some recent work I’ve been doing at Nitobi. The project I’m working on is all .NET-based, so our main development tools are:

• Visual Studio (duh!) together with MS SQL Server,
• NUnit, an open-source unit testing framework for .NET projects, and
• Selenium RC + ASP.NET driver, a functional testing server and framework for web sites

For the ASP.NET web application I’ve been working on, we decided to implement and maintain two sets of tests: unit tests to make sure our back-end code was sound, and functional tests written for and executed using Selenium, to make sure our application behaved properly from a front-end perspective. However, soon after we started writing tests and feeling good about ourselves, we realized that writing individual test cases is practically impossible from a maintainability perspective, especially the front-end, or Selenium, tests. The reason is that most serious web applications are composed of a lot of “layers”: many levels of navigation, internationalization, even different views/features provided to end-users based on the browser the user is using. Writing a test case for each combination of these variables quickly adds up.

So what were our options? Given that we were using NUnit as the core testing framework, we looked at what add-ins NUnit had to offer. First, there’s the RowTest add-in, which allows you to create data-driven tests. Cool, I thought, exactly what I needed. That was quickly abandoned, though, because you manually had to specify what the data being passed into the test is! Not very useful. Next there was the IterativeTest add-in. Very simple and powerful idea: your test takes as an argument a function that returns an enumerable (something that implements IEnumerable). You can then use this argument in your test, and forget about writing the same test n times. Yay! Perfect, right? Yes… but it wasn’t good enough for us . The reason is because the current IterativeTest add-in that is up on the NUnit home page can only accept one enumerable argument (plus only works with NUnit 2.4.5 :s). So what happened was that Arthur C., good friend and ex-co-worker of mine on this project, extended the add-in and made it work with as many arguments as you like, and not just enumerables, too! It works with pretty much any type (including class getters). The add-in then creates combinations of each IterativeTest argument value and creates a separate test case for it. This ended up saving us a lot of time, and came in handy for two big functional, Selenium-based testing scenarios:

1. A web application that is localized. Internationalization is a big topic these days, and being able to run tests for each set of supported languages is pretty sweet. To use my project as an example, we stored the languages in the database, so our test suite implemented a function that dips into the database, grabs all of the languages and returns them as an ASP.NET ArrayList object. This was then passed into pretty much all of our test cases, so that they were run for each language.
2. Testing across browsers. Selenium gives us the ability to run the tests in various browser instances, so it’s quite easy to create an ArrayList of browser executable names (’iexplore’, ‘firefox’, etc.) and pass these into your test cases. The test case then creates an instance of the Selenium server, speciying which browser to use as the agent, and executes the test.

So, everyone, please feel free to grab the IterativeTest NUnit add-in that we’ve put together. It works for NUnit 2.4.8, too. The binaries are linked above. For the source, check out my repository that’s up on GitHub. As always if you have stuff to add or comment on, just fork away and keep in touch!