Wiki -> FitServer.exe -> FitServer.exe.config -> AssemblyTest

Pour résoudre se problème, il existe plusieurs possibilitées :

Copier le contenu de votre fichier de configuration dans le fichier FitServer.config
Le probleme avec cette methode c’est qu’il faut autant de FitServer.exe que de fichier de configuration différent :

• Assembly 1
• • Assembly1.dll
  • Assembly1.dll.config
  • FitServer.exe
  • FitServer.exe.config

Avec FitServer.exe.conf = Assembly1.dll.config

• Assembly 2
• • Assembly2.dll
  • Assembly2.dll.config
  • FitServer.exe
  • FitServer.exe.config

Avec FitServer.exe.conf = Assembly2.dll.config

De plus il faut configurer les pages Wiki pour qu’elles éxécutent le bon FitServer en fonction de l’assembly a tester.
Si on a 10 assemblies a tester ca peut devenir compliqué.

Utiliser la Suite Configuration
FitServer.exe peut être executé avec un argument « -c » qui est la Suite Configuration, qui permet au FitSever.exe de prendre un fichier de configuration en paramètre.
Pour utilisé ce fichier de configuration il suffit d’ajouter une define a la page de test ou a une suite :

!define COMMAND_PATTERN {%m -c mySuite.config %p}

Ce fichier de configuration se presente sous la forme suivante :
[sourcecode language=’xml’]
<suiteConfig>
<fit.Settings>
<appConfigFile>myDomain.dll.config</appConfigFile>
</fit.Settings>
</suiteConfig>
[/sourcecode]

Grace a ce fichier de configuration supplémentaire, un seul FitServer est nécessaire.

• FitServer.exe
• Assembly 1
• • Assembly1.dll
  • Assembly1.dll.config
  • suite.config

• Assembly 2
• • Assembly2.dll
  • Assembly2.dll.config
  • suite.config

Plus d’info sur le suite configuration ici

Comment ca marche ?

Un TDD s’écrit en 6 étapes :

• écrire un test
• vérifier qu’il échoue (car le code que l’on teste n’existe pas)
• écrire juste le code suffisant pour passer le test
• vérifier que le test passe
• Checkiner le source pour que les autres développeurs puissent l’utiliser
• Refactoriser le code

Mais pourquoi faire ?

Ces tests permettent de préciser les spécifications du code, et donc son comportement ultérieur en fonction des situations auxquelles il sera exposé. Ce qui facilite la production d’un code valide en toutes circonstances. On obtient donc un code plus juste et plus fiable.

En écrivant les tests d’abord, on utilise le programme avant même qu’il existe. On s’assure ainsi que le code produit est testable unitairement. Il est donc impératif d’avoir une vision précise de la manière dont on va utiliser le programme avant même d’envisager son implémentation. Cela évite souvent des erreurs de conception dues à une précipitation dans l’implémentation avant d’avoir défini les objectifs.

De plus, le fait d’avoir des tests augmente la confiance en soi du programmeur lors de la refactorisation du code : il sait qu’à un moment donné les tests ont réussi. Il peut ainsi se permettre des changements radicaux de design en étant sûr, à la fin, d’avoir un programme se comportant toujours de la même façon (si les tests réussissent toujours).

L’utilisation de TDD permet la construction conjointe du programme et d’une suite de tests de non-régression.

Entrons dans le vif du sujet

Prenons un exemple,
Notre analyste nous demande de transformer le prix HT dans l’application par le prix TTC.
Nous devons donc réaliser une fonction qui transforme un prix HT en prix TTC.

Travaillons par étape, en premier nous devons créer un projet de tests unitaires.

Puis nous créons une class de tests unitaires pour tester la class Price
Le nom de la class de test pourra être appelée PriceTest par exemple.

Il est très important de définir une norme pour le nom des projets de test, les class de test, et les méthodes de test entre tous les développeurs pour une homogénéité du code (StyleCop)

Que doit faire ce test ?
la réponse est relativement simple, il doit créer un objet de type Price qui a une valeur correspondant au prix HT, et ajouter une taxe a ce prix.

Quels sont les acteurs, les activités et les asserts du test ?

Acteurs :

• Un object Price
• Le prix HT
• Le prix TTC retourné par la fonctionnalité
• Le prix TTC attendu

Activités :

• Appeler une method de la class Price qui nous retourne un decimal de la valeur TTC

Asserts :

• Vérifier que la valeur attendu est égale à la valeur retournée par la methode

Prenons un scénario, si le prix HT est 50 Euros alors quelle sera la valeur TTC ?

Durant l’analyse de ce scénario et l’écriture de ce test, plusieurs questions restent sans réponses :

• Qu’elle est la valeur de la taxe
• Combien de chiffre après la virgule pour le prix TTC
• Doit on arrondir ou couper le prix TTC

Ces questions doivent être répondu par notre analyste le plus rapidement possible.
Il nous répond que la taxe sera exclusivement de 19.6 et que l’on ne doit pas arrondir la valeur TTC.

Ce qui donne le test suivant :

[TestMethod]
public void Price_PriceTTCIs59_8_WhenPriceHTIs50()
{
#region Actors
Price price;
decimal HTPrice = 50;
decimal TTCPrice;
decimal expectedTTCPrice = 59.8m;
#endregion

#region Activities
price = new Price(HTPrice);
TTCPrice = price.GetTTCPrice();
#endregion

#region Asserts
Assert.AreEqual(expectedTTCPrice, TTCPrice, « The TTC expected price is not correct »);
#endregion
}

Le test ne compile pas car la class Price n’existe pas encore.
Faisons une implémentation rapide de cette class.

public class Price
{
private decimal _price;
public Price(decimal price)
{
_price = price;
}

public decimal GetTTCPrice()
{
return 59.8m;
}
}

Le test est vert, le code peut être checkiner pour que les autres développeurs puissent l’utiliser pour l’interface graphique par exemple.
Maintenant nous pouvons prendre un peu de temps pour implémenter la methode GetTTCPrice;

public decimal GetTTCPrice()
{
decimal TTCPrice;
TTCPrice = _price * 1.196m;

return TTCPrice;
}

Le test reste vert la methode GetTTCPrice a l’air de fonctionner.
Ecrivons un 2 eme test pour valider notre implémentation

[TestMethod]
public void Price_PriceTTCIs119_6_WhenPriceHTIs100()
{
#region Actors
Price price;
decimal HTPrice = 100;
decimal TTCPrice;
decimal expectedTTCPrice = 119.6m;
#endregion

#region Activities
price = new Price(HTPrice);
TTCPrice = price.GetTTCPrice();
#endregion

#region Asserts
Assert.AreEqual(expectedTTCPrice, TTCPrice, « The TTC expected price is not correct »);
#endregion
}

Les 2 tests sont vert, tout va bien, nous pouvons checkiner notre code.

Bravo nous venons de faire du TDD.

Pour cela nous devons déjà les définir.
Reprenons l’exemple de l’article précédent avec GetTTCPrice

• Nous devons vérifier que si le prix HT est 0 Euros alors le prix TTC reste 0
• Que ce passe t-il si le prix HT est inferieur 0 ?

Pour le premier point, un test unitaire suffira, mais pour le 2 eme point, nous devons demander a notre analyste.
Notre analyste nous répond tout simplement qu’un prix négatif, ca n’existe pas.
La peste, ca n’existait pas avant qu’on la découvre.
Si ca n’existe pas faut-il tester ce cas ?

Bien sur que oui, ca prend 5 minutes et ca ne mange pas de pain.
Ok, on test, mais quel doit être le comportement d’un cas qui n’existe pas ?
Le choix doit âtre pris par le développeur, donc par nous.
Fonctionellement ce cas est impossible, mais techniquement c’est tout a fait possible de passer un nombre negatif a la class Price.
Si nous faisons rien pour éviter qu’un prix soit négatif, notre application a un risque de partir dans un comportement incontrôlé, nous devons intérompre se comportement le plus rapidement, mais comment ?

• En mettant le prix a 0
• En claquant une exception

Beaucoup de personnes vont penser que la première solution est suffisante, mais NON arrêtez d’être stupide, pourquoi 0 ? pourquoi pas 5 ou 22 ou 42 ? decimal.MaxValue, c’est pas mal non plus non ?
Il faut avertir l’application qu’il y a un problème en claquant une exception, le Framework .NET a une exception du type ArgumentException, plutôt cool non ?

Modifions la class Price pour gérer ce cas:

public class Price
{
private decimal _price;

public Price(decimal price)
{
if (price < 0)
throw new ArgumentException(« Price cannot be negative »);

_price = price;
}

public decimal GetTTCPrice()
{
decimal TTCPrice;

TTCPrice = _price * 1.196m;

return TTCPrice;
}
}

Et voila les 2 nouveaux tests unitaires pour tester les limites :

[TestMethod]
public void Price_PriceTTCIs0_WhenPriceHTIs0()
{
#region Actors
Price price;
decimal HTPrice = 0;
decimal TTCPrice;
decimal expectedTTCPrice = 0;
#endregion

#region Activities
price = new Price(HTPrice);
TTCPrice = price.GetTTCPrice();
#endregion

#region Asserts
Assert.AreEqual(expectedTTCPrice, TTCPrice, « The TTC expected price is not correct »);
#endregion
}

[TestMethod]
[ExpectedException(typeof(ArgumentException))]
public void Price_ThrowArgumentException_WhenPriceHTIsNegative()
{
#region Actors
Price price;
decimal HTPrice = -56;
#endregion

#region Activities
price = new Price(HTPrice);
#endregion

}