Почти все ответы, данные здесь, корректны, но, вероятно, стоит дать пример:
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].)
Несколько лет спустя, и подобный ответу Alexei, но поддерживаемый врожденно
можно сделать Directory.Build.props
подобный NuGet.Config
файл согласно
https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build? view=vs-2019
Наш взгляды как:
<Project>
<PropertyGroup>
<DefineConstants>RC_427</DefineConstants>
</PropertyGroup>
</Project>
И это эффективно включает это во все файлы CSPROJ в Вашем SLN. По некоторым причинам то конкретное решение безумно трудно найти через Google. Вокруг начиная с MSBuild 15