Autofixture: Suggestion : suivez le style « Arrange Act Assert » pour les tests

Fonce. Mais je préférerais avoir la première lettre majuscule, c'est-à-dire

// Arrange
// Act
// Assert

à la place de

// arrange
// act
// assert

Avez-vous de bonnes raisons de préférer le second cas ?

Non, les majuscules me conviennent - il suffit d'utiliser AAA :blush:

Vous pouvez également séparer chaque phase avec une ligne vierge, qui est le formatage que j'utilise de nos jours. Ensuite, le lecteur de test peut supposer qu'il s'agit de Given/When/Then , ou Arrange/Act/Assert , ou même (celui en quatre phases va ici) .

Vous pouvez en savoir plus à ce sujet dans la section "Tests simples avec plus de trois lignes de code" ici .

Je n'aime pas du tout l'utilisation de lignes vides au lieu de commentaires dans OSS et je ne suis pas d'accord avec cette idée de Marks. Voir mon commentaire ici .

Les commentaires au-dessus de chaque phase de test sont, en gros, des commentaires . Et dans ce cas particulier, ce sont des excuses , car elles expliquent comment — au lieu de pourquoi .

Maintenant, revenons à AutoFixture, puisque tous les tests sont agrémentés de commentaires et que la phase de démontage des fixtures est presque toujours vide, nous pouvons continuer et les changer en AAA .

Et dans ce cas particulier, ce sont des excuses

Eh bien, je me réfère aussi souvent à cette règle, mais dans ce cas particulier, je préfère garder ces "excuses" 😄 Ils rendent la structure du test plus évidente et plus stricte. Personnellement, je trouve plus facile de lire les tests "labellisés", mais c'est probablement simplement une question d'habitude

mais c'est probablement simplement une question d'habitude

Cette; et peut-être aussi une question de qui a réellement écrit le test.

Bonjour, j'aimerais m'y attaquer. Je suis un grand fan d'Autofixture et je l'utilise tout le temps dans mon travail et ce serait un bon moyen de redonner.
Donc, en gros, vous voulez changer les éléments suivants dans tous les fichiers de test :
// Fixture setup à // Arrange
// Exercise System à // Act
// Verify Outcome à // Assert
et enfin // Teardown à rien.

Oui, mais gardez à l'esprit que faire un « rechercher et remplacer » peut ne pas fonctionner car certaines phases sont réunies dans certains tests. C'est-à-dire que vous pourriez rencontrer un système d'exercice et vérifier le résultat et similaire, IIRC.

@moodmosaic Je comprends, je

Merci,
Eissa

@moodmosaic pour // Exercise system and verify outcome il devrait être remplacé par
// Act and Assert
Ou vous pensez à quelque chose de différent ?

Habituellement, j'utilise // Act & Assert car il a l'air plus concis et cool 😎 À moins que @moodmosaic ait des inquiétudes, je préférerais suivre ce style 😉

Dans tous les cas c'est OK :neckbeard:

J'essaie donc de commencer là-dessus et après avoir chargé le All.sln dans VS 2017, deux projets F#
( AutoFoq, AutoFoqUnitTest ) ne s'ouvrent pas. J'ai une expérience zeor avec F # donc toute aide serait appréciée

@micheleissa Assurez-vous que vous utilisez la dernière version de VS (15.5.1 ou ultérieure), sinon le projet ne s'ouvrira pas (MS a appliqué des modifications à son SDK F#). Assurez-vous également d'exécuter git clean -fdx . en root avec VS fermé. C'est pour nettoyer les fichiers temporaires au cas où vous auriez extrait le projet plus tôt.

Ces deux étapes devraient aider. Faites-moi savoir s'ils ne l'ont pas fait

@zvirja J'ai mis à niveau vers la dernière version de VS 2017 15.5.2 et je suis toujours confronté au même problème 😞

As-tu essayé la deuxième partie ?

• Fermer VS
• Vérifiez les derniers master
• Allez à la racine et exécutez git clean -fdx .
• Ouvrir VS à nouveau ?

Il semble que vous ayez simplement des restes du SDK précédent.

Assurez-vous également que l'outillage F# est installé sur votre machine :

Oui j'ai oublié le deuxième désolé :)
je vais essayer maintenant

@zvirja qui a fonctionné, merci beaucoup pour votre aide !

Encore une question, comment associer la branche sur laquelle je travaille dans mon repo forké à ce ticket ?

Super que ça marche ! ??

comment associer la branche sur laquelle je travaille dans mon repo forké à ce ticket ?

Je suggère de regarder cet article, le workflow y est bien décrit : https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git :-Fork,-Branching,- Commit,-and-Pull-Request

Fondamentalement, vous n'avez pas besoin d'associer une branche à ce problème. Au lieu de cela, vous créez une Pull Request et mentionnez simplement ce problème dans le corps (par exemple, voyez celui- ci).

Ok, j'ai compris. Merci! Je vais créer la pull request pendant que je travaille sur le problème afin que vous puissiez suivre les progrès et donner votre avis en fonction de ce qui est mentionné dans les directives de contribution.