• 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.