Oli's Blog

Wer nach dem gestrigen Kurz-Vortrag (auf Englisch) über "10 Years PatternTesting" auf dem Eclipse Demo-Camp etwas ausführlicher die Entstehungsgeschichte hinter PatternTesting nachlesen will, findet in der aktuellen Ausgabe des iJUG-Magazins "Java aktuell" einen Artikel über "10 Years PatternTesting" (javaaktuell032012.pdf (pdf, 670 KB) ).

Die iJUG als Herausgeber dieser Zeitschrift ist ein Dachverband der Java User Groups im deutschsprachigen Raum, der auch die JUGS angehört.

Ansonsten besteht auch auf dem Java Forum Stuttgart am 5. Juli die Gelegenheit, die Geschichte von PatternTesting und einen Rückblick auf die letzten 10 Jahre life mitzuerleben (Track F4, 12:15 - 13:00).

On 23th March 2002 Matt Smith and Vincent Massol initiated PatternTesting to find some of the common anti patterns like a forgotten e.printStackTrace you can find in many projects.

2002 is also the year where asserts are provided with JDK 1.4. With this new keyword it is possible to place detectors in your code for better findings of programming errors. Together with PatternTesting it is possible to automate this process e.g. to find method calls which get null arguments or returns null as return value - a common cause for NullPointerExceptions.

Today is now released the jubilee release - PatternTesting 1.2.10-YEARS. One of the new features of this release is PatternTesting Agent which must be started as Java agent:

java -javaagent:patterntesting-agent-1.2.10-YEARS.jar ...

It provides the ClasspathMonitor of PatternTesting Runtime with the needed infos about the class loader to find unused classes or Jar files or to detect incompatible classes (this are classes with the same signature but different versions). The agent is only needed for class loaders which are not direct supported by the ClasspathMonitor (as e.g. is the case for the IBM JDK). For the normal Sun JDK you don't need it.

More infos how to use the ClasspathMonitor can be found in the PatternTesting Wiki. Look at the Hello World example in the section Getting Started.

Happy PatternTesting

Today I received a mail from Reikje who uses PatternTesting and who was the beta tester for the new ProxyRunner feature in 1.2.0. In his blog Testing just got better you can read about his experience of testing with PatternTesting.

Enjoy it.

Today there is a new release of PatternTesting available. What's new? First it can be now used as OSGi bundle. And second the support for parallel testing was extended:

• patterntesting.concurrent.experimental.ParallelProxyRunner
• patterntesting.concurrent.junit.ParallelSuite

In the wiki article Testing with PatternTesting you can read how to use it.

What's else new? Some testers (ComparableTester and RuntimeTester) were added, an uberjar for patterntesting-rt is now provided and some bugs are fixed. For more changes read the release notes.

Happy PatternTesting

Im aktuelle Javamagazin ist der Artikel "Ein Programmierer sieht rot" erschienen. Dazu erreichte mich die Frage, wie man mit Hilfe von PatternTesting JUnit-Tests mit Hilfe von Properties gruppieren kann, das in dem Artikel nur angedeutet wird. Hier die Auflösung: der Trick besteht einfach darin, dass man vor der Test-Methode (oder vor die ganze Test-Klasse) einfach ein @RunTestOn oder @SkipTestOn mit einer selbstdefinierten Property setzt:

    @Test
    @SkipTestOn(property="SKIP_EXPORT_TEST")
    public void testEmptyExport() throws IOException {
        ...
    }

Sobald dieser Test mit der Option -DSKIP_EXPORT_TEST aufgerufen wird, wird der Test ausgeblendet. Wichtig dabei ist, dass der SmokeRunner oder ParallelRunner als Testrunner verwendet wird:

@RunWith(SmokeRunner.class)
public final class DatenpaketTest {
    …
}

Man kann auch mehrere Optionen angeben:

    @Test
    @SkipTestOn(property={"SKIP_IMPORT_TEST","SKIP_EXPORT_TEST"})
    public void testImportExport() throws IOException {
        ...
    }

Sobald eine der beiden Properties gesetzt ist, wird der Test ausgeblendet.

Das Ganze kann man mit @RunTestOn auch andersrum machen: man definiert sich eine Property, und nur wenn diese Property gesetzt ist, wird der Test auch ausgeführt. Problematik dabei ist, dass man hier immer alle Properties angeben muss, wenn man alle Tests ausführen will. Ist keine Property gesetzt, wird auch kein Test ausgeführt. Ansonsten sind aber beide Verfahren gleichwertig.

Zwei Tage durften wir auf den Stuttgarter Test-Tagen 2011 das Thema "Testen" vertiefen, das ansonsten oft zu kurz kommt. Während es bei den letzten Test-Tagen über 40 Anmeldungen waren, waren es dieses Jahr leider nur 18 Stück - vermutlich eine Auswirkung der parallel stattfindenden JAX in Mainz.

Trotzdem (oder vielleicht gerade deswegen) waren die Teilnehmer sehr zufrieden mit der Veranstaltung. Einzig die Frische des Raums in der Alten Scheuer wurde bemängelt. Der Workshop-Charakter (morgens Vortrag, mittags praktische Übungen) wurde dankbar aufgenommen, und jeder Teilnehmer konnte die Theorie vom Vormittag nachmittags ausprobieren (s. Bilder vom Workshop).

Da wir dieses Mal WLAN-Anschluss hatten, nahmen einige Teilnehmer dies zum Anlass, unter #sttt2011 zu twittern oder zu bloggen. Auch die Referenten nutzen das Internet für Aktualisierungen. So wurde noch während der Test-Tagen eine Mac-Version für den InspectIT-Client nachgereicht (www.inspectit.eu/downloads/) und die inspectIT-Demo aktualisiert.

Auswertung Fragebogen

Kriterium	sehr gut (1)	gut (2)	befr. (3)	(4)	(5)	Schnitt
Umfang	7	6				1.46
Stoffvermittlung	6	5				1.45
Lernklima	11	2				1.15
Übungen	6	3	2			1.64
Unterlagen	2	7	2			2.00
Räumlichkeiten	4	6	3			1.92
Gesamteindruck	4	8				1.67

Was den Teilnehmern besonders gefiel

Ambiente, Atmosphäre
Aufteilung vormittags Vorträge, nachmittags Übungen
Überschaubarer Teilnehmerkreis
Gutes Konzept: Besser als reine Vorträge
Kleine Gruppen, angenehmes Klima
schön familiär
Viel Zeit für Workshops, intensives Arbeiten in kleinen Gruppen
Jubula, Bredex, Tag 2 war inhaltlich besser!
Systemtest nonstop
Die neue Workshopverteilung ist besser, da man ohne Streß die Übungen durchführen kann

Was den Teilnehmern nicht gefiel

Raumtemperatur zu kühl (mehrfach)
Von den Übungen hätte ich am 1. Tage gerne mehr besucht
sehr toollastig
Großer Installations- und Setupaufwand bei den Übungen
Übungen zu kurz
keine Fragerunde direkt nach den Vorträgen, da die Zeit zu knapp war
Anreise mit Auto schwierig (parken)
Stühle könnten bequemer sein
FitNesse, Gebit
Zu oft Pizza

Fazit

Das positive Feedback, das wir von den Teilnehmern und Referenten bekommen haben, beweist, dass Testen nicht langweilig sein muss und ermutigt uns, die Test-Tage in zwei Jahren zu wiederholen - in wärmeren Räumen und zu einem konflikt-freieren Termin.

Since Eastern PatternTesting 1.1.0 is released. Some deprecated APIs from 0.8 and 0.9 are now removed, the check methods of the different JUnit testers are now renamed to assertXxx and the ClasspathMonitor has now a much faster startup time. For more infos about all changes see the release history.

The Wiki article "Testing with PatternTesting" explains how you can use the different annotations and testers which are provided for unit testing. If you want to practice it come to the Stuttgarter Test-Tage 2011 or try it yourself.

Happy PatternTesting

Vor einigen Monaten hatten sich die DOAG (Deutsche Oracle Anwendergruppe) und verschiedene Java User Groups (darunter auch die JUGS in einem gemeinsamen Dachverband, der iJUG zusammengeschlossen. Ursprünglich war geplant, die Zeitschrift "Java aktuell" zum Java Forum Stuttgart rauszugeben - das hätte perfekt mit dem Vortrag "Pleiten, Pech und PatternTesting zusammengepasst, da genau zu diesem Thema auch ein entsprechender Artikel drin steht.

Na ja, jetzt sind es halt zwei Monate später. Aber wer Interesse daran hat, die Zeitschrift gibt es noch im gut sortierten Zeitschriftenladen...

Two objects which are equals should return the same hash code (and not the other way around, as some developers think).

...Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

This is corresponding Javadoc about the equals method. For those who forget this PatternTesting offers now an ObjectTester which checks classes with overwitten equals methods:

    ObjectTester.assertEquals(my.little.Dummy.class);

The ObjectTester will create with this call two Dummy objects to check the implementation. If it is not ok an Assertion Error will be thrown.

You can also add a package to check if all classes in the package have a correct equals/hashCode implementation:

    ObjectTester.assertEquals(Dummy.class.getPackage());
    ObjectTester.assertEqualsOfPackage("my.little");

Both calls are identical. You can also exclude classes from this check. This is sometimes necessary for classes where the constructor produces different objects (as is the case for the Date class, for example).

In a similar way you can check classes with the SerializableTester and CloneableTester if they are really serializable or clonable.

Today PatternTesting 1.0.1 was released. Some feedback from the Java Forum Stuttgart and some minor bug fixes were included. For more info see the release notes.

If you use Maven PatternTesting is not yet sync'd to the Central Maven Repository (the ticket for upload is still "reopened"). So add labs.agentes.de/repository to your POM as described in Build with Maven.

The next event where you can watch PatternTesting live will be probably the gearconf in Düsseldorf. I plan to present a little drama with Christian Heise about a normal day in a developers life.

Stay tuned...