По мере увеличения сложности и важности приложений для iOS, разработчики должны гарантировать неизменное повышение качества прикладного кода. Это означает необходимость использования новейших приемов создания и тестирования приложений. Разработка через тестирование (Test-Driven Development, TDD) - один из таких приемов. Книга \"Разработка через тестирование для iOS\" - первая, которая полностью сосредоточена на том, чтобы помочь вам успешно внедрить приемы TDD и модульного тестирования в окружение iOS. Опытный разработчик Грэхем Ли поможет вам быстро внедрить приемы TDD в процесс разработки с использованием Xcode 4 и фреймворка модульного тестирования OCUnit. Он проведет вас через создание законченного приложения с применением приема разработки через тестирование, от начальной спецификации до функционального продукта. Ли также представит мощные шаблоны применения TDD в разработке и познакомит с новейшими автоматизированными средствами тестирования, которые скоро появятся на платформе iOS.

  Литрес - 399 руб.

Обычно конечной целью многих проектов разработки программного обеспечения является получение прибыли. Типичными путями достижения этой цели являются прямые продажи программного обеспечения, реализация через Интернет-магазин или некоторая схема лицензирования его использования. Программы, создаваемые разработчиками для внутреннего использования, часто приносят прибыль косвенным путем, увеличивая производительность труда и уменьшая время, затрачиваемое на разработку. Если экономия, в терминах эффективности труда, больше стоимости разработки программы, проект можно считать выгодным. Разработчики открытых проектов часто продают услуги по поддержке пакетов или сами используют свои программы: в этих случаях предыдущий аргумент остается справедливым. Итак, с экономической точки зрения все просто: если целью программного проекта является получение прибыли (будь то программный продукт на продажу или для внутреннего использования), его ценность для пользователя должна быть выше стоимости. Я понимаю, что не сказал ничего нового, но это утверждение имеет следствия, важные для тестирования программного обеспечения. Если тестирование (также известное, как контроль качества) рассматривать как нечто, обеспечивающее поддержку программного проекта, оно должно служить цели получения прибыли. Это важное обстоятельство, потому что оно автоматически накладывает ограничения на то, как должен тестироваться программный продукт: если тестирование является настолько дорогостоящим, что приносит убытки, значит выбранный способ тестирования не соответствует цели. Однако тестирование может доказать работоспособность продукта, то есть, доказать, что продукт обладает ценными качествами, ожидаемыми клиентами. Если не продемонстрировать эти качества, клиент может отказаться от покупки продукта. Обратите внимание, что целью тестирования является демонстрация работоспособности продукта, а не вскрытие ошибок. Это конт роль качества, а не увеличение качества. Обнаружение ошибок – это плохо. Почему? Потому что устранение ошибок стоит денег и эти деньги тратятся впустую, потому что вам заплатили за создание программы без ошибок. В идеальном мире разработчики просто писали бы безошибочные программы, выполняли небольшое тестирование, чтобы убедиться в отсутствии ошибок, выгружали бы свои программы на iTunes Connect и ждали, пока деньги посыплются на них. Но постойте: такая организация труда может повлечь за собой убытки. Насколько дольше разработчику придется писать программу, чтобы до тестирования быть в полной уверенности в отсутствии ошибок? Сколько это будет стоить? Таким образом, уровень тестирования программ представляет собой компромисс между необходимой степенью контроля и степенью убежденности в работоспособности программы, без значительного удорожания проекта. Как определить этот компромисс? Он основывается на снижении до приемлемого уровня рисков, связанных с продажей продукта. Первыми должны тестироваться наиболее «рискованные» компоненты, которые являются наиболее важными для функционирования программы или где по вашему мнению может скрываться большая часть ошибок. Затем компоненты, следующие по степени риска, и так далее, пока степень риска не снизится до уровня, когда не имеет смысла тратить время и деньги на дальнейшее его снижение. Конечной целью должна быть демонстрация клиенту возможностей программы, за которые он захочет заплатить.

ПРЕДИСЛОВИЕ
БЛАГОДАРНОСТИ
ОБ АВТОРЕ
ГЛАВА 1. О тестировании программного
обеспечения и модульном тестировании
ГЛАВА 2. Приемы разработки через тестирование
ГЛАВА 3. Как писать модульные тесты
ГЛАВА 4. Инструменты для тестирования
ГЛАВА 5. Разработка приложений для iOS через
тестирование
ГЛАВА 6. Модель данных
ГЛАВА 7. Проектирование приложений
ГЛАВА 8. Взаимодействие с сетью
ГЛАВА 9. Контроллеры представлений
ГЛАВА 10. Собираем все вместе
ГЛАВА 11. Проектирование при разработке через
тестирование
ГЛАВА 12. Применение приема разработки через
тестирование к существующим проектам
ГЛАВА 13. За рамками сегодняшних возможностей
разработки через тестирование
ПРЕДМЕТНЫЙ УКАЗАТЕЛЬ