Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы к экзамену 2012.docx
Скачиваний:
4
Добавлен:
20.09.2019
Размер:
583.63 Кб
Скачать
  1. Модульное тестирование. Разработка посредством тестирования.

  1. Ответ: tdd (Test Driven Development)

Тест – это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную. В данном контексте тест состоит из двух этапов: стимулирование кода и проверки результатов его работы. Автоматический тест выполняется иначе: вместо программиста стимулированием кода и проверкой результатов занимается компьютер, который отображает на экране результат выполнения теста: код работоспособен или код неработоспособен.

Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.

«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:

  • Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной, и можете не беспокоиться о длинной череде ошибок.

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

  • Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них.

  • Разработчику приятнее писать такой код.

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

  • Пишем новый код только тогда, когда автоматический код не сработал.

  • Удаляем дублирование.

Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

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

  • Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас.

  • Наша среда разработки должна быстро реагировать на небольшие модификации кода.

  • Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.

Два упомянутых правила TDD определяют порядок этапов программирования:

  1. Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.

  2. Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

  3. Рефакторинг – удалите из написанного вами кода любое дублирование.

Пример типичного блочного типа:

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

В приведенном ниже примере проверяется метод SaveUser () бизнес-компонента UserBC, иллюстрируя данный подход:

[Test Rollback] // Автоматический откат

// (использование служб без компонентов)

Public void TestUserBCCanSaveUser()

{

// Настройка информации из контекста (входные условия)

UserInfo user = Userinfo(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

// Это еще не тестирование, а уточнение исходного состояния

Assert.IsTrue(user.IsNew);

Assert.AreEqual (New_Object_Id, user.id);

Assert.IsFalse(

IsUserInsertedInDatabase(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

// Входные условия заданны - далее следует выполнение проверяемого метода

UserBC bcUser = new UserBC()

bcUser.SaveUser(user);

// Проверка выходных условий

Assert.IsFalse(user.IsNew);

Assert.IsTrue (user.id != New_Object_Id,);

Assert.IsTrue(

IsUserInsertedInDatabase(

“Claudio”, “Perrone”, “MyUniqueLogin”, “MyPassword”);

Бизнес-компонент UserBC применяет бизнес-объект и сохраняет его в базе данных, поэтому в данном тексте проверяется его поведение, для чего создается бизнес-объект, который передается виде параметра методу SaveUser(), а затем проверяется сохраняемость это бизнес-объекта на информационном складе.