Tdd + Uml. It's easy with Architexa.

Who loved the TDD technique generally think that his test sufficiently documents the code.
"I do it (tests). Do you see these tests. It's easy". They said.
 Then it is not necessary to draw some UML Diagrams.

 Are you sure?

 Instead, I believe that UML diagram add value to Tdd process. I think that UML could be produced during tdd phases.
 We need a powerful tool in order to obtain that.
I think that Architexa has some interesting feature that make it the proper tool in order to join TDD and UML.
 It's more easy to start with blank diagram and step by step, test by test, to reach a final job with code and diagrams.

 I would propose you this example: (First. It enough uses drag and drop method or click something to do all. Architexa is plugin of Ecplise.)  Then, We have a Subscriber of funds which would to do an order.

 Begin with test:


 We'll have class "Subscriber" following the TDD rules:


 then, We can create the first version of Layered Diagram: click on menù: Architexa/Open new Diagram editor/new layered Diagram after We can drag and drop the Subscriber class into the Diagram Window. And we can see:

                  

 After We would have an order: 

 Then we have Order and Product classes: 

 Drag and Drop these classes and We have: 

   

 By Diagram, We select all classes and Right click And choose "Open in Diagram/Class Diagram" on popup menu. After we have a diagram like:

   

 Then, now we must complete the test of Subscriber: After we obtain this: Then, We can add some detail: 

   

 We select Order and right click and choose the item: Open in diagram / Sequence Diagram on popup menu. We can see a new Sequence Diagram. We have this sequence diagram by clicking to "2 member" and to some arrows: 

   

 We are quickly created: 2 tests, 3 classes and 3 UML diagrams. It is unbelievable.

Junit e Maven, finalmente amici!

... Usare il plugin di Junit per Eclipse con un multi progetto complesso gestito con Maven
a volte può risultare un operazione molto difficile. Il plugin di Maven di Eclipse in verità deve
crescere ancora molto.
Si ha spesso la necessità di aver dei files di risorse filtrati secondo specifiche politiche configurate in Maven.
Purtroppo per Junit è sconosciuta la gestione dei filtri di maven, quindi spesso non si possono
eseguire i test da Eclipse semplicemente perchè tali files necessari non vengono preventivamente filtrati.
Ci si ritrova per esempio a non poter eseguire un test usando "Spring" a causa dell'impossibilità di caricare
il contesto, descritto nel file "application.xml", perchè questo risulta non filtrato ...

Come si può risolvere tal problema?
Maven fornisce la soluzione. Le operazioni consistono nell'eseguire manualmente il filtraggio delle risorse:

mvn process-test-resources -P

avendo configurato opportunamente il "Pom.xml" file alla sezione "resources".

ad es:

 <testresources>
  <testresource>
   <directory>src/test/resources
   <filtering>true
   <includes>
    <include>**/**
   </includes>
   <targetpath>../filtered-resources</targetpath>
  </testresource>
 </testresources>

Molto importante come vedremo in seguito è il nodo "targetPath". Esso indicherà a Maven la directory nel quale saranno
generati i files di riscorse.
Lanciando il comando otteremo qualcosa come di seguito:

[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] Copying 18 resources to ../filtered-resources
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10 seconds
[INFO] Finished at: Sat May 29 12:41:47 CEST 2010
[INFO] Final Memory: 20M/37M
[INFO] ------------------------------------------------------------------------

Ultima operazione sarà quella di impostare la directory "targetPath", nell'esempio: <project>/target/filtered-resources,
nel classpath del test desiderato:

Da Eclipse:

1) Cliccare su "run/run configuration" (o debug in caso)
2) Cliccare la voce "Classpath"
3) Selezionare la voce "User Entries" e cliccare il pulsante "Advanced"
4) Selezionare la voce "Add folder" e procedere alla scelta della cartella identificata con "targetPath"
5) Usando il tasto "up" portare la cartella appena aggiunta alla prima posizione in "User Entries"
6) "Apply" e "run" del test finalmente felici di poterlo fare.

Testng - uso del tag package

Qualche post fa si è definito un test tramite questa porzione di xml di configurazione:

<parameter name="parameter"  value="Questo è il parametro"/>
<test name="Test dei parametri">
 <classes>
  <class name="it.testng.parameters.ParametersTest" />
 </classes>
</test>

Può nascere durante i test la volontà di eseguire tutti i test riferendosi al package anzichè ad una specifica classe. Niente di più semplice! E' sufficiente utilizzare il tag <packages> come mostrato di seguito:

<test name="Test Package">
 <packages>
   <package name="it.testng.mypackage"></package>
 </packages>
<test>

TestNg - Passaggio dei parametri

Fin qui le differenze tra TestNg e Junit non appaiono così evidenti.Ma TestNG è un framework avanzato e non vi è bisogno di molto per mostrarlo.
Per esempio con testNg non c'è più la necessità di creare costanti o qualsiasi altro metodo per ottenere dei parametri (dati) da utilizzare nei singoli test.
TestNG fornisce un'annotazione @Parameter utile per passare dati ai singoli metodi di test.
Per esempio:
Creare un test http://tommyalf.blogspot.com/2008/05/testng-primo-test.html

package it.testng.parameters;

import static org.testng.Assert.*;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;

public class ParametersTest {

  @Parameters("parameter")
  @Test
  public void parametersTest(String parameter) {
    assertEquals("Questo è il parametro", parameter);
  }
}
 

Quindi il metodo parametersTest verrà invocato dal framework passando il parametro relativo a parameter.
Il valore di parameter si imposta sempre tramite il file testng.xml:

<parameter name="parameter"  value="Questo è il parametro"/>
<test name="Test dei parametri">
 <classes>
  <class name="it.testng.parameters.ParametersTest" />
 </classes>
</test>

TestNG.zip V1.0 - Prima Versione demo di utilizzo

Clicca per eseguire il download della prima versione demo.
Potrai ottenere una prima applicazione dei test con il framework TestNg.

TestNg - Dipendenze (SoftDependencies)

SoftDependencies è il metodo di TestNg per eseguire i test rispettando l'ordine delle dipendenze,
senza però che il successo o il fallimento di una dipendenza dipenda da un'altra.

Esso è possibile realizzarlo aggiungendo il
parametro alwaysRun=true nell'annotazione @Test

@Test(alwaysRun=true)

TestNg - Dipendenze (HardDependencies)

Spesso è necessario eseguire i test seguendo un ordine specificato.
TestNg permette di aver questa funzionalità secondo due modelli:

HardDependencies : i test vengono eseguiti secondo l'ordine costituito dalle dipendenze. Se il test fallisce verrà notificato come SKIP e non FAIL.

Ad esempio, se ho un test "tradizionale" nel quale sono presenti 20 dipendenze delle quali soltanto 10 falliscono avrò questo risultato:

10 test eseguiti con successo (dipendenze non fallite) e 11 failure.

In questo modo sono portato a pensare che i miei test sono falliti e che devo fare 11 fix. Invece TestNG con l'HardDependencies dimostra chiaramente che dei 21 test, 10 sono le dipendenze fallite mentre il test che dipende da questi 10 test è skippato. Il report infatti è:

10 test eseguiti con successo (dipendenze non fallite), 10 failure (dipendenze fallite), 1 SKIP (test dipendente).

TestNg mostra in modo più accurato ciò che succede durante l'esecuzione dei test.

TestNG - Gestione dei gruppi di test

E' anche possibile definire dei gruppi nei test. Così si possono realizzare test divisi per : 'unit test', 'integration test' ecc.

Ciò può essere realizzato tramite l'annotazione @Test e con il parametro 'groups'.




package it.testng.samplegroup.test;

import org.testng.annotations.Test;


public class SampleGroupTest {

@Test(groups = {"gruppo 1", "gruppo 2"})
public void TestMethod1() {
System.out.println("Metodo 1");
}

@Test(groups = {"gruppo 2"})
public void TestMethod2() {
System.out.println("Metodo 2");
}

@Test(groups = {"gruppo 3"})
public void TestMethod3() {
System.out.println("Metodo 3");
}

}




e configurando il file testNg.xml aggiungendo :


<test name="TestGroup">
<groups>
<run>
<include name="gruppo 2" />
</run>
</groups>
<classes>
<class name="it.testng.samplegroup.test.SampleGroupTest" />
</classes>
</test>



E' anche possibile escludere dai test un gruppo

inserendo all'interno di il tag
es:


Si può realizzare anche una gerarchia dei gruppi



@Test(groups = { "main" })
public class All {

@Test(groups = { "little" )
public void method1() { ... }

public void method2() { ... }
}


il method2 riferisce al gruppo "main" invece il method1 viene eseguito per i test di "main" che quelli di "little"

TestNg - Primo Test

Dopo aver creato il Progetto maven SampleOneTestNG in eclipse procedere
con il creare una classe nei test di nome SampleOneTest così composta:

package it.testng.sampleone.test;

import org.testng.annotations.Test;

@Test
public class Test1 {
public void sampleOne() {
System.out.println("ok!");
}
}

da notare che l'annotazione Test ha lo stesso nome di quella di junit ma riferisce ad un jar diverso (org.testng.annotations.Test)

Successivamente è necessario creare il file testng.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="SuiteProva" verbose="1" >
<test name="Prova1" >
<classes>
<class name="it.testng.sampleone.test.SampleOneTest" />
</classes>
</test>

</suite>