Comment la trace de pile de mon test d'unité ne pouvait-elle pas correspondre à la source réelle?

Question

Dans une bibliothèque de classe C# et ensemble de tests. Tout allait bien jusqu'à ce que j'ajoute un nouvel ensemble de tests - ils fonctionnent correctement sur ma machine, mais échouent sur le serveur de construction TFS. La trace de pile dans le journal de construction n'a aucun sens - le constructeur d'une classe semble être mappé à l'une de ses méthodes.

Si ma classe ressemble un peu à ceci:

1. public class ClassToBeTested 
2. { 
3. 
4.  /// <summary> 
5.  /// Default constructor. 
6.  /// </summary> 
7.  public ClassToBeTested() 
8.  { 
9. 
10.  } 
11. 
12.  /// <summary> 
13.  /// Default constructor. 
14.  /// </summary> 
15.  public MethodToTest() 
16.  { 
17.   /* do stuff that throws exception */ 
18.  } 
19. 
20. } 

Et dans ma classe de test unitaire j'ai ceci:

1. [TestMethod()] 
2. public void UpdateTest() 
3. { 
4.  ClassToBeTested Target = new ClassToBeTested(); 
5.  ClassToBeTested.MethodToTest(); 
6. } 

Ensuite ma trace de la pile indique ceci:

Méthode d'essai unittestclass.UpdateTest a lancé l'exception/quel que soit/
ClassToBeTested.MethodToTest(): Ligne 17
unittestclass.UpdateTest(): Ligne 4

Comment est-ce possible?

Answer 1

Je pense que le code dans la méthode qui déclenche une exception peut avoir quelque chose à voir avec cela. surtout si quelque chose là-dedans a un constructeur statique: peut-être cela peut faire la lumière:

http://msmvps.com/blogs/jon_skeet/archive/2010/01/26/type-initialization-changes-in-net-4-0.aspx

mais pour plus d'aide ... peut-être la méthode de code manquant de détails et/ou type d'exception.

Vérifiez aussi que votre configuration de construction sur votre machine de débogage est le même que votre serveur de build .. ou essayer de tester dans la publication/configuration de libération