Discussion :

[KhaledZero]

Bonjour,

comment modifier le test générer automatiquement par visual studio 2010:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
[TestMethod()]
public void getEmployeeAvecPlusDunCompteTest()
{
   IEnumerable<SalesForceUser> expected = null; // TODO: Initialize to an appropriate value
   IEnumerable<SalesForceUser> actual;
   actual = Program.getEmployeeAvecPlusDunCompte();
   Assert.AreEqual(expected, actual);
   Assert.Inconclusive("Verify the correctness of this test method.");
}

sachant que ma methode utilise des variables static de classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public static List<SalesForceUser> listSforce;
 
public static IEnumerable<SalesForceUser> getEmployeeAvecPlusDunCompte()
{
  var employeeAvecPlusDunCompt = from SalesForceUser userInchatter in listSforce
                                           from SalesForceUser userInchatter2 in listSforce
                                           where userInchatter.EmployeeNumber.Equals(userInchatter2.EmployeeNumber) && !(userInchatter.Username.Equals(userInchatter2.Username))
                                                 && !(userInchatter.EmployeeNumber.Equals("DONOTUPDATE") && (userInchatter.IsActive.Equals("true")))
                                           orderby userInchatter.EmployeeNumber
                                           select userInchatter;
  return employeeAvecPlusDunCompt;
}

Merci.

[MaximePalmisano]

Il faut savoir que le static, c'est l'ennemi des tests unitaires.

Y a t il une réelle nécessité à rendre cette méthode statique ?

[KhaledZero]

Il faut savoir que le static, c'est l'ennemi des tests unitaires.

Y a t il une réelle nécessité à rendre cette méthode statique ?

je reprends un code de plus de 8000 lignes et je crois pas que je vais le changer juste pour les testes

[Babyneedle]

je reprends un code de plus de 8000 lignes et je crois pas que je vais le changer juste pour les testes

Bah justement, du code qui ne se teste pas, c'est du code qui ne devrait jamais être déployé, encore moins vendu.

Dans mon équipe, c'est une offense qui a déjà mené à des licenciements, avec raison.

Donc soit que tu mettes le code aux standards du 3ième millénaire ou bien tu acceptes de livrer du code médiocre.

[KhaledZero]

pourquoi les "static" c'est des ennemis des testes unitaire ?

[MaximePalmisano]

je reprends un code de plus de 8000 lignes et je crois pas que je vais le changer juste pour les testes

<ironique>En effet, ça serait dommage d'avoir du code fiable et testable.</ironique>

pourquoi les "static" c'est des ennemis des testes unitaire ?

Parce que c'est relatif à la classe, et non à l'instance, et que cela implique un état persistant tout le long du programme.

[Babyneedle]

pourquoi les "static" c'est des ennemis des testes unitaire ?

Quand on définit une entité comme statique, on délègue le cycle de vie de cette entité au framework. C'est une facilité d'intégration puisque vous n'avez pas à créer une instance, c'est la machine virtuelle qui s'en occupe.

Par contre, vous n'avez plus de 'handle' (de prise) sur l'instance.

Le propre des tests unitaires est d'isoler chaque entité de ses dépendances en utilisant, par exemple, des stubs ou des mocks (Moq, Rhinomock, etc.).

Or n'ayant aucune prise sur le cycle de vie d'une entité empêche justement de la manipuler en ce sens.

Le gain apparent à l'origine de l'utilisation d'entités statiques devient un cauchemar pour un projet moindrement d'envergure puisque l'équipe est condamnée à tester à l'aide de tests d'intégration, beaucoup plus demandants que des tests unitaires.