Lorsque je ne suis pas sûr de quelque chose pour un projet, j'utilise généralement un petit projet séparé et en faire mon terrain de jeu pour les choses doivent être testés. Comment tu fais ça ?Projets de terrains de jeux
Cela dépend de ce que je veux essayer. Pour des trucs algorithmiques simples, j'ai une application console qui se compose de plusieurs classes, une pour chaque chose que je veux essayer. De cette façon, j'ai tout dans un seul projet et peut parcourir les idées et les approches que j'ai essayé au cours des années. J'utilise des dossiers pour les nouveaux sujets et postfixer les noms de classe avec un index croissant (ou quelque chose de similaire qui permet de voir la différence dans les implémentations en regardant simplement le nom de classe), lorsque j'essaie différentes solutions pour un problème. La seule maintenance que je fais sur les classes est de filtrer les choses qui ne sont pas compilées (plus), mais les fausses approches ne sont marquées que par de longs commentaires dans les fichiers de classe respectifs. Pour moi, c'est aussi un bon moyen de voir comment mes compétences s'améliorent avec le temps ... et c'est assez marrant de regarder l'ancien code aussi. J'ai une approche similaire pour les choses liées à l'interface graphique ainsi que l'application ASP.net, de sorte que j'ai un total de trois projets de test, tous organisés de la manière décrite ci-dessus.
Je le fais de la même manière. Un projet temporaire a quelques inconvénients ... Vous devez configurer un nouveau projet dès que vous voulez tester autre chose. J'ai aussi trouvé que les terrains de jeu étaient de très bonnes références. Souvent, je me souviens que j'ai essayé quelque chose auparavant et que je peux ensuite regarder dans les anciens fichiers du terrain de jeu et même le modifier pour l'adapter aux nouvelles exigences.
Je n'utilise pas un sous-projet entier comme terrain de jeu - je fais normalement un test simple et si cela fonctionne comme prévu, je fusionne le code dans mon projet. Pendant le temps en tant que programmeur, il y a beaucoup de ces textos et je les garde toujours. C'est bien d'avoir ces exemples - donc chaque fois que je pense à quelque chose, je regarde d'abord mes tests.
Parfois, j'utilise une simple application de console pour tester les choses.
D'autres fois, je clone (ou branche) le projet principal et essaye des choses dans la copie. Souvent, le clone est recopié (ou fusionné) dans l'original une fois que j'ai fini d'essayer les choses.
D'autres fois, je m'assure que le projet principal est enregistré dans le contrôle de source, puis j'essaie des choses là-bas. Si je n'aime pas la façon dont les choses fonctionnent, je revois les changements.
J'utilise l'idée de «tests de résistance» que j'ai vu pour la première fois dans «TDD adventures in C#» de Ron Jeffries. Les tests de pointes sont codés en tant que classes de test unitaires, avec des morceaux de code que vous souhaitez tester à la place des méthodes de test. De cette façon, vous pouvez facilement essayer du code avec lequel vous n'êtes pas à l'aise en l'exécutant dans le testeur.
Je place habituellement des tests de pointe dans le même projet avec des tests unitaires. Une fois dans le référentiel, le code de test de pointe peut aider les autres développeurs à comprendre vos décisions dans le code de production.