Partager via

Test piloté par les données

  • Article

Le test piloté par les données est une méthodologie de test dans laquelle les valeurs d’entrée et de sortie d’un test sont séparées du code. Ce formalisme signifie généralement qu’un petit investissement pour rendre le code de test un peu plus générique permet d’écrire un grand nombre de cas de test en identifiant simplement les données impliquées.

Le test piloté par les données est idéal pour les zones de test qui fonctionnent avec un ensemble de valeurs d’entrée qui définissent leur comportement. Par exemple, lors du test d’une API, les paramètres d’entrée et de sortie peuvent être définis en tant que source de données, et le code de test consomme les données, effectue les appels d’API et valide les résultats.

Prise en charge des tests pilotés par les données dans TAEF

TAEF offre une variété d’options pour la création de tests pilotés par les données. Nous allons comprendre ces options afin que vous puissiez choisir celle qui correspond le mieux à votre scénario de test.

La solution de test piloté par les données basée sur des tables vous permet de contrôler finement les variations de paramètres de données et de définir les types de paramètres. Dans ce cas, la source de données est une table définie dans un fichier XML. Vous pouvez spécifier les types de paramètres (int, unsigned int, size_t, bool, double, DWORD, __int64 etc. et leur variante de tableau homogène), ou avoir le type par défaut WEX::Common::String (natif) ou string (managé). Chaque ligne de la table est un ensemble de variantes sur les valeurs de paramètre. La méthode de test est appelée à nouveau pour chaque ligne de la table. Voici un extrait de code d’une source de données XML pour les tests pilotés par les données basés sur des tables :

1  <?xml version="1.0"?>
2   <Data>
3     <Table Id ="Table1">
4          <ParameterTypes>
5                  <ParameterType Name="Size">Int32</ParameterType>
6                  <ParameterType Name="Color">String</ParameterType>
7          </ParameterTypes>
8          <Row>
9                 <Parameter Name="Size">12</Parameter>
10                 <Parameter Name="Color">Blue</Parameter>
11         </Row>
12         <Row>
13                 <Parameter Name="Size">4</Parameter>
14                 <Parameter Name="Color">White</Parameter>
15         </Row>
16         <Row>
17                 <Parameter Name="Size">9</Parameter>
18                 <Parameter Name="Color">Black</Parameter>
19         </Row>
20    </Table>
21  </Data>

Pour en savoir plus : Test piloté par les données basé sur des tables.

La prise en charge des tests pilotés par les données légers n’offre pas la fidélité totale qu’offre la solution de test piloté par les données basées sur les tables. Pour clarifier : Les tests pilotés par les données de poids léger limitent les paramètres de données à WEX::Common::String (natif) ou String (managé) par rapport aux différents types pris en charge par la solution de test piloté par les données basées sur les tables. Toutefois, si vous recherchez une variation de données rapide et économique (par exemple un ou deux paramètres) pour créer une méthode de test pilotée par les données, et si l’ajout d’un fichier XML comme DataSource semble ne pas valoir la peine, les tests pilotés par les données légères peuvent être exactement ce que vous recherchez. Un bon exemple de ceci est un développeur qui écrit un test unitaire pour une API par exemple OpenThemeData (...) et souhaite vérifier l’API par rapport à « Button », « Listbox » et « ScrollBar ». Il peut s’agir d’une surcharge excessive pour créer un fichier DataSource XML pour cela, mais avec la prise en charge des tests pilotés par les données légers, cela peut être effectué efficacement dans le code source lui-même. Si plusieurs paramètres sont spécifiés, TAEF génère une expansion combinatoire à n voies des paramètres en arrière-plan et la méthode de test est appelée pour chaque combinaison. Pour en savoir plus : Tests légers pilotés par les données.

L’expansion combinatoire à n voies proposée par les tests légers pilotés par les données peut coûter cher et fournir des rendements décroissants à mesure que le scénario de test devient plus complexe. Dans ce scénario de test complexe, la solution de test piloté par les données basée sur PICT (Pairwise Independent Combinatorial Testing) proposée par la solution de test piloté par les données PICT peut être ce que vous recherchez. PICT fournit beaucoup de valeur en générant un ensemble compact de résultats de paramètres pour obtenir une couverture complète des paramètres. Découvrez des liens pour en savoir plus sur PICT et comment utiliser cette solution sur une solution de test pilotée par les données PICT .

À l’aide de la prise en charge des tests basés sur les données basés sur WMI , vous pouvez également ajouter une condition préalable à vos tests et obtenir des informations (données) en fonction des ressources disponibles sur la machine de test. Par exemple, si vous souhaitez exécuter le test uniquement si l’ordinateur est joint à un domaine et que vous avez également besoin des informations de nom de domaine lorsque vous exécutez le test. La source de données dans ce cas est une requête WQL. Découvrez comment tirer parti des tests pilotés par les données basés sur WMI dans votre scénario de test.

Étant conscient de toutes les options répertoriées ci-dessus, vous pouvez également trouver une conception où une combinaison des options ci-dessus peut sembler adaptée. Par exemple, vous pouvez utiliser une requête WMI pour obtenir des informations sur toutes les imprimantes connectées à la machine de test, mais il peut y avoir un autre ensemble de paramètres qui peut être défini à l’avance à l’aide d’une construction de test pilotée par les données basée sur une table. Plusieurs spécifications DataSource peuvent également être utiles si vous souhaitez que les données de votre test proviennent de deux tables distinctes, ce qui permet à chaque table d’être réutilisable dans d’autres tests. Lisez les détails sur la façon de spécifier plusieurs Sources de données pour un test et les contraintes qui s’appliquent lors de cette opération : Spécification de plusieurs sources de données

Dans cette section