SharePoint Summit 2012 - Les tests automatisés et SharePoint 2010, c'est possible!

Post on 21-Jun-2015

858 views 0 download

Tags:

description

Présentation donnée lors du SharePoint Summit 2012 de Québec le 18 avril 2012.

transcript

Les tests automatisés et SharePoint 2010, c'est possible!

Sébastien LevertDirecteur technique, Développement SharePoint, Les Solutions Victrix

2

À propos de moi !

Directeur technique,

Développement SharePoint

Les Solutions Victrix

MCTS, MCITP & MCPD

Twitter : @sebastienlevert

LinkedIn : http://ca.linkedin.com/in/sebastienlevert

Blog : http://blog.sebastienlevert.com/

3

À qui ça s’adresse ?

Développeurs

Responsables d’assurance-qualité

Gestionnaires d’équipes techniques

4

Les prérequis

Connaître les concepts de base des tests unitaires

Bien connaître les API de développement de SharePoint

Être à l’aise avec les expressions lambdas

Être curieux

5

Agenda

Pourquoi, les tests automatisés ?

Les tests unitaires dans un environnement SharePoint

Les tests d’interface

Comment l’intégrer dans la réalité

Questions

6

Les tests automatisés

7

Pourquoi, les tests automatisés ?

Favoriser la qualité des solutions livrées

Assurer une rétro-compatibilité

Alléger les tests fonctionnels

Favoriser un modèle de développement obligeant à penser en fonction des tests

Deux types Tests unitairesTests d’interface

8

Les tests unitaires

9

Les tests unitaires

En programmation informatique, le test unitaire est un procédé permettant de s’assurer du fonctionnement correct d’une partie déterminée d’un logiciel ou d’une portion d’un programme (appelé « unité » ou « module »). – Wikipédia

Tests isolés d’une méthode, d’une fonctionPlus le test isole un cas associé à une fonction, plus le test est pertinent

10

Les tests unitaires dans un environnement SharePoint

Avez-vous déjà tenté l’expérience ?

Sans outil, c’est long, complexe, non performant et impossible à tester à 100%

Donc… On fait quoi ?

Utilisation de « framework » d’isolation (« Mocking »)TypeMock IsolatorTelerik JustMockMoqRhinoMockMicrosoft Pex & Moles

11

Les tests unitaires dans un environnement SharePoint

Pex & Moles à la rescousse !

Permet de changer le comportement des appels aux méthodes des classes (de tout type)

Permet d’être isolé complètement de la plateforme

Pourquoi pas TypeMock, JustMock, moq, RhinoMock, etc ?Visual Studio 11 Beta !Moles a été intégré nativement à la plateforme de tests unitairesSupporté par l’équipe de Visual StudioLe nouveau nom : Fakes

12

L’isolation : Exemple

Comment tester ceci ?

Si on pouvait modifier le comportement de DateTime.Now, ça deviendrait testable…

À l’appel de DateTime.Now, la véritable date qui sera retournée sera celle définit dans le MDateTime.NowGet. Magie!

if (DateTime.Now == new DateTime(2000,1,1))throw new BogueAn2000();

MDateTime.NowGet = () => return new DateTime(2000, 1, 1);

if (DateTime.Now == new DateTime(2000,1,1))throw new BogueAn2000();

13

Les tests unitaires dans un environnement SharePoint

Du code ! Enfin !

14

En résumé

Permettent de tester vos fonctionnalités utilisant les entrailles de SharePoint

Permettent de faire aisément des tests de régression

Doivent être accompagnés d’isolation

Ajoutent un certain temps au développement, habituellement rapidement compensé par moins de tests fonctionnels.

15

Les tests d’interface

16

Les tests d’interface, qu’est-ce que c’est ?

Séquence d’utilisation d’un logiciel

Peut être « enregistré »

Génère le code afin de reproduire la séquence

Le code généré peut être modifié pour satisfaire différentes conditions

Intégration à Visual Studio 2010 Premium/Ultimate

17

La différence avec les tests unitaires

Permet de faire des tests couvrant une plus vaste superficie de votre logiciel (Déploiement, comportement web, etc.)

Sont des tests « intégrés » à l’environnement SharePoint

Couvre des éléments beaucoup plus complexes à tester avec des tests unitaires

18

Les tests d’interface dans un environnement SharePoint

Démo !

19

L’intégration dans la réalité

20

Comment intégrer ces techniques dans la réalité ?

Intégration des tests dès le premier jour du projetBeaucoup plus efficace et motivantNe requiert pas de faire des tests rétroactifs qui coûtent beaucoup plus cher

Formation des développeursUn développeur formé et comprenant les enjeux des tests automatisés sera plus enclin à développer des tests de grande qualité

Ajout de politiques au gestionnaire de sourceImpossible de déposer du code non testéImpossible de déposer du code si les tests échouent

21

Comment intégrer ces techniques dans la réalité ?

Planifier les testsUn coût est associé à l’ajout de ces mesuresAjout de 15 à 20% d’effort à un projet au niveau des activités de développementRéduit au minimum les « dummy » testsÀ favoriser lors de projets misant sur la qualité de la solutionPlus la découverte et la correction d'une erreur survient tard dans le cycle de développement, plus elle sera coûteuse à corriger. L'augmentation des coûts au niveau unitaire peut donc alors être perçu comme un investissement dans la qualité globale.

Ne remplace pas les activités d’assurance-qualitéPermettent de valider les cas principauxNe permettent pas de valider les besoins

22

Questions ?