Blogbody Rotating Header Image

February, 2007:

Struts 2: released

Feb 27th, 2007
by plightbo.
1 comment

While I’m on my posting blitz, I thought I’d take a moment to recognize that Struts 2.0 is GA and out.

I upgraded HostedQA to Struts 2.0 a few weeks ago and it was wonderful. I think I might even switch Able back to using it – if I get the time.

But mostly, I just want to say to the guys that made this happen (Don, Ted, Toby, Rainer, and everyone else): thank you for all your hard work.

It’s truly amazing to see a project I helped grow over the last few years become so widely distributed and backed up by an amazing team. I only hope I can be more involved in the 2.1 release!

Faster Feedback: from TDD to CI and Beyond

Feb 27th, 2007
by plightbo.
Comments are off for this post

It’s a long read, but well worth it: check out Faster Feedback and Why You Want It: From TDD to CI and Beyond from the IDEA guys. They really are spot on, and lot of what is said there goes back to the same philosophy that drives IDEA excellence.

I’m really looking forward to what JetBrains continues to pump out – they have an amazingly solid platform (IntelliJ IDEA) to build upon.

Do it: use ridiculously long test method names

Feb 27th, 2007
by plightbo.
1 comment

“Dan North” (tastapod!) has a good write-up on what he is calling “BDD”: Behavior Drive-Development.

He does a much better job than I can do discussing all these items, but the thing that struck me is that almost all his conclusions can be reached by following just one piece of advice: make your test methods really expressive.

I started doing this in 2004 and it has been a huge help. My tests are more focussed, and because of that, I write more tests because it doesn’t take as much thought/energy. And in writing more tests, I often design my code better, and ultimately produce software faster. As a nice side effect, quality has gone up, but that is not the primary reason for TDD or BDD.

Unfortunately, Dan’s examples of test methods were rather weak – often the agiledox crowd uses really simplistic examples. So I thought I’d give some examples of some of my methods from HostedQA:

  • parsingHostHandlesHttpAndHttpsAsWellAsOptionalPorts
  • findingAnAccountByNameWorksAfterCreatingAnAccountOfTheSameName
  • creatingNewAppConfigReturnsSameIdAsTheIdSetOnTheAppConfigReference
  • findingAppConfigsForAProjectReturnsThemInAlphabeticalOrderByName

And my personal favorites (broken up with a space because they are so long):

  • updatingAppConfigWithoutResourcesThat UsedToBeAssociatedWithItCausesThoseReferencesToBeDeleted
  • deletingAPopulatedProjectCausesAllChild EntitiesToAlsoBeDeletedAndTheProjectIsCompletelyDeleted

Kind of annoyingly long methods? Absolutely. But not only, as Dan points out, is it easier to know what went wrong when a failure occurs, it is also almost brainless to implement these tests (and thereby design your application in the most direct manner possible).

If my test requires that I test that “updating an app config without resources that used to be associated with it causes those references to be deleted”, it’s really easy to know what I need to test – it’s literally spelled out for me.

As a small note: Dan recommends that tests usually have “should” in front of them. I prefer to think that all my test methods (I use TestNG, so I don’t have “test” in the method names) have “test that” prepended in front of the sentence. Ie: “test that adding X and Y results in Z” becomes addingXAndYResultsInZ.

Next Gen Testing Tools

Feb 27th, 2007
by plightbo.
Comments are off for this post

What Problem Would Next-Generation Functional Testing Tools Solve?:

Various people have tried various structures including table driven things (like FIT/FITnesse) and Domain Specific Languages. But none of these approaches has quite succeeded in transforming the state of the practice the way JUnit did for unit testing.

(Via Ruminations.)

Elisabeth Hendrickson has posted several posts on next gen testing tools recently.

With HostedQA, which, by the way, recently had some major developments I’ll be announcing soon, I tried to attack two main problems that crop up when writing very rich tests like functional and acceptance tests: infrastructure and * maintenance*. I’m sure that there is a lot to do on the reporting front as well, but I’m leaving that alone for now. :)

By infrastructure, I mean challenges like setting up the test environment, keeping it in a consistent state, ensuring you have all the tools/browsers/databases/whatever always available for automation, running your tests in a timely manner, etc. All of these are much more challenging that JUnit, simply because JUnit only concerned itself with in-memory state and fixtures that could be recreated in milliseconds, not minutes or hours.

When I talk about maintenance, I mean the issue of describing tests in a way that is usable by the test writer and evolving the test as the product and requirements evolve. Again, with JUnit test description was easy: the test writer had intimate knowledge with the item being tested and was able to write it in the same language. For complex testing, there are literally a handful of languages being tested (SQL, Java/Perl/Ruby/etc, HTML, JavaScript, Flash, PL/SQL, etc), so right off the bat there is a big disconnect between the simplicity of JUnit and this problem.

I’d like to dive in to the solutions I’ve come up with for both of these, but it’s getting late and I’m already in the wrong time zone. But I promise to follow up in the next day or two on how HostedQA has addressed infrastructure and maintenance problems, all with the goal of making functional testing as ubiquitous as JUnit is.

For now, I leave you with this: These are the two biggest challenges that I see with this type of testing. Do you agree? Disagree? What is your biggest barrier to entry for this type of testing?

Why IntelliJ IDEA Customers Keep Coming Back

Feb 27th, 2007
by plightbo.
Comments are off for this post

Why IntelliJ IDEA Customers Keep Coming Back:

Brian Pontarelli has a passion for the keyboard and makes some good points about usability and support in regards to Java IDEs, specifically IntelliJ IDEA and Eclipse. The comments after the main post are especially interesting, such as where some commenters argue over whether a reported issue counts as either a severe bug or a missing feature. I mean, come on. Does it really matter? The point is that it interferes with Brian’s experience of usability and productivity. I’ve been saying it for a while: It’s not about feature lists, it’s about usability and productivity. You won’t find usability or productivity on a feature list, but it can easily be the most important deciding factor on whether or not to choose one piece of software over another. JBuilder was marketed on the length of its feature list, and look where it got them.

(Via idea.log.)

Spot on. Feature-for-feature, Eclipse has most of what IDEA has. Most of the same refactoring, most of the same plugins, etc. But it doesn’t have the intangibles that don’t fit on a feature list.

I was just demoing IDEA to a coworker (who is an Eclipse user) and he was very impressed at the subtle things I showed him that Eclipse just completely glosses over:

  • Intentions everywhere: see an error or warning? Press F2 to jump the cursor there and press Alt-Enter to bring up a toolbar that can usually fix it immediately. For example:
    • A variable not being set anywhere? Generate a setter!
    • A variable not being read anywhere? Generate a getter!
    • A parameter not being used? Assign it to a field and/or create a new field!
    • A private function not being used? Delete it!
    • A method call not matching the args being passed in? Change the signature!
    • A method doesn’t exist that is being called? Create it!
    • etc etc – the list is literally hundreds and hundreds of little nuggets like this
  • Smart code completion: Eclipse and VS.NET have basic code completion that offers up the list of variables in scope. IDEA goes so much further. In addition to type-specific code completion (only show things that are actually type-safe), it will even suggest variable names and other values based on your usage patterns in the past.
    • Do you always name your ProductManager variable prodMgr? IDEA will notice that and start suggesting that as you code complete a new variable definition.
    • Editing an XML file? IDEA will see the unique words and allow you to press ctrl-space and prompt you for those words. Perfect for configuration files where you often repeat the same strings several times.
    • The above also works in i18n resource bundles, even for the values of the keys. Just today “foo.desc” expanded to “foo.description” and “Desc” expanded to “Description”. Once you’re used to it, everything just flows..

There are a ton more examples I could provide, but the general rule of thumb is that while most IDEAs might match it feature-for-feature on a check list, none go nearly as deep. And it is that depth that makes IDEA users so much more productive.

Re: Testing Ajax

Feb 27th, 2007
by plightbo.
Comments are off for this post

Testing Ajax?:

I ran across an interesting article entitled “Improving Test Coverage of Ajax Applications” in which the author likens the challenges of testing Ajax applications to that of testing traditional GUI apps. While some newer frameworks (like Selenium) are positioned to actually verify Ajax-ian behavior, they can lead to a false sense of security because of the complexity associated with the combination of actions in using a GUI.

(Via Test Early.)

I posted the following comment to the entry above, but I think it important enough that I bring it up here as well. I’d be interested in hearing about ideas that can help make expressing tests for AJAX applications easier:

Absolutely – Selenium and other tools are now available to help, but there are still real challenges in describing these new types of interactions. The old-school tools (SilkTest, QTP, HttpUnit, etc) either didn’t understand the concept of multiple user transactions in a single page or didn’t have the technology to deal with AJAX at all.

Selenium helps with the AJAX/multiple user transactions issue, but it still requires testers to express the desire to “click on button X, wait for Y to appear” in their tests. I think there is still room to make this easier to understand and test against, possibly by integrating with AJAX and/or web-based frameworks, and thereby understanding the interactions at a deeper level.

Good for Atlassian

Feb 27th, 2007
by plightbo.
1 comment

Confluence 2.4 – Baby Steps:

Confluence 2.4 would be developed in a strict six week time-box from inception to release. Anything we had done at the end of those six weeks we’d ship.

(Via Atlassian Developer Blog.)

Atlassian has always been a company I admire greatly. They put engineering first and foremost and let their products sell themselves. I’m really glad to see that they are continuing to push the envelope with short release cycles and lots of automated testing. They have a few interesting things just around the corner that will make watching this experiment that Charles blogs about even more interesting.

Of course, Atlassian wouldn’t be able to do any of this without their huge library of automated tests. I’m told they use HtmlUnit for most new tests, and HttpUnit in older tests. Now if I could only get them to try out Selenium, or even better, HostedQA. :)