Каково различие между, Утверждают. AreNotEqual и Утверждают. AreNotSame?
6 ответов
Почти все ответы, данные здесь, корректны, но, вероятно, стоит дать пример:
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 и AreNotSame просто инверсии AreEqual и AreSame, конечно.
РЕДАКТИРОВАНИЕ: опровержение к в настоящее время принимаемый ответ ...
, Если Вы используете Assert.AreSame с типами значения, они упаковываются. Другими словами, это эквивалентно выполнению:
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);
Ни firstNumber, ни secondNumber имеет объектное значение, потому что int тип значения. Причина эти AreSame вызов перестанет работать, то, потому что в.NET, упаковывая значение создает новое поле каждый раз. (В Java это иногда не делает - это ловило меня прежде.)
В основном Вы должны никогда использование AreSame при сравнении типов значения. Когда Вы выдерживаете сравнение ссылка типы, используйте AreSame, если Вы хотите проверить на идентичные ссылки; используйте AreEqual для проверки на эквивалентность под [1 115].Править: Обратите внимание, что там ситуации, где NUnit не просто использует Equals непосредственно; это имеет встроенную поддержку наборов, где элементы в наборах тестируются на равенство.
заявление в ответе, что:
Используя пример выше изменения интервала для строкового представления AreSame и AreEqual возвратят то же значение.
полностью зависит от того, как переменные инициализируются. Если они будут использовать строковые литералы, то все же, интернирование будет заботиться об этом. Если, однако, Вы используете:
string firstString = 1.ToString();
string secondString = 1.ToString();
затем AreSame и AreEqual будут почти наверняка не , возвращают то же значение.
Что касается:
общее эмпирическое правило состоит в том, чтобы использовать AreEqual на типах значения и AreSame на ссылочных типах.
я почти [1 127] никогда не хотят проверить на ссылочные идентификационные данные. Это редко полезно для меня. Я хочу проверить на [1 128] эквивалентность , который является что AreEqual проверки на. (Я не говорю, что AreSame не должен быть там - это - полезный метод, просто намного более редко, чем [1 119].)
Двумя вещами могут быть равные, но различные объекты. AreNotEqual проверяет объекты значения через тест равенства, в то время как AreNotSame проверяет, что они не тот же точный объект.
очевидно, почему мы хотели бы протестировать это вещи AreNotEqual (мы заботимся о протестированных значениях); что относительно AreNotSame? Полноценность этого в тестировании найдена, когда Вы раздали ссылки и хотите удостовериться, что после того, как Ваша перестановка сделана, что две ссылки являются все еще тем же объектом.
В случае реального мира, мы используем большое кэширование объектов смягчить распространения в прямом и обратном направлениях к базе данных. После того, как объект был передан к системе кэша, наши модульные тесты гарантируют, чтобы в некоторых случаях мы возвратили тот же объект (кэш был допустим), и в других случаях мы возвращаемся новый объект (кэш делался недействительным). Обратите внимание, что AreNotEqual не был бы необходимый быть достаточным в этом случае. Если объект имел новую метку времени в базе данных, уже , данные "не достаточно отличались" для проваливания теста равенства, AreNotEqual не заметит, что мы обновились объект .
Утверждать. AreNotEqual утверждает, что два значения не равны друг другу.
Утверждают. AreNotSame утверждает, что две переменные не указывают на тот же объект.
Пример 1:
int i = 1; int j = i; // The values are equal: Assert.AreEqual(i, j); // Two value types do *not* represent the same object: Assert.AreNotSame(i, j);
Пример 2:
string s = "A"; string t = s; // The values are equal: Assert.AreEqual(s, t); // Reference types *can* point to the same object: Assert.AreSame(s, t);
AreNotSame действительно ссылается на сравнение, тогда как AreNotEqual делает сравнение равенства.
Использование AreNotSame ссылочное равенство (object.ReferenceEquals) - т.е. является ими тот же фактический экземпляр объекта; AreNotEqual использует концептуальное равенство (.Equals) - т.е., они рассмотрели равный.
Не это так, чтобы AreNotEqual проверил на случай, где два объекта не равны с точки зрения, Равняется () методу, тогда как AreNotSame проверяет на случай, где эти две ссылки на объект не являются тем же. Таким образом, если X и Y являются двумя объектами, которые равны с точки зрения, Равняется (), но были отдельно выделены, AreNotEqual () инициирует провальное утверждение, но другой нет.