testdriven.com Wrangling quality out of chaos

JUnit lets you test software code units by making assertions that the intended requirements are met, but these assertions are limited to primitive operations. IBM Software Engineer Tony Morris fills the gap by introducing Assertion Extensions for JUnit, which provides a set of complex assertions that execute within the JUnit framework. Follow along as the author shows you how using this new package from alphaWorks can increase the reliability and robustness of your Java™ software.

Author: Tony Morris
Published: IBM DeveloperWorks, March 8, 2005
link

I want to automate as many tests as I can. I’m not comfortable running a test only once. What if a programmer then changes the code and introduces a bug? What if I don’t catch that bug because I didn’t rerun the test after the change? Wouldn’t I feel horrible?

Well, yes, but I’m not paid to feel comfortable rather than horrible. I’m paid to be costeffective. It took me a long time, but I finally realized that I was over-automating, that only some of the tests I created should be automated. Some of the tests I was automating not only did not find bugs when they were rerun, they had no significant prospect of doing so. Automating them was not a rational decision.

The question, then, is how to make a rational decision. When I take a job as a contract tester, I typically design a series of tests for some product feature. For each of them, I need to decide whether that particular test should be automated. This paper describes how I think about the tradeoffs.

Author: Brian Marick
Published: QualityWeek, 1998
link

After spending some time researching how easily you can automate Internet Explorer in C# (with the help of some URLs given to me by Demetrie), I began writing my own version of IEDriver. The URLs I looked at had a basic example of how to instruct IE to perform various actions. Over the course of the last year, I have enhanced my IEDriver class to handle other types of interactions with IE that I have required. While this is by no means a complete automation class, I believe it performs many of the common functions needed when writing automated tests.

Author: Leslie Hanks
Published: The Code Project, February 25, 2005
Related: IE Web-testing tools section
link

Email has become an integral part of everyday life for many people around the planet. Ubiquitous and inexpensive access using common standardized protocols has been one of the principal drivers behind this success. For software systems that must communicate with numerous human users asynchronously, email is a cost-effective and practical solution. However, these systems’ email components have proved difficult to test comprehensively. This article explains how to write a simple email server that can be easily integrated into your testing environment.

Author: Jason Kitchen
Published: JavaWorld, August 29, 2003
link

So where to start, where to start… What aspect of the project do I know the least about? XSL. I’ll start there. I’ll start with creating a sample XML file. No, wait. Source control first. I just imported what I’ve written so far into Subversion. OK, now I’m ready to create my XML sample.

Author: Dave Hoover
Ongoing contents

(NDLR: An instructive, step-by-step Java project notes blog describing the steps involved in creating a pet project using test-first methodology, mock objects, etc.)
link

After reading the first two parts of this article, you should have enough information to strike boldly and apply test-driven development to your projects. At first you’re likely to find that the road is somewhat rough and bumpy, though. How do you break up this module into something testable? How can you prevent your tests from becoming a burden to maintain? What exactly should you test?

This third and last part will cover some tips that should help smooth out the learning curve and make you more productive from the start. We’ll also look at some of the consequences of applying TDD to a project and what kind of things you can expect on the other side of the looking glass.

Author: Noel Llopis
Published: March 6, 2005
link

A step-by-step tutorial on installing Selenium, configuring it on your local machine, then writing and running acceptance tests against any Web application you want.

Author: Grig Georghiu
Published: March 3, 2005
link

The agile development workplace recommends some form of continuous integration in the build process, and CruiseControl is a popular framework for implementing such a continuous build process. While integrating CruiseControl with regular Java applications is well documented, some extra steps are required to make CruiseControl work effectively with BEA WebLogic Workshop applications.

This article shows how to use CruiseControl to effectively manage WebLogic Workshop applications, thereby allowing you to incorporate Workshop applications in your continuous integration build process. A critical part of this integration is writing code that interprets Workshop’s compiler output. This article also includes a download for a custom Ant task that does just this.

Author: Michael Hart
Published: dev2dev, February 28, 2005
link

Agile development can look a bit crazy, at first.

I’m writing this guide to explain the foundations of agility, outline its benefits, and show why it’s not so crazy after all.

[Sections: A Brief Definition, History, Benefits, Visible Progress, Fixed Price Contracts, Conclusion]

Author: John Rusk
Published: February 27, 2005
link

Once each developer is working in the tight feedback loop of the central circle, we can examine how the entire development team can work together in a more Agile way. Team level practices are central to Agile, as they show us how the team can work together more effectively and drive technical decisions together. We’ll look at this evolution of the team in four increments — setting the tone, team based code, increasing and maintaining effectiveness and the first moves into a "one team" approach, which includes those outside the immediate development team. We’ll present you with examples from 3Q Solutions, a software company that creates wealth management systems and uses Agile methods exclusively.

Author: Brian Swan
Published: uk.builder.com, 28 February 2005
link

To help developers decide whether they should be doing more automated testing, Ben Teese presents two questions in this article: Are developers being realistic about the testing they will complete on their applications? And when does automatic testing make sense for their applications?

Author: Ben Teese
Published: JavaWorld, March 7, 2005
link

I settled on the idea of investigating in-memory databases that would allow me to test the Hibernate layer without having to startup a full-featured RDBMS external to my development environment. I can say with much satisfaction that this was a very worthy exercise. I found numerous bugs I would not have been able to catch without this technique.

Author: Alex Vollmer
Published: February 27, 2005
link

Here’s a good interview question for a tester: how do you define performance/load/stress testing? Many times people use these terms interchangeably, but they have in fact quite different meanings. This post is a quick review of these concepts.

Author: Grig Georghiu
Published: February 28, 2005
link

A simple walk-through for a Maven-built application with Eclipse IDE integration.

Author: Tarun Ramakrishna Elankath
Published: March 1, 2005
link

A comprehensive unit-test suite is a necessity for a robust program. But how can you be sure that your test suite is testing everything it should? Jester: JUnit test tester, Ivan Moore’s JUnit test tester, excels at finding test-suite problems and provides unique insights into the structure of a code base. Elliotte Rusty Harold introduces Jester and shows how to use it for best results.

Author: Elliotte Rusty Harold
Published: IBM DeveloperWorks, March 3, 2005
link

Stepping Through the Looking Glass: Test-Driven Game Development (Part 1) provided just a glimpse of what was behind the looking glass. Now we’re ready to dive in all the way and look at how we can apply test-driven development to games. Be warned: the looking glass is very much one-way only. After you try this, you might become test infected and may never be able to go back and write code the way you’ve done up until now.

Author: Noel Llopis
Published: February 25, 2005
link

If you’re a typical game developer, you probably don’t write any tests for the code you create. So how would you feel about not just writing tests, but creating them before the code they are testing? What if I told you those tests don’t even verify that the code you write is correct? "It’s madness," you might say; "it’s all backwards!" Not really. It all makes sense in its own way. Follow me through the looking glass and I’ll show you the wonderful upside-down world of test-driven development and how we can apply it to games.

Author: Noel Llopis
Published: February 20, 2005
link

Agile is not a specific process, but rather an umbrella term for a group of methodologies and approaches that have a similar basis. These approaches, which include Extreme Programming, Dynamic System Development Method, SCRUM, Crystal, and Lean among others, are based on delivering high quality, working software early and often, and creating customer satisfaction.

Author: Brian Swan
Published: uk.builder.com, February 21, 2005
link

This article explains some theory behind testing/not testing private methods, and then provides and walks through a downloadable code sample to demonstrate these testing techniques.

Author: Tim Stall
Published: March 1, 2005
link

When using agile methods, it is not uncommon for the contents of a release to change dramatically. This can create problems for up-front user interface design as it is created with the expectation that certain functionality will be present in the released system. As UI design is created across features using techniques such as scenarios, it is especially vulnerable to changes. A user interface design also assumes that functionality will be implemented in an order that makes navigating from one feature to another possible. However, if the customer’s priorities do not match the flow created by the UI designer then the design may have to change substantially.

Author: Owen Rogers
Posted: February 12, 2005
link

On traditional projects, folks with Quality somewhere in their title (Quality Assurance, Quality Engineers, et al) perform Independent Verification and Validation (IV&V) activities to assess the quality of the system. Often these teams also review design artifacts. Sometimes they also have a hand in defining and/or enforcing the process by which the software is made.

Agile project teams generally reject the notion that they need an independent group to assess their work products or enforce their process. They value the information that testing provides and they value testing activities highly. Indeed, Extreme Programming (XP) teams value testing so much, they practice Test-Driven Development (TDD), writing and executing test code before writing the production code to pass the tests. However, even though agile teams value testing, they don’t always value testers. And they’re particularly allergic to the auditing or policing aspects of heavyweight, formal QA.

So how can testers make themselves useful on a team that does not see much use in traditional, formal QA methodologies? Here’s what I’ve been doing.

Author: Elizabeth Hendrickson
Published: January 19, 2005
link

Agile teams accept change as inevitable and tailor their processes accordingly. Short iterations mean that stakeholders can see steady progress and provide frequent feedback. Continuous integration means that if one part of the system isn’t playing nicely with others, the team will find out almost immediately. Merciless refactoring, where programmers improve the code internally without changing its external behavior, prevents code from becoming fragile over time. Extensive automated unit tests ensure that fixing one bug won’t introduce two more.

Author: Elisabeth Hendrickson
Presented: Pacific Northwest Software Quality Conference, October 2004
link

It’s no exaggeration to say that Web services are revolutionizing application-to-application communication. Web services are already being used extensively in corporate intranet environments and are making their way into commercial use, too. But because Web services are relatively new, techniques to test Web services programmatically are not widely known. In this column I’ll show you a technique to quickly write test automation that verifies Web service functionality.

Author: James McCaffrey
Published: MSDN Magazine, March 2005
link

We write software in order to serve some specific set of needs for some specific set of people. When I’m trying to understand what software to write, I apply this principle in the form of a few questions: Whose needs will the software serve? What needs will trigger those people to interact with the software? What roles will the software play in satisfying those needs?

Author: Dale H. Emery
Published: February 22, 2005
link

Release, to my mind, is the delivery of business value to the client – the process of taking your wonderful code, packaging it up, and delivering it in a nice little bundle to your client. In this diagram, a release is simply something that happens when you have no stories left. Not only does this jar with the agile/XP concept of “release early, release often”, but it radically oversimplifies the kind of checks that might need to be done prior to a release being ready (here simply called “System Testing”).

Author: Sam Newman
Blogged: February 14, 2005
link