IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Visual Studio 2015 : Microsoft présente Smart Unit Tests
Un utilitaire qui aide à détecter des bugs plus tôt dans le cycle de développement

Le , par Stéphane le calme

349PARTAGES

2  0 
Microsoft a dévoilé la préversion de Visual Studio 2015, la prochaine version majeure de son environnement de développement. Cette annonce s’est accompagnée de quelques autres à l’instar de la nouvelle mouture de Blend pour Visual Studio 2015 afin que les développeurs puissent créer de belles applications en XAML mais également une préversion de « Smart Unit Tests », un outil qui a vu le jour dans le cadre du projet de recherche Microsoft Pex.

L’objectif de cette fonctionnalité est d’aider les développeurs dans leurs efforts de refactoring. Une bonne pratique avant d’en arriver au refactoring consiste à vous assurer que vous avez mis sur pied une solide couverture autour de votre test afin que les modifications apportées au code ne cassent pas le comportement de votre application. Cependant, il arrive que des efforts de refactoring se fassent sans couverture de test ou alors qu'ils soient même évités parce qu’ils sont jugés effrayant à cause de plusieurs paramètres.

C’est alors qu’entre en jeu la fonctionnalité « Smart Unit Tests » qui vous permet de faire des choses de manière intelligente et crée des tests unitaires afin de cerner le comportement actuel du code avant d’effectuer tout refactoring.

L’outil va parcourir votre code et trouver tous les chemins de code possibles puis générer des tests unitaires pour chacun des scénarios qu’il aura rencontré. Concrètement, pour chaque déclaration dans le code, une entrée de code qui l’exécutera sera générée. Une analyse de cas sera effectuée pour chacune des branches conditionnelles dans le code. Par exemple les déclarations en ‘if’ et toutes opérations pouvant renvoyer des exceptions seront analysés. Il faut savoir que cette analyse est utilisée pour générer des données de test pour un test unitaire paramétré de chacune de vos méthodes, créant des tests unitaires avec un maximum de couverture de code.

Ces tests unitaires vous permettront de voir plus facilement où effectuer des modifications pour remédier à d’éventuelles erreurs. Il est possible de sélectionner parmi les tests générés celui/ceux qui serviront à fournir une suite de régression. Pendant que vous effectuez des modifications de votre code, il faut également recommencer les Smart Unit Tests afin que les tests générés soient en phase avec les changements effectués.

Voici un petit cas pratique pour comprendre comment il fonctionne avec l’implémentation de Conway's Game of Life. Voici la méthode CellState et plus bas les résultats de cette méthode qui a conduit à 5 tests.




Pour lancer Smart Unit Test, effectuez simplement un clic droit sur la méthode ou la classe et choisissez "Smart Unit Tests"

Voici le premier test qui a été généré.


Il faut préciser que cet outil est encore en préversion. De plus, Smart Unit Tests doit être exécuté sous l'hôte Smart Device et ne pourrait pas être exécuté sous l'hôte ASP.NET.

Source : Microsoft, Blog Jeremy Bytes

Et vous ?

Qu'en pensez-vous ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 01/04/2015 à 21:14
Citation Envoyé par clementmarcotte Voir le message
Bonjour,

Si je me fie à l'illustration, c'est aussi adieu aux éditions Express. Encore qu'il faut reconnaître que VS2013 Community est actuellement mieux pourvu que les VS2013 Express.
Personnellement je trouve que l'express est trop limitée car absence totale de plu-gins, genre entity framework avec oracle, c'est mort pour le tooling...

bon les 1millions de CA sont vites atteins mais pour une startup qui démarre ça peut aider.
4  0 
Avatar de I_Pnose
Membre chevronné https://www.developpez.com
Le 02/04/2015 à 14:22
Citation Envoyé par Washmid Voir le message
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien
SharpDevelop n’arrive clairement pas à la cheville (que dis-je, à la voute plantaire =P) de Visual Studio en terme de tooling. Je ne dénigre pas l’outil, mais on ne peut sérieusement pas dire qu’il est le pendant gratuit de l’IDE de Microsoft.

Nativement VS propose déjà des outils dont on a du mal à se passer en basculant sur une autre IDE (outil de profilage, débogage intra-VM, etc...) mais en plus sa notoriété fait qu’une multitude de plugins viennent étendre encore davantage ses possibilités (le piège étant de ne pas trop en installer, sinon on se retrouve réellement avec une usine à gaz).

Pour peu que vous déployiez des services dans Azure, que vous utilisiez TFS, que vous développiez des applications mobiles multiplateformes natives (via Xamarin) ou pas, alors il n’y a pas de concurrence sérieuse pour le moment.

Citation Envoyé par Washmid Voir le message
Si tu prends eclipse dans la même situation, bah... la compilation étant incrémentale, c'est instantané (avec un capacité de montée en charge assez bluffante)
Ben... même principe avec Visual Studio, si tu actives la compilation incrémentale, seules les méthodes modifiées seront recompilées (et ta solution devrait mieux s'en sortir...). De même (mais ça je pense que VS s'en sort tout seul) vérifier que dans les options de l'IDE le nombre de builds parallèles correspondent un tant soit peu au nombre de cœurs disponibles.
4  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 06/04/2016 à 20:40
Le problèmes des PCH, c'est qu'ils ne sont pas composables. Tu ne peux pas dire je prend le PCH lié à la lib A, et celui de la lib B, et je les fait tourner ensemble. Tu es obligé de faire un PCH spécifique qui ne marche que quand tu utilises A puis B.

Donc les PCH sont spécifiques à chaque projet, et doivent être générés dans chaque cas. Et se pose la question de savoir ce qu'on met dedans, et ce qu'on garde sous forme de #include en dehors du PCH. Si on n'en met pas assez, on est trop lent, si on en met trop, à chaque compilation incrémentale, on va devoir re-générer l'ensemble du PCH et perdre du temps.

On peut voir les modules comme des PCH mais qui sont composables, et où tu aurais un PCH par header (ou groupe de headers étroitement liés). Tu as généré le code précompilé pour A, celui pour B, tu peux les utiliser séparément ou ensemble, dans l'ordre que tu veux. Du coup, quand tu livres ta bibliothèque, tu livres le précompilé avec qui peut directement être réutilisé. Jamais tu n'auras besoin de le code client de parser les headers de cette bibliothèque. Pourquoi peut-on faire ça avec les modules, mais pas avec les PCH ? Voir ma réponse à la seconde question.

isolation from macros = en quoi les macros posent pb ?
Ce sont elles qui empêchent toute composabilité. Quand tu inclues un .h dans ton code, la manière de l'interpréter dépend de l'ensemble des macros définies au moment où tu l'inclues. Qui n'a jamais eu sous windows un problème pour inclure un header d'une bibliothèque third party après un #include <windows.h> parce ce dernier définit une macro min... L'idée de base est qu'un module ne dépende pas des macros définies avant qu'il soit importé, et qu'en retour, il ne pollue pas l'environnement avec ses propres macros. Et là, la modularité commence à apparaître.
Je dis "l'idée de base" parce que certains aimeraient bien pouvoir dire que sélectivement, telle ou telle macro définie dans un module pourrait être visible de l'extérieur. C'est en discussion.

il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Je ne pense pas qu'il s'agisse forcément de réels problèmes, mais d'une simple description de ce que les modules ne sont pas, pour éviter les confusions :

Namespaces : Certains langages (Java par exemple) lient structure physique du code (modules, fichiers source) et structure logique (namespaces, classes). D'autres ne le font pas (C# par exemple). La proposition de module pour le C++ choisi de ne pas le faire. Ce n'est en rien une limitation, mais un choix qui fait sens en C++ (sinon, comment ajouter une spécialisation de std::hash ?).
Versionning : On a déjà tous des outils pour gérer les versions, tu as parlé de nuget par exemple, je ne vois pas trop quel rôle les modules pourraient jouer là dedans, à part éventuellement en terme de réflexion, qui peut toujours s'ajouter.
Binary distribution : C'est un problème potentiel. Mais d'un autre côté, les autres langages ont bien réussi à résoudre ce problème. Quand on distribue une assembly .NET, c'est bien un binaire qu'on distribue, et ça fait déjà 15 ans que ça dure sans problèmes. Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent). Mais la situation ne sera pas pire que ce qu'elle est aujourd'hui : On risque de devoir quand même compiler une bibliothèque pour le compilo qu'on utilise, comme on le fait aujourd'hui. C'est juste qu'on risque aussi de ne pas avoir besoin de le faire, si le mainteneur de la bibliothèque nous fourni un module compilé pour notre compilateur, chose qui était très difficile avant, à cause des multiplicités de gestions de macros. Donc la situation ne devient pas parfaite, mais elle s'améliore quand même.

Et sinon, pour avoir expliqué à pas mal de débutants, oui, les #include, c'est compliqué. Et parfois même des professionnels aguerris galèrent pendant des heures pour faire un #include dans certains contextes...
3  0 
Avatar de Kikuts
Membre éprouvé https://www.developpez.com
Le 18/12/2014 à 10:42
Mamamia !! Si ça fonctionne bien, alors là je serais heureux !
Parce que copier coller une erreur dans google (bing ou autre) et ne rien trouver de pertinent, c'est relou ^^ alors si ça me fait économiser des minutes de recherche, pourquoi pas !
2  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 02/04/2015 à 12:35
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien

L'avantage de VS, c'est la floppée de designers et autres outils WYSIWYG liés aux diverses technos Microsoft.

Avis personnel : ces outils sont vraiment super pour les applis... simples (ou si on maîtrise pas bien les technos sous-jacentes). Il n'y a qu'à voir les tutos VS qu'on trouve sur MSDN, c'est toujours du "cliquez ici", "sélectionnez ça". Si un dev a tendance à tout faire "from scratch", ou pour les très grosses applis (pour lesquelles on a besoin d'industrialiser le code, factoriser dans tous les sens etc.), franchement VS n'a pas grand intérêt.
6  4 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 13:23
Citation Envoyé par Washmid Voir le message
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien

L'avantage de VS, c'est la floppée de designers et autres outils WYSIWYG liés aux diverses technos Microsoft.

Avis personnel : ces outils sont vraiment super pour les applis... simples (ou si on maîtrise pas bien les technos sous-jacentes). Il n'y a qu'à voir les tutos VS qu'on trouve sur MSDN, c'est toujours du "cliquez ici", "sélectionnez ça". Si un dev a tendance à tout faire "from scratch", ou pour les très grosses applis (pour lesquelles on a besoin d'industrialiser le code, factoriser dans tous les sens etc.), franchement VS n'a pas grand intérêt.

Comme tu le souligne, les outils de VS sont super.

Par contre sharpDevelop n'est pas au niveau (avis personnel , ne pas tapper)

Dans mon cas je travail sur des grosses applis avec VS et Eclipse , l'IDE ne remplace pas l'architecte, mais il permet d'aller très loin.
Ce que j'ai remarqué c'est que sur éclipse on travail généralement sur des projets unitairement plus petit .
Sur VS on travail plus souvent en mode "solution".

Il ne faut pas oublier que VS est, il me semble, le plus gros logiciel de Microsoft à ce jours ( certain diront "usine à gaz" , perso je serai nuancé et je dirait "achat SSD" ! ), il gère parfois de choses qu'on ne soupçonne pas et n'est pas dédié qu'a .NET .
3  1 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 14:26
Citation Envoyé par Washmid Voir le message
A propos de la taille des projets, si on a beaucoup de petits projets dans VS, il suffit de modifier un commentaire pour que cet abruti recompile l'intégralité des projets qui référencent le projet modifié.

Chez nous on a une "solution" à 40+ projets... Disons qu'heureusement que la fenêtre est fermée parce que l'ordi finirait sur le parking

Si tu prends eclipse dans la même situation, bah... la compilation étant incrémentale, c'est instantané (avec un capacité de montée en charge assez bluffante)

Conclusion Eclipse est une usine à gaz pour les petits "workspace" c'est vrai, Visual Studio le devient avec les grosses "solutions", et en mille fois pire.

Tu utilise quelle version de VS ( quel type de projet)?

perso 40 projets dans une seule solution ça me semble pas correct niveau conception ...
mais je suis sûr qu'on peut les faites tourner sans soucis.

c'est comme pour éclipse tu peux configurer ça...
car en effect si t'a des contrôles et qu'il recharge le designer pour tout les documents ouverts, les perfs peuvent êtres mauvaises.

Cela dit avec VS 2013 c'est asynchrone.
2  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 15:26
Citation Envoyé par Washmid Voir le message
Une grosse appli appliquant des règles métier issues de la réglementation dans notre domaine d'activité. En gros l'appli est complexe parce que la loi française l'est, tout simplement (500 000 lignes de code + 10 MO environ de données bruttes pour du paramétrage).

Et non, malheureusement, VS n'est absolument pas capable de faire tourner ça sans soucis. Il n'analyse pas le code pour la compilation, ce qui fait qu'il doit recompiler tout le code projet par projet quelque soit la nature de la modification.

Pour les designers on ne les utilise même plus, les problèmes apparaissent dès le lancement en debug de l'appli.

Si on fait le parallèle avec Eclipse :
- la compilation est classe par classe, contrairement à VS qui la fait projet par projet.
- la compilation des dépendances ne se limite qu'au strict nécessaire, quand VS recompile tout en cascade
- VS doit packager toutes les dll pour lancer en debug, Eclipse n'a besoin que des .class
- Eclipse recompile à l'enregistrement de chaque fichier source, VS recompile avant l'exécution

En somme, dans VS, si on modifie une ligne de code dans un projet "à la base" de la solution, il nous régénère des centaines de méga de binaires.

Testé avec VS2013 c'est le même délire (même comportement, performances un peu meilleures ceci dit)

Je bosse sur une solution pour le transport de 1,2 millions de lignes (16 projets)
et j'ai pas de soucis de lenteur sur un pc moyen tout en utilisant le designer...

L'erreur faut la chercher ailleurs je pense (process de l'entreprise, application ayant mal vécus, mauvaise configuration/conception).

Les seuls soucis (réels) de perf que j'ai eu c'était avec les plugins d'infragistics..
2  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 02/04/2015 à 15:39
Ou sinon tu peux "décharger" les 39 projets qui ne te servent pas, et recharger ceux que tu souhaites modifier.
S'agissant d'un paramètre utilisateur ca n'aura même pas d'impact sur les autres au niveau de ton gestionnaire de source.
2  0 
Avatar de kipy4
Membre du Club https://www.developpez.com
Le 30/06/2015 à 13:51
Cette monture a l'air sympa !

J'espère qu'ils ont prévu un vrai désinstalleur ce coup-ci * rêve tout haut *
2  0