C # «внутренний» модификатор доступа при выполнении модульного тестирования
Просто добавьте немного подтверждения в ответ Майкла:
Следующий код компилируется и запускается:
public class Program
{
public class Foo : IFoo
{
}
[Guid("00000000-0000-0000-0000-000000000000")]
[CoClass(typeof(Foo))]
[ComImport]
public interface IFoo
{
}
static void Main(string[] args)
{
IFoo foo = new IFoo();
}
}
Вам нужны как ComImportAttribute, так и GuidAttribute
Также обратите внимание на информацию, когда вы наводите курсор мыши на new IFoo(): Intellisense правильно подбирает информацию: Nice!
4 ответа
Внутренние классы должны быть протестированы и есть атрибут сборки:
using System.Runtime.CompilerServices;
[assembly:InternalsVisibleTo("MyTests")]
Добавьте это в файл информации о проекте, например Properties \ AssemblyInfo.cs .
Если Вы хотите протестировать закрытые методы, взглянуть на PrivateObject и PrivateType в Microsoft.VisualStudio.TestTools.UnitTesting пространство имен. Они предлагают простые в использовании обертки вокруг необходимого отражательного кода.
Документы: PrivateType, PrivateObject
Для VS2017 & 2019, можно найти их путем загрузки MSTest. TestFramework nuget
Можно использовать частный также, и можно назвать закрытые методы с отражением. При использовании Комплекта Команды Visual Studio, он имеет некоторую хорошую функциональность, которая генерирует прокси для вызова закрытых методов для Вас. Вот статья проекта кода, которая демонстрирует, как можно сделать работу сами к модульному тесту закрытые и защищенные методы:
http://www.codeproject.com/KB/cs/testnonpublicmembers.aspx
, С точки зрения которого модификатора доступа необходимо использовать, мое общее эмпирическое правило является запуском с частным, и возрастите по мере необходимости. Тем путем Вы выставите такие небольшие внутренние детали Вашего класса, как действительно необходимы, и он помогает сохранить детали реализации скрытыми, как они должны быть.
-
1Это бросит не имеющую ссылки ошибку в IE. Предпочтительное тело той функции
return typeof window[$Name] !== 'undefined';. Обратите внимание на то, что Вы передали бы ту функцию строка, содержащая название переменной. Вероятно, легче просто проверить, существует ли переменная в коде вызова (это не может быть реализовано как функция) черезif (typeof var !== 'undefined'). – Anthony DiSanti 10 September 2011 в 07:36
Продолжайте использовать частный по умолчанию. Если бы участник не должен быть подвергнут кроме того тип, то он не должен быть выставлен кроме того тип, даже к в рамках того же проекта. Это сохраняет вещи более безопасными и более опрятными - при использовании объекта это более ясно, какие методы Вы предназначены, чтобы смочь использовать.
Однако я думаю, что разумно сделать естественно-закрытые-методы внутренними в тестовых целях иногда. Я предпочитаю, что к использованию отражения, которое недружелюбно рефакторингом.
Одной вещью рассмотреть мог бы быть суффикс "ForTest":
internal void DoThisForTest(string name)
{
DoThis(name);
}
private void DoThis(string name)
{
// Real implementation
}
Затем при использовании класса в рамках того же проекта очевидно (сейчас и в будущем), что Вы не должны действительно использовать этот метод - это только там в тестовых целях. Это - немного hacky и не что-то, что я делаю самостоятельно, но это является, по крайней мере, стоящим рассмотрения.