Comment tester des applications C # existantes? Facile: avec un outil de simulation

Je vous suggère de jeter un œil à l'application ERP pour commencer: [19659029] Telerik UI pour WPF ERP Sample App "title =" Telerik UI pour WPF ERP Sample App "/>

Les fois où j'ai vu ou interagi avec elle se comptent sur les doigts d'une main. Mais cela ne devrait pas déranger moi, ou toi (enfin, du moins pas beaucoup).

J'ai oublié de mentionner quelque chose à propos de JustMock – il suit le modèle Arrange-Act-Assert . Le modèle AAA rend un test plus simple et plus structuré en le divisant en trois sous-sections, comme expliqué ci-dessous:

Une fois l'extension JustMock installée, vous êtes assuré d'un bon départ. Les modèles de projet qui l'accompagnent m'ont aidé à créer un projet de test en quelques secondes.

Maintenant, je suis prêt pour les tests unitaires!

Modifier / Supprimer des commandes

Voir les boutons Modifier et supprimer à gauche sous la barre d'Ariane? Je parie qu'il y a une commande liée aux deux.

Vous avez remarqué que l'élément Commandes est initialement sélectionné? Étonnamment (ou non), son DataContext est le OrdersViewModel. De retour aux commandes, oui, les voici:

 this  .EditRecordCommand =  new   DelegateCommand (
  (o) => 
  {
 ]  dialogFactory.TargetItemName =  this  .ItemName; 
  dialogFactory.ShowEditDialog ( this  .ItemToEdit); 
  this . Actualiser (); 
 }, 
  (o) =>  this  .ItemToEdit! =  null ); 
 
 this  .DeleteRecordCommand =  nouveau   DelegateCommand (
  (o) => 
  {
  dialogFactory.TargetItemName =  this  .ItemName; 
  if   (dialogFactory.ShowDeleteDialog ()) 
  {
  ( this  .ItemToEdit  as   ISavableObject) .D elete (); 
  this  .Refresh (); 
 } 
 }, 
  (o) =>  this [19659038] .ItemToEdit! =  null ); 

Voyons comment ce qui précède peut être couvert avec des tests unitaires et écrivons nos premiers avec Just Mock! Le but des deux tests – supposons qu'il existe une liaison directe entre les boutons et les commandes. De cette façon, nous pourrons tester les commandes elles-mêmes. Toutes les dépendances (par exemple, ERPDialogFactory, SalesOrderHeader, CollectionView) seront simulées et l'exécution réussie des méthodes respectives (par exemple, ShowEditDialog, ShowDeleteDialog, Refresh) sera vérifiée. En commençant par EditRecordCommand.

  
 
   [TestMethod]  
 public   void   OrdersViewModel_EditRecordCommandExecutedS Successful () 
 {[196590741] 
 {[196590741] 
 // Arrange 
  var dialogFactory = Mock.Create  (); 
  var salesOrderItem = Mock.Create  (); 
  var collectionView = Mock.Create < QueryableDataServiceCollectionView > (); 
  Mock.Arrange (() =>  new   ERPDialogFactory ()). Renvoie (dialogFactory); 
  Mock.ArrangeSet ((( ) => dialogFactory.TargetItemName =  "myItemName" ); 
  Mock.Arrange (() => dialogFactory.ShowEditDialog (salesOrderItem)). DoNothing (); 
  Mock.Arrange (() => collectionView.HasChanges) .Returns ( true ); 
  Mock.Arrange (() => collectionView.RejectChanges ()). InOrder (); [19659043]  Mock. Arrange (() => collectionView.Refresh ()). InOrder (); 
 
  // Act 
  var viewModel =  new   OrdersViewModel (); [19659043]  viewModel.SelectedItem = salesOrderItem; 
  Mock.Arrange (() => viewModel.ItemName) .Returns ( "myItemName" ); 
  Mock .Arrange (() => viewModel.Items) .Returns (collectionView); 
  viewModel.EditRecordCommand.Execute ( null ); 
 
  // Assert 
  Mock.Assert (dialogFactory); 
  Mock.AssertSet (() => dialogFactory.TargetItemName =  "myItemName" Occurs.Once ()); [19659043]  Mock.Assert (salesOrderItem); 
  Mock.Assert (collectionView); 
 } 

Couvrir le DeleteRecordCommand avec un test unitaire ressemble beaucoup à celui de EditRecordCommand:

  
 
   [TestMethod]  
 public   void   OrdersViewModel_DeleteRecordCommandExecutedS Successful () 
 {
 //   // Arrange 
  var dialogFactory = Mock.Create  (); 
  var salesOrderItem = Mock.Create  (); 
  var collectionView = Mock.Create < QueryableDataServiceCollectionView > (); 
  Mock.Arrange (() =>  new   ERPDialogFactory ()). Renvoie (dialogFactory); 
  Mock.ArrangeSet ((( ) => dialogFactory.TargetItemName =  "myItemName" ); 
  Mock.Arrange (() => dialogFactory.ShowDeleteDialog ()). Renvoie ( true ); 
  Mock.Arrange (() => salesOrderItem.Delete ()). DoNothing (); 
  Mock.Arrange (() => collectionView.HasChanges) .Returns ( true ); 
 [19659042] Mock.Arrange (() => collectionView.RejectChanges ()). InOrder (); 
  Mock.Arrange (() => collectionView.Refresh ()). InOrder (); 
 [19659133]  // Act 
  var viewModel =  new   OrdersViewModel (); 
  viewModel.SelectedItem = salesOrderItem; 
  Mock.Arrange ( () => viewModel.ItemName) .Returns ( "myItemName" ); 
  Mock.Arrange (() => viewModel.Items) .Returns (collectionView); 
 [19659042] viewModel.DeleteRecordCommand.Execute ( null ); 
 
  // Assert 
  Mock.Assert (dialogFactory); 
  Mock. AssertSet (() => dialogFactory.TargetItemName =  "myItemName" Occurs.Once ()); 
  Mock.Assert (salesOrderItem); 
  Mock.Assert ( collectionView); 
 } 

Imprimer ces commandes

Qu'en est-il e bouton d'impression à droite en dessous de la barre d'Ariane? Ce bouton:

 < telerik: RadButton 
  x: Name  =  "Print" 
  local: PrintExportHelper.PrintTarget  =  "{Binding ElementName = gridView}" 
  Style  =  "{StaticResource GridNavigationButtonStyle}" 
  Largeur  =  "63" > [19659043]  <! - 



  


               




  Contenu du bouton et info-bulle ici 
  -> 
  </  telerik: RadButton > 

Il a un ensemble PrintTarget et je suppose que c'est ce que je recherche. Voyons d'où vient ce PrintTarget et ce qu'il est censé faire. Cela semble être une propriété de dépendance, dont le setter sera appelé, et respectivement le PropertyChanged, lorsque la liaison ci-dessus est exécutée. Cela nous amène à:

 private   static   void   OnPrintTargetChanged (DependencyObject d, DependencyPropertyChangedEventArgs e) 
 {
  var button = d  as 
 RadButton 
 19659042] var gridView = e.NewValue  as   RadGridView; 
  if   (button! =  null   && gridView! =  null ) 
  {
  button.Command =  new   DelegateCommand (OnPrintCommandExecuted); 
  button.CommandParameter = gridView; 
 } [19659064] } 

 
 private   static   void   OnPrintCommandExecuted ( object   obj) 
 {
  var gridView = obj  ] as   RadGridView; 
  if   (gridView! =  null ) 
  {
  var spread sheet =  new   RadSpreadsheet (); 
  var window =  new   RadWindow () {Width = 0, Height = 0, Opacity = 0, Content = spreadsheet}; 
  window.Show (); 
  spreadsheet.Workbook = gridView.ExportToWorkbook (); 
  spreadsheet.Print ( new   PrintWhatSettings (ExportWhat.ActiveSheet) ,  false )); 
  window.Close (); 
 } 
 } 

Commençons cette fois par la définition XAML du bouton et tester si la liaison est correctement résolue et respectivement - cliquer sur ce bouton fait sa magie.

  
 
   [TestMethod]  
 public   void   PrintExportHelper_PrintButtonClickExecutesPrintCommand () 
 {
 // 
 // Arrange 
  Mock.NonPublic.Arrange ( typeof  (PrintExportHelper),  "OnPrintCommandExecuted" Arg.Expr.AnyObject); 
 
  // Act 
  var printButton = Mock.Create  (); 
  var args = Mock.Create  (); 
  var gridView = Mock. Create  (); 
  Mock.Arrange (() => args.NewValue) .Returns (gridView); 
  PrivateAccessor.ForType ( typeof  (PrintExportHelper) )). CallMethod ( "OnPrintTargetChanged" printButton, args); 
  printButton.Command.Execute (gridView); 
 
  // Assert 
  Mock.Assert ([19659039] typeof  (PrintExportHelper)); 
 } 

Ce test unitaire ne semble pas suffisamment stable. Cela garantit seulement qu'il y a un bouton d'impression et quand on clique dessus, la méthode statique de la classe d'assistance ci-dessus est appelée. Mais fonctionne-t-il correctement, c'est-à-dire que se passe-t-il exactement lorsque la commande du bouton est exécutée? Testons:

  
 
   [TestMethod]  
 public   void   PrintExportHelper_PrintCommandExecutionSucceeded () 
 {
 
 {
 // 
 {
 // Arrange 
  var gridView = Mock.Create  (); 
  Mock.NonPublic.Arrange ( typeof  (PrintExportHelper),  "OnPrintCommandExecuted"  ]gridView); 
  var spreadsheet = Mock.Create  (); 
  var workbook = Mock.Create  (); 
  var window = Mock.Create  (); 
  Mock.Arrange (() => window.Show ()). IgnoreInstance (). InOrder (); 
  Mock.Arrange (() => window.Close ()). IgnoreInstance (). InOrder (); 
  Mock.Arrange (() => gridView.ExportToWorkbook ()); 
  Mock.Arrange (() => tableur.Imprimer (Arg.IsAny  (),  null )). IgnoreInstance (); 
 [19659133]  // Act 
  PrivateAccessor.ForType ( typeof  (PrintExportHelper)). CallMethod ( "OnPrintCommandExecuted" gridView); 
 [19659133]  // Assert 
  Mock.Assert ( typeof  (PrintExportHelper)); 
  Mock.Assert (gridView); 
  Mock. Assert (window); 
  Mock.Assert (spreadsheet); 
  Mock.Assert (workbook); 
 } 

Ici, nous devons organiser trois autres choses (à part ceux du test précédent) - la fenêtre, la feuille de calcul et son classeur (ceux-ci feront la magie d'exporter les données de la grille dans le classeur d'un tableur).

L'acte que nous accomplissons appelle la méthode OnPrintCommandExecuted avec la vue de grille simulée.

La phase d'assertion garantit que toutes les dispositions ci-dessus ont été prises, y compris cette fois celles concernant la grille, la feuille de calcul et son classeur en dehors de PrintExportHelper.

C'est le chemin heureux de la fonctionnalité d'impression. Qu'en est-il du passage d'un élément, différent de la vue de grille attendue, par exemple, une chaîne vide, à la commande d'impression? Laissez-nous couvrir cela avec un test - en supposant que nous ayons passé un faux argument, l'exécution de la commande d'impression devrait échouer, non?

  
 
   [TestMethod]  
 public   void   PrintExportHelper_PrintCommandExecutionFailed () [19659107105] {
 // [19659107105] {
 // Arrange 
  var gridView = Mock.Create  (); 
  Mock.NonPublic.Arrange ( typeof  (PrintExportHelper),  "OnPrintCommandExecuted"  ]gridView) .OccursNever (); 
  var spreadsheet = Mock.Create  (); 
  var workbook = Mock.Create  (); 
 [19659042] var window = Mock.Create  (Constructor.NotMocked); 
  Mock.Arrange (() => window.Show ()). IgnoreInstance (). InOrder (). OccursNever (); [19659043]  Mock.Arrange (() => window.Close ()). IgnoreInstance (). InOrder (). OccursNever (); 
  Mock.Arrange (() => gridView.ExportToWorkbook ( )). OccursNever (); 
  Mock.Arrange (() => tableur.Print (Arg.I sAny  (),  null )). IgnoreInstance (). OccursNever (); 
 
  // Act 
  PrivateAccessor.ForType ( typeof  (PrintExportHelper)). CallMethod ( "OnPrintCommandExecuted" String.Empty); 
 
  // Assert 
  Mock.Assert ( ] typeof  (PrintExportHelper)); 
  Mock.Assert (gridView); 
  Mock.Assert (window); 
  Mock.Assert (tableur); [19659043]  Mock.Assert (classeur); 
 } 

Devinez quoi, il a fait. Pas le test. L'exécution de la commande - nous avons fait en sorte qu'aucune invocation des méthodes ci-dessus ne se soit jamais produite en agissant avec une chaîne vide au lieu de la vue de grille attendue.

Eh bien, il semble que les fonctionnalités d'exportation, de suppression et d'impression fonctionnent comme prévu. Bon travail!

Et le dernier bouton de cette barre de boutons - l'exportation? Eh bien, je laisse ceci comme votre devoir JustMock. Commentaires honnêtes dans les commentaires.

Que vous:

Indépendamment de ce qui précède «Cas», n’hésitez pas à:

Essayez le dernier JustMock Now

Vous ne le regretterez pas.