Mardi 20 avril s’est déroulé une session du Ch’ti JUG sur GIT et Mockito sponsorisé par ProxiAD : GIT et Mockito avec ProxiAD

Pour ceux qui ne savent pas ce qu’est le Ch’ti Jug ou ce qu’est un Jug, voir l’introduction de mon article sur la première session à laquelle j’ai participé:  Ch’ti Jug: les technologies Google.

Cette session été animée par David Gageot directeur technique chez Algodeal.

GIT

Les principaux atouts de GIT:

• Rapide : il fonctionne en locale.
• Déconnecté : commit local, repository local intégrale, possibilité de synchroniser un repository local avec un repository  distant
• Ouvert
• Flexible
• Robuste
• Simple : utilisation simple par des lignes de commandes
• Complet et Complet : possibilité étendue.
• Grande communauté d’utilisateur : github

De nombreux outils sont compris dans GIT qui permettent de faciliter grandement sont utilisation et qui peuvent faire gagner énormément de temps. Le présentateur nous a fait une démonstration de l’outil git-bisect qui a lui-seul suffit à vouloir utiliser GIT.

Imaginez que vous ayez fait une centaines de commit dans votre repository et que vous découvrez ensuite que les sources ne compilent plus! Comment faire pour trouver l’erreur ? git-bisect vous permet de facilement retrouver le commit à partir duquel vos sources ne compilent plus. Son principe: il utilise un algorithme de type dichotomie pour tester un a un l’état de votre repository. Pour cela vous lui donnez la version de départ et une commande à exécuter (par exemple « mvn compile » si vous utilisez Maven), il va ensuite lancer la commande sur les versions de votre repository et vous donner la première version dont la commande est en erreur. Comme il utilise un algorithme de dichotomie cela prend beaucoup moins de temps que de tester toutes les version … et en plus c’est automatisé!

Comment marche git au jour le jour. N’importe quel répertoire peut être définie comme un repository git (le présentateur nous a même expliqué qu’avant toute mise à jour d’Eclipse il transformer le répertoire d’Eclipse en repository git pour pouvoir revenir en arrière si nécessaire!). Ensuite ils suffit d’ajouter des fichiers (git add) et de faire des commits des fichiers (git commit -m « message »). Tout se passe alors en locale, sans connexion a aucun serveur.

Vous me direz, oui mais, et le travail en équipe?

Pour cela il y a de nombreuses manière de faire.
Par définition, on doit utiliser les commandes suivantes:

• git clone : clone un repository (depuis une machine distante, un disque réseaux, une clé USB, un autre répertoire, …).
• git push : envoit les modification de votre repository vers un autre.
• git pull : recupère les modification d’un autre repository.

Classiquement, on utilise deux architecture différentes:

• Server centralisé : on défini un serveur qui sera le repository centralisé sur lequel toute l’équipe fera ses push et depuis lequel elle fera ses pull.
• Cercle de confiance : architecture utilisé dans les projets open source (et notamment dans le développement du noyeau linux). Il y aura alors une hiérarchie de commiteur, les plus « petit » feront un push vers une personne de plus grande confiance qui lorsqu’elle aura tester les changement fera un push vers une personne de plus grande confiance et cela jusqu’au repository de référence. Ensuite tout le monde fera des pull en cascade. Intérêt: pas d’administration, idéale pour les grande équipe, vérification limité grâce aux cercles de confiance, pas de serveur centralisé: peut marcher s’il y a défaillance d’une partie des repository.

GIT est réputé aussi pour son merge « omniscient » : GIT peut merger tout seul énormément de situation qui sous d’autre gestionnaire de source nécessite une action manuelle et permet donc des refactoring lourd sans code freeze. Il réussit à faire un merge d’un fichier ayant été déplacé et renommé alors qu’une autre personne le modifié!

Pour tout ceux qui voudrait essayer, il existe un outils permettant de migrer un repository SVN existant en gardant l’historiquel : git-svn.

Il existe de nombreuses autres fonctionnalités, si vous êtes intéressé, n’hésitez pas à creuser le sujet.

MOKITO

Mockito est un framework de mock facilitant grandement l’écriture de test unitaire par la possibilité de créer différents objets de test tel que :

• Dummy object : Mockito.mock(Class c) : mock une classe concrète ou une interface : créé une instance « bidon » de cette classe.
• Fake object : MaClass fake = Mockito.mock(MaClass.class); when(fake.getTime()).thenReturn(1,2,3) : crée une instance « bidon » de la classe retournant des valeurs prédéfinie (1,2,3) lors d’appel successifs d’une des méthode de cette classe.
• Stub : MaClass stub = Mockito.mock(MaClass.class); verify(stub).send(Email.class) : crée une instance « bidon » de la classe. On peut ensuite l’utiliser (par exemple appeler une méthode send avec comme paramètre un Email). Puis dans notre testcase on va vérifier que notre stub a bien été appelé : on vérifie que la méthode send a été appelé avec un email en paramètre.
• Mock : sur le même principe un mock permet de valider les exceptions, l’appel des méthodes avec le contenu des paramètre, les appels multiples, les réponses multiples, …

Mockito peut s’interfacer facilement avec JUnit4 grâce à l’annotation RunWith qui permet ensuite d’utiliser l’annotation Mock pour mocker un objet.

Mockito contient de nombreuses fonctionnalités avancées toujours aussi facilement utilisable (mock partiel, deep-stub, syntaxe BDD, …), pour plus d’information allez faire un tour sur le site officiel: http://code.google.com/p/mockito/