Dobre praktyki:

• każdy test powinien być niezależnych względem innych (konkretne zachowanie komponentu (zachowanie, a nie metoda publiczna) powinno być testowane tylko raz – w przeciwnym przypadku zmiana zachowania komponentu wymaga poprawy wielu różnych testów).

• testy powinny dotyczyć tylko metod publicznych (kontraktów), więc wyjściem do pisania testów powinny być dobrze zdefiniowane interfejsy.

• najpierw black box, później white box (implementacja testu w oparciu o opis funkcjonalny – często opis w interfejsie, później przegląd implementacji i dodatkowe testy)

• zbyt duża liczba assercji to problem! Jeśli testujemy funkcjonalność biznesową odpowiedzialną za np. zamykanie paczki z transakcjami to nie powinniśmy sprawdzać jednocześnie wszystkich własności paczki (tylko jej status).

• wywołania komponentów zależnych powinny być mockowane (poza warstwą DAO) – np. EasyMock – pozwala to na dużo łatwą ocenę miejsca wystąpienia błędu

• nazewnictwo:

• nazwa klasy (nie interfejsu) + Test

• metody: testowana metoda + scenariusz + wynik (np. removeApplicationIfActiveStateActiveStateException)

• testując komponenty biznesowe nie powinniśmy mockować obiektów DAO

• każdy test sam ustanawia dla siebie środowisko i po jego wykonaniu wszystkie zmiany na bazie testowej powinny być rollbackowane

Integer i7 = 7;
long l7 = 7L;
System.out.println(i7.equals(l7));

Wynikiem jest false.

public boolean equals(Object obj) {
	if (obj instanceof Integer) {
	    return value == ((Integer)obj).intValue();
	}
	return false;
}

String[] tablica = new String[] {"1", "2", "3", "4", "5"};
List<String> list = Arrays.asList(tablica);
// zmiana elementu 
list.set(0, "a");
for (String tab : tablica) {
    System.out.print(tab + " ");
}		
 
// dodanie nowego elementu
list.add("6");
for (String tab : tablica) {
    System.out.print(tab + " ");
}

Wynikiem powyższych instrukcji jest:

a 2 3 4 5
UnsupportedOperationException

Jak widać zmiana elementu listy została odwzorowana również w tablicy, natomiast dodanie elementu do tablicy zakończyło się wyjątkiem. Jest to spowodowane faktem, że lista faktycznie odwołuje się do tablicy, która zaalokowana jest na stercie i jej powiększenie, bez utworzenia nowej tablicy jest niemożliwe.

public static void checkedException() throws IOException {
    try {
        System.out.println("1");
        throw new IOException("Exception 1");
    } catch (FileNotFoundException e) {
        System.out.println("2");
        throw new IOException("Exception 2");
    } catch (IOException e) {
        System.out.println("3");
        throw e;
    } finally {
        System.out.println("4");
        throw new IOException("Exception 4");
    }
}

W bloku finally strumienie są zamykane, lecz metoda close() może wyrzucić wyjątek IOException.  Wywołanie poniższej metody:

try {
    checkedException();
} catch (IOException e) {
    System.out.println(e.getMessage());
}

wypisze na konsoli:

1
3
4
Exception 4

Można by przypuszczać, że wypisany zostanie “Exception 1″, jednak jako ostatni wyrzucony zostaje wyjątek w bloku finally i to on jest przekazywany dalej. Podobna sytuacja dotyczy zwracania wartości w bloku finally.

public class A {
    public String getName() { return "A"; }
 
    public static void main(String[] args) {
        Set<B> bSet = new LinkedHashSet<B>();
        Set<A> aSet = bSet; // THIS WILL NOT COMPILE
        aSet.add(new C());
 
        B[] bTable = new B[2];
        A[] aTable = bTable;
        aTable[0] = new B();
        aTable[1] = new C(); //ArrayStoreException
    }
}
 
public class B extends A {
    @Override
    public String getName() { return "B"; }
}
 
public class C extends A {
    @Override
    public String getName() { return "C"; }
}

Załóżmy, że istnieje możliwość przypisania obiektu LinkedHashSet<B> do zmiennej referencyjnej Set<A>. Na nowej referencji można wywołać metodę aSet.add(new C()), czego skutkiem tego jest dodanie obiektu C (podtypu klasy A) do trzymanego na stercie obiektu LinkedHashSet<B>, co jest błędne. Należy jednocześnie pamiętać, że typy genetyczne są zapominane podczas kompilacji i w rzeczywistości w pamięci istnieje obiekt Map. W związku z powyższym przy próbie rzutowania obiektu LinkedHashSet<B> na Set<A> otrzymujemy błąd kompilacji.

Mając analogiczną sytuację dla tablic nie otrzymujemy żadnego powiadomienia o błędzie od kompilatora podczas rzutowania. Dopiero po uruchomieniu dostajemy wyjątek: ArrayStoreException. Jest on związany z próbą dodania do tablicy niezgodnego typu obiektu. Należy pamiętać, że w momencie tworzenia tablic zapamiętują one swój typ.

Z powyższego przykładu widać, że korzystanie z kolekcji jest bezpieczniejsze niż z tablic.

13 maja

• Object Teams: The Next Dimension of Modularity, Stephan Herrman
• Easy to Use Highly Available Java Database Access, Craig L Russell
• The High Availability Non-Stop, Fault-Tolerant Services Tutorial, Eugene Ciurana
• Java in high-performance computing, Dawid Weiss
• Gradle – A Better Way To Build, Hans Dockter
• Get ‘em before they get you, Vaclav Pech

14 maja

• Let it crash: using Actors for fault-tolerance, scalability and concurrency, Jonas Bonér
• JDK 7 Update, Dalibor Topic
• Squeezing Java Performance: When you need a little more, Thomas Enebo
• Beyond Agile, Andrea Provaglio
• Apache Camel as a DSL for system integration, Roman Kalukiewicz
• Object Oriented for nonbelievers, Bruno Bossola
• JSR-299 Context and Dependency Injection, Mark Struberg

Najciekawsze wykłady poprowadzili: Eugene Ciurana,  Dawid Weiss, Hans Dockter, Dalibor Topic, Roman Kalukiewicz, Bruno Bossola. Konferencja zakończyła się powodzeniem, choć część tematów traktowana była zbyt ogólnie. Najbardziej interesującym tematem okazał się dla mnie Apache Camel, narzędzie pozwalające na integracje wielu serwisów, oparte na EIP (Enterprise Integration Patterns). Dzięki DSL (Domain Specific Language) przykłady pokazane podczas prezentacji okazały się bardzo zwięzłe i proste do analizy.