• Etape 1  et 2 : Extraction des données dans la base réel

Il s’agit de faire une snapshot de la base avant l’execution du test. On va extraire que les données qui nous intéresse et non l’ensemble de la base. Il faut écrire un main java :

....
PropertiesConfiguration propertiesConfiguration = new PropertiesConfiguration("maProp.properties");
String url = propertiesConfiguration.getString("URL");
 String user = propertiesConfiguration.getString("USER");
 String password = propertiesConfiguration.getString("PASSWORD");
 String schema = propertiesConfiguration.getString("SCHEMA");
// database
connection Class.forName("oracle.jdbc.driver.OracleDriver");
Connection jdbcConnection = DriverManager.getConnection(url, user, password);
IDatabaseConnection connection = new DatabaseConnection(jdbcConnection, schema);
IDataSet createDataSet = connection.createDataSet();
FlatDtdDataSet.write(createDataSet, new FileOutputStream("src/main/resources/maBase.dtd"));
QueryDataSet partialDataSet = new QueryDataSet(connection);
partialDataSet.addTable("TABLE_PERSONNE", "select * from PERSONNE where AGE < 18");
FlatXmlWriter datasetWriter = new FlatXmlWriter(new FileOutputStream("jdd.xml"));
datasetWriter.setDocType("maBase.dtd"); datasetWriter.write(partialDataSet);
 ... 

Db unit nous fourni un jeu de test au format xml qu’on placera dans les ressources de nos tests.

• Etape 3 , 4 et 5   : écriture du test et load du jdd en base mémoire et extraction du resultat

On doit à présent loader le jdd.xml dans notre base H2. La encore Db unit nous fournit des outils pour le faire.

IDatabaseTester databaseTester = MonDBmemoire.getInstance();
databaseTester.setSetUpOperation(DatabaseOperation.CLEAN_INSERT);
databaseTester.setDataSet(getDataSetFromFile("path/chemin/jdd.xml"));
databaseTester.onSetup();
...
// mon traitement pour le test
...
//dump de la base apres execution du traitement
private String[]  nomTables={"PERSONNE ", "VILLE"};
IDataSet databaseDataSet = connection().createDataSet(nomTables);
FlatXmlDataSet.write(databaseDataSet, new FileOutputStream("monDump.xml"));

A cette étape on a extrait de la base mémoire, les données voulues apres l’execution du test. Il faudra faire une analyse fonctionnelle, afin de s’assurer que le résultat obtenu est conforme à ce qui est attendu.

Pour ce faire on peut  soit analyser le fichier xml (monDump.xml) de sortie ou directement requeter en base mémoire. Si vous opter pour la dernière solution n’oublier pas de commiter vos donner en mémoire après le test ( setAutoCommit(false))   puis lancer la commande  java -cp h2*.jar org.h2.tools.Server pour activer  le GUI de H2 .

Si le résultat vous convient, placer le fichier monDump.xml dans les ressources de votre test puis  passer à l’étape suivante sinon revoir votre code.

• Etape 6 : finalisation du test avec assertion 

A ce stade vous avez valider les données qui ont été inserées/updatées/supprimées en base. Il ne reste plus qu’à comparer l’état de la base mémoire avec le fichier monDump.xml.  Dans notre classe de test on supprimera la partie d’extraction dump qu’on remplcera par le code suivant :

...
private String[]  nomTables={"PERSONNE ", "VILLE"};
IDataSet databaseDataSet = connction.createDataSet();
IDataSet expectedDataSet = getDataSetFromFile("path/vers/chemin/monDump.xml");
for (String tb: nomTables) {
ITable actualTable = databaseDataSet.getTable(tb);

ReplacementTable expectedTable = new ReplacementTable(expectedDataSet.getTable(tb));
expectedTable.addReplacementObject("${date-today}", new SimpleDateFormat("yyyy-MM-dd").format(new Date()));
Assertion.assertEquals(new SortedTable(expectedTable, actualTable.getTableMetaData()),new SortedTable(actualTable, actualTable.getTableMetaData()));

• Dependance Maven

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>fr.cadjee.testUI</groupId>
	<artifactId>CadjeeSelenium</artifactId>
	<version>1.0</version>

	<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-surefire-plugin</artifactId>
			<configuration>
				<testFailureIgnore>true</testFailureIgnore>
			</configuration>
		</plugin>
	</plugins>
</build>

	<dependencies>
		<dependency>
			<groupId>org.seleniumhq.selenium</groupId>
			<artifactId>selenium-java</artifactId>
			<version>2.46.0</version>
		</dependency>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.11</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>

• Selenium IDE 

Toutes les actions sont enregistrées puis exportable via le Menu File > Export Test Case As …> Java Junit 4 / Web Driver. Les autres options (WebDriver Backed…ect ) seront bientôt obsolètes. Ils sont la uniquement pour assurer la rétro comptabilité entre la version selenium 1 RC et selenium 2 WebDriver.

Les classes java sont  à importer dans votre projet sous forme de test ou main exécutable. La forme ‘testCase’ permet d’automatiser plus naturellement votre application avec Maven et Jenkins.

• Forcer Selenium à utiliser un autre navigateur différent du navigateur par défaut 

Les test UI peuvent s’exécuter sur différent navigateurs sachant que le navigateur par défaut de Selenium est FireFox. Pour cela il va chercher dans le Path de votre OS le chemin vers votre FireFox. Dans mon cas je veux plutôt utiliser un FireFoxPortable ( donc non présent dans le PATH):

</pre>
public class SeleniumForFirefoxCase {

protected static WebDriver driver;
protected static String baseUrl;
protected boolean acceptNextAlert = true;
protected static StringBuffer verificationErrors = new StringBuffer();
private static final String URL_EXE_FIREOX = "C:\\Documents\\selenium\\FirefoxPortable\\FirefoxPortable.exe";

...

@BeforeClass
public static void init() {
File pathToBinary = new File(URL_EXE_FIREOX);
FirefoxBinary ffBinary = new FirefoxBinary(pathToBinary);
FirefoxProfile firefoxProfile = new FirefoxProfile();
driver = new FirefoxDriver(ffBinary, firefoxProfile);
}

}

J’ai déclarer le driver en static afin d’avoir une seule instance du firefox pour mes tests. Cela évite d’ouvrir plusieurs fenêtres de fireFox. Je peux ainsi enchaîner mes tests sur la même fenêtre.
Pour info il est possible d’exécuter les tests sur IE, Chrome, Safari…Ect et même en mode non graphique via le driver HtmlUnitDriver.

• Form Based Authentication : Fenêtre d’authentification 

Ces fenêtres vous demandent de vous authentifier pour accéder à une page donnée. Souvent l’oeuvre d’un JAAS ou Valve défini au sein de votre application:

L’IDE ne sait pas enregistrer cette action. Il va falloir passer par programmation. L’astuce est simple: ajouter dans l’url le  mot de passe et le login :

public class SeleniumForFirefoxCase {
...
protected static String baseUrl;

...

@BeforeClass
public static void init()
{
...
baseUrl = "http://login:motDePasse@localhost:8080/monAppli/";
driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
driver.get(baseUrl);

...
}

• Gestion des pop up 

Pour gérer la pop up il faut indiquer au driver de switcher de fenêtre car par défaut  c’est toujours la fenêtre principale qui est prise en compte:

@Test
public void Scenario1_OuverturePopUp() throws Exception {

// ouverture de la pop up

driver.findElement(By.xpath("//a[contains(@href, \"lienPopUp')\")]")).click();

// On recupere l'id des fenetres actives
Set<String> windowId = driver.getWindowHandles();

Iterator<String> itererator = windowId.iterator();

//1er fenetre
String mainWinID = itererator.next();
System.out.println(mainWinID);
//2de fenetre le pop up
String popUpID = itererator.next();
System.out.println(popUpID);

//On switch de fenetre
driver.switchTo().window(popUpID);
System.out.println(driver.getTitle());
Assert.assertEquals("Refus demande", driver.getTitle());
driver.findElement(By.name("commentaire")).clear();

//envoie d'une valeur dans la zone de texte de la pop up
driver.findElement(By.name("commentaireRefus")).sendKeys("test pop up selenium");

• Conclusion

L’intégration par Maven permet l’exécution des tests de la même façon q’un test unitaire classique. Mais ne nous y méprenons pas, Selenium n’a pas vocation à remplacer un TU et vis versa!

Pour aller un peu plus loin, il est même conseillé d’utiliser une base mémoire tel que H2. On peux également utiliser un serveur Jetty plus léger et plus rapide. Enfin Une connaissance de Xpath est obligatoire pour mener à bien votre intégration de Selenium.

Sub generatorScript()

FileNumber = FreeFile
fileSaveName = Application.GetSaveAsFilename( _
InitialFileName:="GeneratorICAJEE", fileFilter:="Text Files (*.sql), *.sql", Title:="Creation script")
Open fileSaveName For Output As #FreeFile

For i = 1 To 740
txt = txt & " update personne set personne_id= : " & Sheets(1).Cells(i, 9) & " where personne_id= " & Sheets(1).Cells(i, 3) & " and  nom_personne= " & Sheets(1).Cells(i, 1) & ";" & Chr(10)
Next i

Print #FileNumber, txt
Close #FileNumber
End Sub

Le Chr(10) permet un retour chariot pour chaque ligne traitée.

Une formation de 4 jours riches en concepts et TP. Voici les notions que nous aborderons :

• Architecture 3 tiers
• EJB2 vers EJB 3
• JNDI : Datasource…etc
• JPA
• WebServices
• JMS queue/topic
• MDB
• Création d’un projet fromscratch avec Maven
• Présentation de Jboss ( noyau et fichier de conf)
• Administration par UI, JBOSS CLI, et conf XML en mode standalone
• Déploiement d’une application dans JBOSS
• Analyse et explication de la log server
• Mise en place d’un custum LOGGER à partir de Jboss
• Changer le LEVEL LOGGER à chaud sans redéployer l’application
• JMX : supervision au runtime d’une application via JConsole et VisualVM
• Création d’une web appli (WAR) – Servlet/JSP
• Mise en place d’un politique de sécurité avec JAAS
• Sécurisé l’accès à l’application avec SSL
• Présentation de Jboss domain et le management de n cluster
• Loadbalancing avec mod jk
• Mise ne place de la haute dispo avec Jboss AS7.1.1

1. Générer les pojos java (décoré des annotations JAXB).
2. faire du marshalling / unmarshalling.

Nous nous intéresserons au point 1. Comment bien gérer cette phase de génération? Comprenons que ces POJOs générer sont, d’une part soumis au changement pour toute modification du XSD et d’autre part n’a pas lieu de faire partie intégrante de votre projet au sens package java. Le seul élément qui doit se retrouver dans votre projet c’est la XSD lui même. L’idée est donc d’avoir la XSD au niveau de nos ressources projets et de demander à Maven de s’occuper de générer les pojos à partir de la XSD puis d’ajouter ces derniers au classpath de notre livrable (jar,war,ear…etc)  à chaque build de Maven.

Prenons une XSD connue du milieu bancaire (flux SEPA) :  https://github.com/w2c/sepa-sdd-xml-generator/blob/master/validation_schemes/pain.008.003.02.xsd.

• Etape 1 : Bien positionner la XSD

Placer la XSD dans scr/main/ressources/maXSD 

• Etape 2 : Configuration de Maven

Dans notre pom maven nous ajoutons le plugin pour la génération des POJOS. Il convient d’indiquer le chemin de la xsd ainsi que le nom du package qu’on souhaite donner pour la génération.

</pre>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<executions>
<execution>
<id>xjc</id>
<goals>
<goal>xjc</goal>
</goals>
<configuration>
<schemaDirectory>src/main/resources/xsd</schemaDirectory>
<packageName>fr.cadjee.sepa.jaxb</packageName>
</configuration>
</execution>
</executions>
</plugin>
<pre>

•  Etape 3 : C’est fini…lancer le build

Lancer votre mvn clean install  :

voici un aperçu général de l’arborescence:

On peut bien entendu gérer plusieurs XSD dans des répertoires différents soit en ajoutant une autre exécution ou en utilisant le fichier xjb.

Commencons par le commencement: Dépendance Maven

<dependency>
  <groupId>org.jboss.weld.servlet</groupId>
  <artifactId>weld-servlet-core</artifactId>
  <version>2.2.8.Final</version>
</dependency>
<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>javax.servlet-api</artifactId>
   <version>3.0.1</version>
   <scope>provided</scope>
</dependency>
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>jstl</artifactId>
  <version>1.2</version>
</dependency>
 

Classes Java de la couche Service et Buisness

Ces classes feront une simple opération d’addition entre 2 valeurs.

package fr.cdi.servlet;

public interface ICalcul {
	public int addition(int a,int b);
}
 

Ci dessous une implémentation de l’interface ICalcul. L’annotation @Default et @Any  est ici facultative car nous avons qu’une seule implémentation possible.  Ces annotations s’appellent un Qualifer.  La spécification de la JSR 299 propose des qualifers par défauts : @Default, @Any, @Named, @New.  Ils permettent à CDI de savoir quelle implémentation injecter. Dans le cas où rien n’est précisé, 2 annotations sont implicitement ajoutées par CDI : @Default et @Any. Comme je vous l’ai dit, dans notre cas nous n’en avons qu’une seule donc aucune ambiguïté à ce niveau. Nous reviendrons plus tard sur ces notions de Qualifier dans un autre billet.  Retenez juste qu’une implémentation injectable aura par défaut 2 types de Qualifer et ce, même si le développeur ne le précise pas : default et any !

package fr.cdi.servlet;
import javax.enterprise.inject.Default;

@Default
@Any
public class CalculBuisness implements ICalcul {

	public int addition(int a,int b){
		return a+b;
	}
}
 

Notons la première présence de l’annotation @Inject sur l’attribut de classe. Par cette simple annotation la classe CalculBuisness est automatiquement injectée grâce au qualifier @Default.  L’avantage considérable est ici de découpler le code d’une implémentation particulière. On aurait pu écrire aussi @Inject @Default private ICalcul calculBuisness ou @Inject @Default  @Any private ICalcul calculBuisness.

package fr.cdi.servlet;
import javax.inject.Inject;

public class CalculeService {

	@Inject
	private ICalcul calculBuisness;

	public int addition(String  a,String  b){
		return calculBuisness.addition(Integer.parseInt(a), Integer.parseInt(b));
	}
}
 

La servlet

Même principe que précédemment on injecte par annotation la classe CalculeService. L’injection doit se faire de bout en bout c.à.d de la Servlet jusqu’à la dernière classe appelée ( classe buisness).

package fr.cdi.servlet;

import java.io.IOException;
import javax.inject.Inject;
import javax.servlet.GenericServlet;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebServlet;

@WebServlet(value="/addition", name="servletCDI")
public class ServletCDI extends GenericServlet{

	@Inject
	private CalculeService calculeService;

	@Override
	public void service(ServletRequest req, ServletResponse res)
			throws ServletException, IOException {

		String val1 = req.getParameter("val1");
		String val2 = req.getParameter("val2");
		int resultat = calculeService.addition(val1, val2);
		req.setAttribute("resultat", resultat);
	req.getRequestDispatcher("/WEB-INF/index.jsp").forward(req, res);
	}
}
 

Le web.xml

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>

  <display-name>Archetype Created Web Application</display-name>
    <resource-env-ref>
    <resource-env-ref-name>BeanManager</resource-env-ref-name>
    <resource-env-ref-type>javax.enterprise.inject.spi.BeanManager</resource-env-ref-type>
  </resource-env-ref>
</web-app>
 

Enfin le fameux fichier bean.xml

Ce fichier est presque vide est doit être au même niveau que le web.xml (WEB-INF). Le bean.xml permet de préciser au serveur web ou application qu’une injection par CDI est à prévoir. Le serveur va donc scanner le projet à le recherche des @Inject. Tous les objets annotés seront instanciés par WELD dans un conteneur dit « léger ». Le fichier bean.xml à d’autre utilité qu’on verra dans un autre billet. Contentons nous du strict minimum pour le moment

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                           http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
       version="1.1" bean-discovery-mode="all">
</beans>
 

la JSP

<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c"%>
<html>
<head>
<body>
	<h1>Welcome CDI tuto</h1>
	<c:out value="${resultat}"/>

</body>
</head>
</html>
 

Voici le résultat simple mais efficace.

L’injection n’est plus l’affaire d’un spécialiste Spring. Elle est belle et bien démocratisée et facile d’utilisation avec la JEE 6. Il serait dommage de s’en priver n’est-ce pas?

Ca se passe ici : javax.validation.*. 

Les dépendances Maven nécessaire: 

<dependency>
   <groupId>javax.validation</groupId>
   <artifactId>validation-api</artifactId>
   <version>1.0.0.GA</version>
</dependency>
<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator-annotation-processor</artifactId>
  <version>4.1.0.Final</version>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.5.6</version>
</dependency>

Un bean Personne bien décoré

 
public class Personne{

	@NotNull(message="le nom est obligatoire")
	@Size(max=10)
	private String nom;
	@AssertTrue(message="il faut etre beau")
	private boolean isBoGoss;
	@Min(value=18, message= "Il faut avoir + de 18 ans")
	private int age;
	@Past
	private Date datenaissance;
	@Pattern(regexp="[0-9]{4}",message="code CB non valide desolé :-(")
	private String codeCB;
	
	public String getNom() {
		return nom;
	}

	public void setNom(String nom) {
		this.nom = nom;
	}

	public boolean isBoGoss() {
		return isBoGoss;
	}

	public void setBoGoss(boolean isBoGoss) {
		this.isBoGoss = isBoGoss;
	}

	public int getAge() {
		return age;
	}

	public void setAge(int age) {
		this.age = age;
	}

	public Date getDatenaissance() {
		return datenaissance;
	}

	public void setDatenaissance(Date datenaissance) {
		this.datenaissance = datenaissance;
	}

	public String getCodeCB() {
		return codeCB;
	}

	public void setCodeCB(String codeCB) {
		this.codeCB = codeCB;
	}

}

L’écriture des annotations est très claire et intuitive. On peut également personnaliser le message en cas d’erreur. L’API se chargera donc de lire ces annotations et d’appliquer la règle qu’on lui aura spécifiée. Par exemple dans le cas de la date de naissance, l’API vérifiera que la date du bean est antérieure à la date courante.

Validation du Bean

public static void main(String[] args) throws ParseException {

		Personne p = new Personne();
		p.setNom("CADJEE");
		p.setBoGoss(false);
		p.setAge(16);

		SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd/MM/yyyy");
		String date="19/04/1984";
		p.setDatenaissance(simpleDateFormat.parse(date));
		p.setCodeCB("007");

		ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
		Validator validator = factory.getValidator();

		Set<ConstraintViolation<Personne>> constraintViolations =validator.validate(p);
		StringBuffer sbf = new StringBuffer();
		if (constraintViolations.size() > 0) {
			 sbf.append("Paramètres invalides : ");
			for (ConstraintViolation<Personne> contraintes : constraintViolations) {
				sbf.append(contraintes.getMessage()).append(" - ");

			}

		}else{
			sbf.append(" tout est ok, circulez! ");
		}

		System.out.println(sbf);
	}

La validation passe par l’objet javax.validation.Validator. On récupère cette objet via la factory ValidatorFactory.  Le Validator stocke l’ensemble des erreurs dans un Set. Libre à nous de gérer ces messages à notre guise (Exception,Warning…etc).
Sachez qu’il est également possible de créer notre propre contrainte et annotation de valisation. Je vous laisse découvrir tout cela dans l’excellent article: La validation des données

Un bean Personne avec constructeur privé

public class Personne {
	private String nom;

	private Personne() {
	}

	public String getNom() {
		return nom;
	}

	public void setNom(String nom) {
		this.nom = nom;
	}

Pour instancier cet objet utilisons l’outillage java.lang.reflect.*

public class Genericite {

	public static <T> T instanceObject(Class<T> clazz) throws InstantiationException, IllegalAccessException, SecurityException, NoSuchMethodException, IllegalArgumentException, InvocationTargetException{
		Constructor<T> defaultConstructor =  clazz.getDeclaredConstructor();
		defaultConstructor.setAccessible(true);
		T t = defaultConstructor.newInstance();
		return t;
	}

le setAccessible(true) nous permet en quelque sorte de « hacker » cette classe et changer la visibilité d’un constructeur.

	public static void main(String[] args) throws InstantiationException, IllegalAccessException, SecurityException, NoSuchMethodException, IllegalArgumentException, InvocationTargetException {
		Personne p = Genericite.instanceObject(Personne.class);
		p.setNom("Isma");
		System.out.println(p.getNom());
	}

Ce mécanisme est très utilisé dans les framework tel que Spring.

Le réflexe de recourir au service de UtraEdit est une solution. Mais Eclipse offre déjà cette fonctionnalité bien pratique, alors pourquoi s’en priver ?

Il suffit juste de passer en mode sélection par colonne avec le raccourci magique suivant :Alt+Shift+A ( même raccourci pour revenir en mode sélection ligne).

PS : ce raccourci n’est pas présent dans le fameux Crt+Shift+L