- •Вопросы к экзамену.
- •Современная аис.
- •Группа проекта пс.
- •Жизненный цикл программных систем.
- •Case-средства.
- •Функциональная модель. Конкретизация требований к проектируемой системе с использованием функциональной модели.
- •Конкретизация требований к системе с использованием илм
- •Конкретизация требований к проектируемой системе с использованием вариантов использования.
- •Унифицированный язык моделирования uml.
- •Диаграмма вариантов использования uml.
- •Диаграмма классов uml.
- •Паттерны проектирования GoF.
- •Диаграмма взаимодействия uml.
- •Архитектура программной системы.
- •Диаграмма деятельности uml
- •Диаграмма состояний uml.
- •Модульное тестирование. Разработка посредством тестирования.
- •Ответ: tdd (Test Driven Development)
- •Диаграмма компонентов и диаграмма развёртывания uml.
- •Непрерывная интеграция и основные этапы интеграции.
Модульное тестирование. Разработка посредством тестирования.
Ответ: tdd (Test Driven Development)
Тест – это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную. В данном контексте тест состоит из двух этапов: стимулирование кода и проверки результатов его работы. Автоматический тест выполняется иначе: вместо программиста стимулированием кода и проверкой результатов занимается компьютер, который отображает на экране результат выполнения теста: код работоспособен или код неработоспособен.
Методика разработки через тестирование(Test-Driven Development, TDD) позволяет получить ответы на вопросы об организации автоматических тестов и выработке определенных навыков тестирования.
«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование. Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:
Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной, и можете не беспокоиться о длинной череде ошибок.
У разработчика появляется шанс усвоить уроки, которые преподносит ему код. Если он воспользуется первой же идеей, которая пришла ему в голову, у него не будет шанса реализовать вторую, лучшую идею.
Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них.
Разработчику приятнее писать такой код.
Однако как мы можем получить чистый код, который работает? Очень многие силы мешают нам добиться этого, а иногда нам не удается получить даже код, который работает. Чтобы избавиться от множества проблем, мы будем разрабатывать код, исходя из автоматических тестов. Такой стиль программирования называется разработкой через тестирование. В рамках этой методики мы:
Пишем новый код только тогда, когда автоматический код не сработал.
Удаляем дублирование.
Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:
Проектируя код, мы постоянно запускаем его и получаем представление о том, как он работает, это помогает нам принимать правильные решения.
Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас.
Наша среда разработки должна быстро реагировать на небольшие модификации кода.
Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.
Два упомянутых правила TDD определяют порядок этапов программирования:
Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.
Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
Рефакторинг – удалите из написанного вами кода любое дублирование.
Пример типичного блочного типа:
Типичный подход к тестированию поведения объекта заключается в его настройке на информацию из соответствующего контекста, вызове его методов и записи ряда утверждений для проверки возвращаемого значения или метода, изменившего состояние среды предполагаемым образом.
В приведенном ниже примере проверяется метод 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(), а затем проверяется сохраняемость это бизнес-объекта на информационном складе.