Quelle est la différence entre Assert.AreNotEqual et Assert.AreNotSame?

Question

En C #, quelle est la différence entre

 Assert.AreNotEqual
 

et

 Assert.AreNotSame
 

Answer 1

Presque toutes les réponses ici sont correctes, mais il est probablement utile de donner un exemple:

public static string GetSecondWord(string text)
{
    // Yes, an appalling implementation...
    return text.Split(' ')[1];
}

string expected = "world";
string actual = GetSecondWord("hello world");

// Good: the two strings should be *equal* as they have the same contents
Assert.AreEqual(expected, actual);

// Bad: the two string *references* won't be the same
Assert.AreSame(expected, actual);

AreNotEqual et AreNotSame sont juste des inversions de AreEqual et AreSame de cours.

EDIT: UNE réplique à la actuellement accepté de répondre...

Si vous utilisez Assert.AreSame avec des types valeur, ils sont emballés. En d'autres termes, c'est équivalent à:

int firstNumber = 1;
int secondNumber = 1;
object boxedFirstNumber = firstNumber;
object boxedSecondNumber = secondNumber;

// There are overloads for AreEqual for various value types
// (assuming NUnit here)
Assert.AreEqual(firstNumber, secondNumber);

// ... but not for AreSame, as it's not intended for use with value types
Assert.AreSame(boxedFirstNumber, boxedSecondNumber);

Ni firstNumber ni secondNumber a un objet de valeur, car int est un type valeur. La raison pour laquelle le AreSame va échouer, c'est parce que dans .NET, la boxe une valeur crée une case à chaque fois. (En Java, il n'a parfois pas - cela m'a pris avant.)

Fondamentalement, vous devriez ne jamais les utiliser AreSame lorsque l'on compare les types de valeur. Lorsque vous comparez référence types, utilisez AreSame si vous souhaitez vérifier les références identiques; utiliser AreEqual pour vérifier l'équivalence en vertu de l' Equals. EDIT: à Noter qu'il y sont des situations où NUnit ne pas simplement utiliser Equals directement; il a un support intégré pour les collections, où les éléments dans les collections sont testés pour l'égalité.

La demande dans la réponse que:

À l'aide de l'exemple ci-dessus, la modification de la int string, AreSame et AreEqual reviendra de la même valeur.

tout dépend comment les variables sont initialisées. S'ils utilisent des littéraux de chaîne, puis encore, un stage prendra soin de cela. Si, toutefois, vous utilisez:

string firstString = 1.ToString();
string secondString = 1.ToString();

puis AreSame et AreEqual sera presque certainement pas retourner la même valeur.

Comme pour:

La règle générale est d'utiliser AreEqual sur les types valeur et AreSame sur les types de référence.

J'ai failli ne jamais vouloir vérifier l'identité des références. Il est rarement utile pour moi. Je veux vérifier l'équivalence qui est ce que l' AreEqual des chèques pour. (Je ne dis pas qu' AreSame ne devrait pas être là - c'est une méthode utile, juste beaucoup plus rarement qu' AreEqual.)

Answer 2

Deux choses peuvent être égaux, mais différents objets. AreNotEqual vérifie les objets de valeurs via le test d'égalité, tandis que AreNotSame vérifie qu'ils ne sont pas exactement le même objet.

Il est évident pourquoi nous voudrions tester que les choses AreNotEqual (nous nous soucions les valeurs testées); qu'en AreNotSame? L'utilité de ce dans les essais est trouvé lorsque vous avez passé de références autour de et voulez vous assurer que, après votre brassage est effectué que deux références sont toujours le même objet.

Dans un cas réel, nous utilisons beaucoup de la mise en cache des objets pour atténuer les allers-retours à la base de données. Une fois qu'un objet a été transféré vers le système de cache, nos tests unitaires s'assurer que, dans certains cas, on retrouve le même objet (le cache est valide) et dans d'autres cas, on obtient un frais d'objet (cache a été invalidé). Notez que AreNotEqual ne serait pas nécessaire suffire dans ce cas. Si l'objet avait un nouveau timestamp dans la base de données, mais les données n'a pas été "suffisamment différentes pour" l'échec d'un test d'égalité, AreNotEqual ne serait pas l'avis que nous avons actualisé l' objet.

Answer 3

AreNotSame fait une comparaison de référence, alors qu'AreNotEqual fait une comparaison d'égalité.

Answer 4

Affirmer.AreNotEqual affirme que les deux valeurs ne sont pas identiques les uns aux autres.

Affirmer.AreNotSame affirme que les deux variables ne pointent pas vers le même objet.

Exemple 1:

int i = 1;
int j = i;
// Les valeurs sont égales:
Affirmer.AreEqual(i, j);
// Deux types de valeur ne *pas* de représenter le même objet:
Affirmer.AreNotSame(i, j);

Exemple 2:

string s = "Un";
string t = s;
// Les valeurs sont égales:
Affirmer.AreEqual(s, t);
// Les types de référence *peut* pointent vers le même objet:
Affirmer.AreSame(s, t);

Answer 5

AreNotSame utilise l'égalité de référence ( object.ReferenceEquals ) - autrement dit, s'agit-il de la même instance réelle d'un objet; AreNotEqual utilise l'égalité conceptuelle ( .Equals ) - autrement dit, est-il considéré comme égal.