Weiqi Gao's Observations - testing tag

Java News Brief (JNB): Migrating To JUnit 4

Tue, 18 Sep 2007 22:27:56 GMT

In the August issue of the OCI Java News Brief (JNB), Charles Sharp gave a pretty detailed prescription for migrating from JUnit 3 to JUnit 4. Besides the normal "this is what changed" material, Charles also points out some of the new features in JUnit 4.4. One of them is described thusly:

Charles Sharp: JUnit 4.4 introduces a new assert, assertThat, and some assumptions: assumeThat, assumeNotNull, assumeNoException, and assumeTrue. The 4.4 release notes give credit to Joe Walnes for the assertThat assertion mechanism. Those familiar with the jMock project will probably recognize it.

The assertThat assertions require a parameter of org.hamcrest.Matcher type. JUnit 4.4 provides several of these Matcher classes by including a third-party package, org.hamcrest.core as well as including some in the package, org.junit.matchers. According to the release notes, this is the first time a third-party package has been shipped with JUnit. A good start on using this assertion is found in a blog post by Joe Walnes, in which he explains the rationale and intended usage of assertThat.

That's something I would not have paid attention to. If you haven't figured out, I have a tendency to do the old thing. I would have been perfectly happy using JUnit 4 with just the @Before, @After and @Test annotations. Now I'm curious about this assertThat thing. And I wrote the following test:

import static org.hamcrest.core.AnyOf.anyOf;
import static org.hamcrest.core.IsSame.sameInstance;
import static org.junit.Assert.assertThat;
import org.junit.Test;

public class Foo {
    @Test()
    public void foo() {
        Object o = new Object();
        Object o1 = new Object();
        assertThat(o, anyOf(sameInstance(o), sameInstance(o1)));
    }
}

Hmmm, my unit tests can become a lot more interesting.

Got your attention? Go read the whole thing.

Selenium: Automatable In-browser Functional Testing For Web Apps

Fri, 21 Apr 2006 02:54:31 GMT

At today's OCI Java lunch, our resident automated building and testing zealot Mario Aquino talked about an interesting tool called Selenium.

I forgot to blog it while he's talking. So I'm doing a little bit of catching up tonight. And all of this is from my impression from one hour of presentation/demonstration.

Selenium

tests web applications
while running them inside the browser
with FIT style table driven test scripts
that exercises the HTML page's links, buttons, text fields, etc.
and asserts and verifies various on-screen values
for fields selected by IDs, names, or XPath expressions

Selenium scripts

have alternative representations as
Java code that can be put into JUnit tests and become part of the hourly build
Ruby code that can be invoked through rake
or Selenium "wiki" code that's just a tad easier to write than HTML tables

There is a Selenium IDE that can be installed as a Firefox extension. It allows one to write Selenium scripts by recording a browsing session. (In the screenshot you can see me clicking on the Save button to save a draft of this post, and then clicking on the link to the artile on the Drafts screen to resume editing.)

Mario did mention a few quirks. One is that if ran as JUnit tests, Selenium tends to not close the browser when it's done, leaving thousands of open browsers behind on the testing machine. Another is that "clickAndWait" doesn't work with AJAXy buttons or links.

Selenium was developed by ThoughtWorks for one of their projects and is now Open Source (Apache 2.0 License).

Java News Brief (JNB): The Framework for Integrated Tests (Fit)

Wed, 14 Dec 2005 18:26:45 GMT

If you have heard about Fit for some time, but never had the time to investigate it, then this month's JNB article is for you.

The idea is very simple.

Your write your test scripts in HTML:

<table border="1" cellpadding="2" cellspacing="2">
  <tbody>
    <tr>
      <td style="vertical-align: top;" colspan="2" rowspan="1">ValidateCustomerName</td>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">
        <span style="font-style: italic;">customer name</span>
      </td>
      <td rowspan="1" colspan="1">
        <span style="font-style: italic;">valid()</span>
      </td>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">
      </td>
      <td rowspan="1" colspan="1">error</td>
    </tr>
    <tr>
      <td rowspan="1" colspan="1">Mario</td>
      <td rowspan="1" colspan="1">true</td>
    </tr>
  </tbody>
</table>

which looks like this in a browser:

ValidateCustomerName
customer name	valid()
	error
Mario	true

You run the thing:

[prompt] $ java fit.FileRunner tests.html report.html

And depending on if your code is right or wrong, you get either an all green report card:

ValidateCustomerName
customer name	valid()
null	error
Mario	true

or worse (from a different test):

check

customer total balance

$135.00 expected

$35.00 actual

You have to write a few Java classes along the way. But those are trivial, right? :)