Модульное тестирование и тестирование пользовательского интерфейса в .NET - PullRequest
2 голосов
/ 26 ноября 2010

Я новичок в модульном тестировании.Я хочу знать, на каком уровне мне нужно проводить юнит-тестирование.Я в основном работаю над веб-приложениями.В настоящее время я работаю над книгой MVC, и они показали пару модульных тестов для разбивки по сетке и заполнения элемента управления меню.Нужно ли тестировать свойства бизнес-объекта, методы, уровень данных, хранимые процедуры и т. Д.?Я не хочу выглядеть параноиком и проверять все.Если это лучшая практика, я сделаю это.

Например, если предполагается, что свойство имени имеет длину 50 символов и может содержать только буквенные символы, тогда нужно ли проверять оба?

Я также использую библиотеку пользовательского интерфейса Yahoo, нужно ли мне это тоже проверять?

Какие инструменты модульного тестирования пользовательского интерфейса доступны?Я слышал, что есть фреймворки, которые позволяют вам издеваться над целым, даже если его там нет, и тогда вы можете протестировать страницу таким образом?Какие рамки для тестирования пользовательского интерфейса доступны?

Я хотел бы услышать как можно больше мнений?Будем благодарны любые предлагаемые книги для начинающих с большим количеством образцов.

Спасибо

Ответы [ 4 ]

2 голосов
/ 26 ноября 2010

Не тестируйте свойства, методы, данные и т. Д. Вместо этого опишите поведение, которое вы ищете, и приведите несколько примеров, которые показывают, как вы можете использовать класс.

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

Например, вы могли бы иметь валидатор, который читал бы:

[Test]
public void ShouldOnlyValidateAlphaNamesLessThan50Chars() {

    var validator = new Validator();

    Assert.IsTrue(validator.validates("An Alpha Name"));

    Assert.IsFalse(validator.validates(
        "A Really Really Long Name that's 51 characters xx"));
    Assert.IsFalse(validator.validates("A name with 1234 numbers"));
}

Этого достаточно, чтобы показать, какое поведение должен иметь валидатор.

Я бы поместил достаточно примеров в каждый метод тестирования, чтобы показать ценный характер кода. Экспериментируйте с этим. Некоторые люди предпочитают «Одно утверждение на тест», но это не должно быть так, если он работает лучше для вас по-другому.

Что касается сторонних библиотек, я подумаю о том, что они для вас делают, что это ценно, а затем оберну их в другой класс, который вы можете макетировать. Moq - мой любимый фреймворк для .NET.

Для тестирования пользовательского интерфейса, особенно для веб-страниц, я бы посмотрел на Selenium.NET. Однако это используется для тестирования всей системы - обычно мы не тестируем элементы пользовательского интерфейса. Это отчасти потому, что это сложно и дорого, а отчасти потому, что на самом деле смотреть на них, использовать их и играть с ними в контексте - это единственный способ проверить, что они ведут себя правильно.

QUnit - это фреймворк, который я видел, который использовался для тестирования Javascript, если вы используете его на своих страницах и хотите это тоже проверить.

1 голос
/ 28 ноября 2010

Тестирование нереально для большого приложения. Даже для небольших приложений вы будете тратить много времени на написание модульных тестов для всего. Только небольшая часть вашей системы на самом деле стоит модульного тестирования, так как большая часть кода выполняет тривиальную логику, и тестирование не является действительно полезным. Если вам платят по часам и у вас неограниченное время, я бы сказал, что вы можете проверить все. Но если вы работаете на временной шкале, вам нужно быть умным в том, что вы тестируете.

1 голос
/ 26 ноября 2010

Помимо согласия с другими ответами здесь, я также добавлю прагматический момент, который я считаю чрезвычайно полезным.

При обучении написанию тестов и привыкании к парадигме тестирования часто бывает труднознать, с чего начать и что проверить в первую очередь.Тестирование всего - это идеал, которого можно достичь, однако есть прагматический аспект того, сколько вы можете сделать прямо сейчас.

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

Примером, который я получил из недавнего проекта, является интеграция некоторых механизмов ведения блогов в наш сайт на основе канала от блоггера.Чтобы протестировать мой код, мне нужно создать проект блога, затем создать веб-проект, который ссылается на проект блога (который занимает около 3 минут в Visual Studio), а затем перейти к рассматриваемой странице (ожидая, пока код выйдетчерез последовательность событий при первом запуске после сборки), а затем приступить к тестированию того, что мне интересно.

Чтобы упростить этот процесс, вы можете начать писать тесты для подобных сценариев.Я фанат TDD и тестирования в целом, и я обнаружил, что такой подход действительно дает разработчику более обоснованное представление о том, как и почему тестирование может быть полезным.Вы действительно можете сразу увидеть преимущества, сократив количество времени и шагов, необходимых для тестирования некоторых функций.Менеджеры также могут высоко ценить это.(Он немного менее пушист, чем некоторые из более идеалистических концепций и шуток, окружающих тестирование.)

Этот подход также вводит вас в увлекательный аспект написания тестов.Как и во всем, если вы начнете с выяснения того, как вы можете наслаждаться процессом, вы, скорее всего, продолжите его делать.

Я работал со многими евангелистами, которые отмахивались от любого веселья или интересовалиНовый разработчик, возможно, нашел в результате тестирования и сделал весь процесс очень религиозным.Сделайте тестирование увлекательным, и вы с большей вероятностью захотите протестировать больше своего кода.

1 голос
/ 26 ноября 2010

Да, я бы протестировал «все», однако тестирование пользовательского интерфейса, как правило, сложное и хрупкое для тестирования, в интересах прагматизма, я бы сохранял ваш код пользовательского интерфейса как можно меньшим и просто был бы осторожен.

Определенно тестируйте весь «бизнес-код».

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

Старайтесь тестировать только ОДНУ вещь одновременно - тестирование «системы» приводит к усложнению и ломкости теста системы.

Когда я говорю «хрупкий», я имею в виду «простойизменение в одной части системы означало, что вам придется переписать половину ваших тестов ".Вы хотите, чтобы изменения оказали влияние только на несколько тестов, которые фактически тестируют этот код.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...