#define для всего решения

Почти все ответы, данные здесь, корректны, но, вероятно, стоит дать пример:

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].)

50
задан Brian Tompsett - 汤莱恩 28 November 2015 в 01:30
поделиться

1 ответ

Несколько лет спустя, и подобный ответу 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

0
ответ дан 7 November 2019 в 11:07
поделиться
Другие вопросы по тегам:

Похожие вопросы: