Комментарии 11
А когда же начнется само unit-тестирование?
Я имею ввиду, что Вы просто описали каждую функцию и для чего она. Но начинающим не хватает какого-нибудь мало-мальски работающего приложения (небольшого), где уже НА ПРАКТИКЕ показали бы, как используется это unit-тестирование. Где был бы разобран каждый вид (Равенство базовых типов, Проверка на nil, Проверка на выбрасывание исключения и т.д.). Хотя, наверно, в рамках одной статьи такое тяжело написать. Надо маленькую книжку написать.
Никак не могу начать писать unit-тесты для своих приложений, потому что не могу понять вообще зачем оно мне и как, и для чего мне их писать. Именно на практике.
Я имею ввиду, что Вы просто описали каждую функцию и для чего она. Но начинающим не хватает какого-нибудь мало-мальски работающего приложения (небольшого), где уже НА ПРАКТИКЕ показали бы, как используется это unit-тестирование. Где был бы разобран каждый вид (Равенство базовых типов, Проверка на nil, Проверка на выбрасывание исключения и т.д.). Хотя, наверно, в рамках одной статьи такое тяжело написать. Надо маленькую книжку написать.
Никак не могу начать писать unit-тесты для своих приложений, потому что не могу понять вообще зачем оно мне и как, и для чего мне их писать. Именно на практике.
В данный момент график сильно забит (данная статья была написана еще в воскресенье), но чуть позднее (предположительно под конец июня) смогу сесть и написать разбор небольшого приложения под iOS, написанного через тестирование (TDD). Главное нужно будет придумать, что должно быть в этом приложении, чтобы не пришлось объяснять помимо тестирование моменты.
p.s. А вы скачивали исходники проекта? Кроме описания каждой функции, есть так же небольшой пример использования.
p.s. А вы скачивали исходники проекта? Кроме описания каждой функции, есть так же небольшой пример использования.
Хорошо, будем ждать. Надеюсь, не только мне это пригодится.
p.s. Скачал. На само приложение не делает ровным счетом ничего :-)
p.s. Скачал. На само приложение не делает ровным счетом ничего :-)
P.S. Людям, которые пока еще не вкурили TDD я предлагаю не пытаться начинать свой опыт в тестировании именно с него. TDD — довольно спорная практика и, как правило, на реальных проектах при сильной изменчивости требований в начале разработки от нее больше вреда, чем пользы.
А тестировать свой код надо. Почему надо?
1. Банальное сравнение. Для того, чтобы проверить свой код без тестов — вам надо запустить проект, дощелкать до нужного места (на одном из проектов, где я работал, это занимало порядка полутора минут), после этого проверить требуемый кейс. В то время как собственно тест займет в худшем случае секунд 15 (при правильной настройке окружения)
2. Более того мало у кого хватит терпения при таком раскладе проверить все возможные ветки исполнения кода (особенно, если это касается edge-кейсов, что программа работает корректно, когда что-то идет не так)
Так что предлагаю вам начать с простого. Настройте тестовое окружение и на любую чисто логическую функциональность напишите тест. В практически любой программе есть 1-2 чисто функциональных модуля, которые берут какие-то данные и что-то с ними делают. Да, поначалу это будет казаться довольно очевидным, но это пройдет довольно быстро :-)
P.S. посмотрите репозитории по ссылкам в комментарии ниже — там можно найти довольно много вдохновения по тестам.
А тестировать свой код надо. Почему надо?
1. Банальное сравнение. Для того, чтобы проверить свой код без тестов — вам надо запустить проект, дощелкать до нужного места (на одном из проектов, где я работал, это занимало порядка полутора минут), после этого проверить требуемый кейс. В то время как собственно тест займет в худшем случае секунд 15 (при правильной настройке окружения)
2. Более того мало у кого хватит терпения при таком раскладе проверить все возможные ветки исполнения кода (особенно, если это касается edge-кейсов, что программа работает корректно, когда что-то идет не так)
Так что предлагаю вам начать с простого. Настройте тестовое окружение и на любую чисто логическую функциональность напишите тест. В практически любой программе есть 1-2 чисто функциональных модуля, которые берут какие-то данные и что-то с ними делают. Да, поначалу это будет казаться довольно очевидным, но это пройдет довольно быстро :-)
P.S. посмотрите репозитории по ссылкам в комментарии ниже — там можно найти довольно много вдохновения по тестам.
Есть неплохая книга «Грэхем Ли — Разработка через тестирование для iOS», там всё на примере приложения расписано.
Актуальна ли книга?
Глянул. Она еще в 2012 году была написана, в ней Xcode 4 и, вероятно, iOS 5 рассматривается.
Или это не помеха?
Глянул. Она еще в 2012 году была написана, в ней Xcode 4 и, вероятно, iOS 5 рассматривается.
Или это не помеха?
В прошлом году читал ее, довольно актуальна была. Не дочитал до конца тк рассматривались в основном простые крайне примеры и стандартная библиотека. Может быть после середины книги там и рассматривается мокирование и тп, но даже в таком случае тот же OCMock поменялся с того времени
Вполне актуальна, в тестах вроде бы с тех времён ничего особо не поменялось. Для общего понимания подходит на 100%
В этой статье вы разбирали XCTest, в основном.
Возможно, вы итак в курсе, но я бы предложил (например, читателям) поинтересоваться такой концепцией как BDD
В мире мобильной разработки она сейчас больше удовлетворяет нуждам. Под обжектив BDD фреймворком является expecta, как надстройка над specta
Под Свифт — это пара Nimble/Quick которая реализует примерно такую же функциональность.
Значительными преимуществами BDD перед TDD является включенное by-design описание тестовых сценариев, соответственно вернувшись к тестам через год, тебе по прежнему будет легко с ними работать. Кроме этого, BDD фреймворки захватывают помимо, непосредственно, юнит тестов еще и часть соседнего домена — интеграционных тестов. Соответственно связки Expecta + Cucumber хватает для практически полного покрытия приложения тестами.
Пы сы. Вот на мой взгляд очень неплохие примеры протестированного кода. Эти репозитории стоит время от времени перечитывать до просветления, так как в них можно найти решения практически всех типовых задач — тестирования контроллеров, тестирования функциональных модулей, асинхронность, тестирование нетворкинга, моки.
1. Facebook iOS SDK — тут мало юнит тестов, но много моков и интеграционных тестов
2. Eigen — этим проектом вообще стоит поинтересоваться с точки зрения организации кода и рабочего процесса, невероятно ценный репозиторий
3. РАК — просто замечательно протестированный код.
P.P.S автору рекомендую подумать над тестированием Swift-кода в качестве умственного эксперимента — тестировать код без нормального мокирования гораздо сложнее и гораздо больше способствует самодисциплине в организации кода. Моки в этом плане в Objective-C немного расхолаживают программистов
Возможно, вы итак в курсе, но я бы предложил (например, читателям) поинтересоваться такой концепцией как BDD
В мире мобильной разработки она сейчас больше удовлетворяет нуждам. Под обжектив BDD фреймворком является expecta, как надстройка над specta
Под Свифт — это пара Nimble/Quick которая реализует примерно такую же функциональность.
Значительными преимуществами BDD перед TDD является включенное by-design описание тестовых сценариев, соответственно вернувшись к тестам через год, тебе по прежнему будет легко с ними работать. Кроме этого, BDD фреймворки захватывают помимо, непосредственно, юнит тестов еще и часть соседнего домена — интеграционных тестов. Соответственно связки Expecta + Cucumber хватает для практически полного покрытия приложения тестами.
Пы сы. Вот на мой взгляд очень неплохие примеры протестированного кода. Эти репозитории стоит время от времени перечитывать до просветления, так как в них можно найти решения практически всех типовых задач — тестирования контроллеров, тестирования функциональных модулей, асинхронность, тестирование нетворкинга, моки.
1. Facebook iOS SDK — тут мало юнит тестов, но много моков и интеграционных тестов
2. Eigen — этим проектом вообще стоит поинтересоваться с точки зрения организации кода и рабочего процесса, невероятно ценный репозиторий
3. РАК — просто замечательно протестированный код.
P.P.S автору рекомендую подумать над тестированием Swift-кода в качестве умственного эксперимента — тестировать код без нормального мокирования гораздо сложнее и гораздо больше способствует самодисциплине в организации кода. Моки в этом плане в Objective-C немного расхолаживают программистов
Может у кого-то есть опыт юнит тестирования (ocmock, specta) кода в котором есть ReactiveCocoa код?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Да начнется unit-тестирование (Objective-C)