Rod Coffin's Weblog

Infinitest and Scala

rcoffin — Tue, 01 Sep 2009 01:21:32 +0000

While at the agile 2009 conference last week Ben Rady and I sat down to figure out what we would need to do to get Infinitest working with Scala. To our delight it worked right out of the box! This is both a testament to the power of JVM based languages and the flexibility of Infinitest. Here is a quick screen cast I put together to show just how easy it is to use Infinitest with Scala.

SCM Green Hooks

rcoffin — Tue, 04 Aug 2009 02:19:04 +0000

Today Improving Works released version 5.0.51 of Infinitest for IntelliJ. This version includes IDE integrated support for SCM Green Hooks. A green hook is an Infinitest term for an action which is taken when your tests are run and all of them are passing (green). This SCM green hook will optionally perform an update from whatever source code repositories you have configured for your project when the passing state is reached. With this hook running you will not only be continuously testing your local copy of the project but will be continuously integrating and testing against the very latest state of your source code repository. Green? Go ahead and commit!

The screencast below explains this new feature and shows how to quickly get going with it.

Infinitest 5.0.26 Released

rcoffin — Sat, 09 May 2009 19:48:53 +0000

Infinitest 5.0.26 has been released and is available for download from the IntelliJ repository. New features include:

Support for Java 6
Rogue marker fixes
Improved marker support for errors that occur outside the project and in 3rd party libraries.
Resolved a class file parsing issue that occurred with some projects

Infinitest for IntelliJ 5.0.0 Released

rcoffin — Thu, 02 Apr 2009 19:01:14 +0000

Today the Infinitest team is pleased to announce the release of Infinitest for IntelliJ version 5.0.0. This new version includes two main features: gutter markers and a log tab. The updated plugin is available for download from the plugin manager within IntelliJ. Also, please check out our new and improved home page at http://www.infinitest.org.

Gutter markers provide information on test failures within your code documents themselves. For example, assertion failures within your unit tests are annotated like this:

And runtime exceptions are annotated at the point at which the exception was thrown, like this:

This new version also contains an additional tab which allows logging messages to be viewed:

FacesTester 0.1 Released

rcoffin — Thu, 02 Apr 2009 14:28:27 +0000

Yesterday Jason Lee and I released our first version (0.1) of FacesTester, a test framework for JavaServer Faces applications. Jason has a great write-up on features included in this release on his blog at http://blogs.steeplesoft.com/facestester-01-released/ that I won’t repeat here. But I encourage you to give this tool a test drive if you’re a JSF developer looking for a solution to test driving your JSF code. The project is being hosted at Kenai where you can access our mailing issues, issue tracker, etc. We would appreciate any feedback you have.

Introducing Faces Tester

rcoffin — Sun, 29 Mar 2009 13:05:54 +0000

For the last month or so I have been working on a test framework for JavaServer Faces applications with my friend Jason Lee. The goal of this framework, named FacesTester, is to enable the test driving of JSF applications. Earlier Jason announced FacesTester and today I’d like to illustrate one very simple example of how FacesTester can be used to specify a simple web interaction in a test driven manner.

Following in the well trodden path of others let’s start by making a quick login page. Using FacesTester I can write a JUnit test like the following that describes how I want this simple page to work:

public class WhenClickingTheLoginButton {
    @Test
    public void shouldDisplayGreetingToUserNamedInUsernameField() {
        FacesTester tester = new FacesTester();
        FacesPage page = tester.requestPage("/login.xhtml");

        FacesForm form = page.getFormById("form");
        form.setValue("username", "Rod");
        form.submit("login");

        assertThat(page.getComponentWithId("greeting").getValueAsString(), is("Hello, Rod!"));
    }
}

As you can see this test specifies that if a user types in their username and clicks the login button then they should receive a friendly greeting from the system. This test fails when run since we haven’t written any production code yet. The message we get is:

com.steeplesoft.jsf.facestester.FacesTesterException: The page /login.xhtml was not found.

So let’s create a simple HTML to pass the previous specification. You’ll notice that in this example we’re using facelets for the view technology:

Running the test now produces the following message:

java.lang.AssertionError: HtmlForm 'form' does not exist on page.

Ok, so now we need to place our components on the page. I’m going to add all three now to save space, but I would normally do this one at a time in quick TDD loops:

Re-run our test and now we get the message:

	java.lang.AssertionError:
	Expected: is "Hello, Rod!"
	     got: null

So now, to actually implement some logical behavior to happen when the login button is pressed. First, let’s declare a managed bean in the faces-config.xml descriptor:


    LoginPage
    com.steeplesoft.jsf.sample.LoginPage
    session

And of course, actually create the bean.

public class LoginPage {
    private String name;
    private String greeting;

    public String login() {
        greeting = "Hello, " + name + "!";

        return null;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public String getGreeting() {
        return greeting;
    }
}

Bind it to the actual components on the page:

Re-running our test shows passes, and running the application shows that our quick login page is now working correctly! We have been able to test drive the interaction of these user interface components in a simple and meaningful way.

We are planning on releasing 0.1, or first public release, sometime soon so keep an eye out here or at Jason’s site. Also, we are adding features in a test-driven manner meaning that we are using test scenarios like the simple one above to guide the functionality we’re building into FacesTester. Like to see some particular features in FacesTester? Just sketch out a test similar to the one above and send it to us. You’re input will help us out tremendously.

Presenting at SD West 2009

rcoffin — Thu, 05 Mar 2009 16:05:29 +0000

Next week (March, 9-14) I will be presenting at SD West 2009. SD West is always a great conference and I highly recommend making the trip out to Santa Clara one year and checking it out. If you are fortunate enough to be making the trip this year I invite you to come to any of the three sessions I am giving.

Set your User Stories Free with Groovy’s easyb

Co-presenting with Andrew Glover

Leveraging user stories during application development enables intelligent handling of customer requirements without having to create deeply formalized requirement documents. What’s more, user stories are an excellent mechanism for availing the expertise of a customer in authoring an appropriate acceptance procedure, which logically ensures the goals of the user story have been fulfilled by development. By employing user stories, teams are able to respond faster to rapidly changing real-world requirements. Yet, automating story testing with most current tools, such as FIT and GreenPepper, for example, can be cumbersome to the point that these tools detract from the conversations (between stake-holders and development) that are a core aspect of user stories. With the emergence of dynamic languages that easily incorporate the creation of domain specific languages, new tools are materializing that more easily leverage users. One such tool is easyb, which is an open source Java based framework that provides a syntax for defining stories and scenarios in a concise manner that ends up staying out of the way such that development teams can more effectively collaborate with stake-holders while having a powerful framework for binding user stories to the system under test. These stories then more appropriately serve as a mechanism for validating a user conversation against the system over time.

Scaling Everest - Testing a Web Application

Testing web applications is notoriously difficult. Historically, this has been because of the interactive nature of web applications, the distribution inherent in the browser-server model, browser diversity, and framework specific issues. Because of these challenges, developing good tests for web applications is often expensive and those tests are often fragile and require ongoing effort to keep relevant. This session will demonstrate various tools, techniques, and strategies for creating cost-effective and maintainable tests for web applications while putting these to work in testing a live application. These tests will progressively scale higher up the application stack as we explore the trade-offs associated with testing at various levels, including: executing tests at the highest level of the application just inside the container boundary; executing test at the web framework level; executing tests as though you were a browser; executing tests through a real browser. Attendees will come away with a deeper understanding of tools and techniques which can be used to develop their own strategy for effectively conquering the web testing mountain.

Continuous Testing: TDD Turned Up To 12

Continuous Testing (CT) is a developer practice that involves automatically running tests after every change, even so much as a single statement. It gives you instant feedback about the semantic correctness of your code, just as modern IDE’s give you instant feedback about syntax errors. CT has a profound impact on the way we use TDD. This session will cover the history, theory, practice, and daily application of CT to real-world projects. First, we will cover the history and basics of Continuous Testing, discuss it’s application on different platforms, and the presenter’s ongoing experiences with CT on several systems. Then we’ll demo the practice using various languages and some open source continuous testing tools. Finally, we’ll wrap up with a discussion of where this practice might be headed.

Raising the Bar with Continuous Testing

rcoffin — Wed, 11 Feb 2009 19:25:13 +0000

Earlier this week the Agile Journal published my article on continuous testing. Please check it out, I would love to hear any feedback you have on the article, CT, or Infinitest.

Hello, Dave

rcoffin — Mon, 19 Jan 2009 19:47:23 +0000

There are quite a few good tools available for developers who are interested in writing more expressive tests. Frequent readers of this blog will doubtless know that I am a big proponent of easyb which is a very effective groovy-based Behavior Driven Development (BDD) tool. But what if your organization doesn’t support the use of Groovy or you are not fortunate enough to use the IntelliJ IDE (for which easyb has direct support for)? Other popular tools in this vein include Fit, Fitnesse, GreenPepper, RSpec, and Concordian among others. These all share a desire to more expressively represent system behavior in an automated manner. But like all tools, they have their own challenges as well. They all introduce their own syntax for expressing behavior which can make writing specs more cumbersome. And they all require special methods for running them introducing very real tooling issues. In this brief post I will introduce how you can begin to write more expressive BDD-styled tests through JUnit, and how the JUnit-based BDD tool JDave can help you find some of the expressiveness offered by the tools listed above without having to venture out beyond the ubiquitous JUnit platform.

BDD is an extension to Test Driven Development (TDD) which re-orients the language of testing from the structure of your code (classes and tests) to the behaviors your system should exhibit. Consider the following user story:

As a bank customer
I want to be able to withdraw funds from my account
So that I can have ready access to cash

We can refine this specification by identifying some acceptance criteria:

Given an account with a balance of $500
When a customer withdraws $100
Then the account should have a balance of $400

We could write a test for this behavior using traditional unit testing syntax as follows:

public class AccountTest extends TestCase {
	public void testWithdraw() {
		Account account = new Account(500);
		account.withdraw(100);
		assertEquals(400, account.balance());
	}
}

With this approach the structure of test is coupled to the structure of our implementation class. Specifically, the AccountTest class is related by naming convention to the Account class and the testWithdraw method is related to the withdraw method of Account. A BDD approach would change the syntax of this tests to relate it to a system behavior rather then specific implementation component. In BDD parlance this is referred to as a spec instead of a test and could look like the following:

public class WhenWithdrawingMoney {
	@Test
	public void shouldDecreaseAccountBalance() {
		Account account = new Account(500);
		account.withdraw(100);
		assertThat(account.balance(), is(400));
	}
}

Reading the test class name and the method name together produces the phrase “When withdrawing money should decrease account balance.” This is very descriptive of behavior that the spec is asserting the system should exhibit.

JDave is a JUnit-based BDD framework that expands the syntax available for use in writing BDD-styled specs such as should, must, not, where, contains, etc. We can express the same test uses JDave as follows:

@RunWith(JDaveRunner.class)
public class AccountSpecs extends Specification {
	public class WhenWithdrawingMoney {
		public void shouldDecreaseAccountBalance() {
			Account account = new Account(500);
			account.withdraw(100);
			specify(account.balance(), should.equal(400));
		}
	}
}

So there are a host of tools and techniques that enable one to write expressive tests with just Java and JUnit. These are great ideas to keep in your developer toolkit. But even with techniques such as these writing tests built upon plain Java doesn’t rival these same conciseness afforded to tools such as easyb which are free of the constraints of the Java language. For example, consider this test written with JDave:

	public class WhenWithdrawingMoney {
		public void shouldNotAllowWithdrawalOfNegativeAmount() {
			final Account account = new Account(500);
			specify(new Block() {
				public void run() throws Throwable {
					account.withdraw(-100);
				}
			}, must.raise(RuntimeException.class));
		}
	}

Because Java doesn’t offer support for closures this test is slightly obscured by three additional lines required to define an anonymous inner class. Instead easyb this test could be expressed as:

it "should throw exception for negative withdraw amounts", {
  Account account = new Account(500);
  ensureThrows(RuntimeException) { account.withdraw(-100) }
}

In conclusion, if you would like to write more expressive, BDD-styled, specifications for your system and aren’t able to use more powerful tools for whatever reason, you can still go quite a towards accomplishing this goal with the Java language, and JUnit. And tools such as JDave, and Hamcrest (which I didn’t cover here) can help make these tests yet more expressive while not deviating from the ubiquity of the JUnit platform.

Free Consulting!

rcoffin — Tue, 13 Jan 2009 15:31:21 +0000

Nowadays everyone is looking for better ways of doing more with less. Companies are reducing staff, slashing budgets, and deferring major new investments while those remaining are left to shoulder the added burden created by these cuts. I believe that in order for software development teams to successfully meet these challenges they need to continue to find new and innovation ways of applying disciplined software development practices to their craft. Project automation, continuous integration, unit testing, test/behavior driven development, and continuous testing are practices that should be a part of every software developer’s arsenal.

These are all topics that I’m passionate about sharing with others and for a very limited time I am offering free 2-4 hour consulting sessions to explore any of these areas with you and/or your company, no strings attached! For companies in the DFW Metroplex I would be happy to come to you to run a brown-bag session, talk about any challenges you’re experiencing or questions you my have, or even pull up a chair and do a little bit of pair programming. If you’re outside of DFW I would be happy to talk on the phone or run a web-based presentation for you.

What I hope to get out of this is simple: opportunities to talk with others about areas that I find interesting, to run through presentations I will be giving at industry events later in the year, and to forge new relationships with people and companies. So if you’re interested in taking me up on this offer then please feel free to contact me by email at rod.coffin@improvingenterprises.com.