ASP.NET - Как вы тестируете модули WebControls?

Question

Хорошо.

Так что я полагаю, что пришло время приступить к модульному тестированию, так как все достаточно долго об этом говорили. Я установил NUnit и прошел несколько обучающих программ типа "введение в модульное тестирование".

В настоящее время я собираю небольшую инфраструктуру, чтобы помочь с перестройкой одного из наших веб-приложений, поэтому я создал проект VS2008 для своей платформы и хочу протестировать его по мере выполнения.

Как же я могу провести модульное тестирование WebControls? Все методы защищены или являются частными, и, поскольку это фреймворк, нет ничего другого, кроме WebControls.

Есть указатели?

Ожоги

Answer 1

Вы можете создать архитектуру типа модель-вид-контроллер или модель-вид-презентатор без использования полноценного фреймворка. Вы уже узнали, что юнит-тестирование юнит-компонентов сложно. Есть способы обойти это, но вы, вероятно, не хотите идти по этому пути. Обычно это делает ваши тесты очень трудными для обслуживания, больше кошмаров на обслуживание - это то, без чего программисты могут обойтись: -)

Попробуйте выделить функциональность, которую вы хотите протестировать, в классе «контроллер» или «презентатор». Затем проверьте этот класс. Чтобы сделать его более тестируемым, вы можете скрыть класс usercontrol (представление) за интерфейсом и заставить контроллер или докладчика общаться с представлением через интерфейс. Таким образом, вы можете смоделировать представление в ваших тестах.

Я знаю, что это звучит как большая работа, и кажется, что это обходной путь, но если вы привыкнете к этому, это действительно хорошая архитектура, которая значительно упрощает изменение поведения пользовательского интерфейса. Вы всегда можете начать использовать «настоящий» MVC-фреймворк, когда вам это действительно необходимо: -)

Answer 2

Использует атрибут assembly:InternalsVisibleTo, и вы сможете получить доступ к этим закрытым членам.

Поместите его в AssemblyInfo.cs вашего проекта webcontrol (в разделе Свойства )

[assembly:InternalsVisibleTo("YourTestProjectName")]

Answer 3

Вы нашли самую большую болевую точку ASP.NET. Насколько закрыты, частные классы, которые мешают юнит-тестированию.

Это основная причина, по которой сотрудники TDD будут использовать инфраструктуру MVC (ASP.NET MVC, Castle MonoRail), поскольку она обеспечивает четкое отделение от ваших шаблонов представлений и логики вашего контроллера. Контроллеры полностью тестируемы.

Answer 4

Вы также можете посмотреть на тестирование компонентов через браузер, поскольку пользователь увидит их, используя среду тестирования, такую ​​как WebAii . Я видел, как это работает, и это довольно круто. Мне также сказали, что вы можете подключить его к автоматизированным сборкам, но я еще не видел этого.

Надеюсь, это поможет ...

Answer 5

Эта на данный момент старая статья, но я использовал NUnitASP для написания единичных тестов для asp.net WebControls в 2004 году. В этой статье представлен подробный пример тестирования простого элемента управления с использованием их концепции создания соответствующий класс "Tester", который инкапсулирует детали вашего контроля из ваших тестов. Тестер также может (должен) находиться в той же сборке, что и ваш элемент управления, поэтому может делиться между ними некоторыми вещами (например, функциями утилит, константами и т. Д.).

Я использовал технику (и другие используют варианты техники) до сих пор для тестирования очень сложных элементов управления.

Надеюсь, это полезно.

Answer 6

Вы тестируете их так:

[Test]
public void ConditionQueryBuilderTest_RendersProperHtml()
{
    var sw = new StringWriter();
    var queryBuilder = new ConditionQueryBuilderStub
    {
        ID = "UnitTestbuilder",
        QueryBuilderURL = @"\SomeAspxPage\SomeWebMethod",
        ResetQueryBuilderURL = @"\SomeAspxPage\OnQueryBuilderReset",
        FilterValuesCollection = new Dictionary<int, string> { {15, "Some Condition"}}
    };
    queryBuilder.RenderAllContents(new HtmlTextWriter(sw));

    AppendLog(sw.ToString());

    Assert.AreEqual(ExpectedHtml, sw.ToString()); // ExpectedHTML is the raw expected HTML
}

Вот моя заглушка:

internal class ConditionQueryBuilderStub : ConditionQueryBuilder // ConditionQueryBuilder is a WebControl
{
    internal void RenderAllContents(HtmlTextWriter writer)
    {
        RenderContents(writer);
    }
}

Answer 7

Ивонна может тестировать WebControls изолированно, в контексте Asp.Net Просто вызовите session.GetControl ("Path.ascx") и убедитесь, что он обладает всеми необходимыми свойствами.

Answer 8

Вы также можете взглянуть на эту Rhino Igloo framework. Это скомпрометированная инфраструктура MVC для WebForms.

Answer 9

Упомянутая выше инфраструктура MVC - лучший способ проверить, что делает элемент управления. Однако тестирование как это работает немного по-другому.

Это совершенно неуместно, но вы можете заставить пользовательский элемент управления предоставлять некоторые защищенные методы и свойства, чтобы возвращать информацию проверки, а затем наследовать ее от тестирующего пользовательского элемента управления. Этот элемент управления может заполнять поля, нажимать кнопки, а что нет. Вид грязный, но это может сработать.