Комментарии 10
интересно посмотреть было бы на реализованные таким образом системы.
конечно же, основной скепсис появляется при мысле о поддержке такого количества тестов.
конечно же, основной скепсис появляется при мысле о поддержке такого количества тестов.
Не ручаюсь, что в sqlite применяют TDD, но это излюбленный всеми пример проекта, полностью покрытого тестами. У них даже статья про это есть https://www.sqlite.org/testing.html
я конечно извиняюсь, но почему именно TDD на iOS? Описанные практики почти никак не касаются собственно iOS и могли бы быть спокойно написаны на псевдокоде.
Я бы ещё заменил слово «if» на слово «ветвление», потому что некоторые функциональные языки спокойно обходятся без них.
Я бы ещё заменил слово «if» на слово «ветвление», потому что некоторые функциональные языки спокойно обходятся без них.
Идея TDD на iOS вызывает отрицательные эмоции.
Понимаете, TDD обрекает программиста на гипер велосипедность. Зачем вообще писать код? Все компоненты уже готовы и лежат на github, от малых библиотек до великих проектов, которые нужно брать и менять под собственные бизнес задачи. А наличие third-parties кода ставит под сомнение объективность тестирования, никто не знает где выстрелит скачанный код.
А отсутствие third-parties кода ставит под сомнение адекватность поставленной задачи :-)
Понимаете, TDD обрекает программиста на гипер велосипедность. Зачем вообще писать код? Все компоненты уже готовы и лежат на github, от малых библиотек до великих проектов, которые нужно брать и менять под собственные бизнес задачи. А наличие third-parties кода ставит под сомнение объективность тестирования, никто не знает где выстрелит скачанный код.
А отсутствие third-parties кода ставит под сомнение адекватность поставленной задачи :-)
Полагаю, одно из самых важных при TDD — это обеспечение уверенности в том, что код работает так, как он должен работать. Выполнять ту задачу, которую на него возлагают.
И если вдруг очередной прогон теста покажет, например, что валидатор Email работает некорректно или не поддерживает ряд правил, то это повод заменить 3party валидатор или сделать форк.
Ибо неважно, свой код дал сбой или чужой.
Главное — обеспечить выполнение логики программы… во всяком случае, так думаю я.
И если вдруг очередной прогон теста покажет, например, что валидатор Email работает некорректно или не поддерживает ряд правил, то это повод заменить 3party валидатор или сделать форк.
Ибо неважно, свой код дал сбой или чужой.
Главное — обеспечить выполнение логики программы… во всяком случае, так думаю я.
Тестировать чужие библиотеки — не желательно, они сами должны быть по-хорошему покрыты тестами. Обычный сценарий — мокируем все 3party и тестируем наш код в изоляции.
Но в некоторых случаях, когда какой-то наш модуль сильно завязан на 3party, то вполне можно протестировать корректность его поведения как black box, вместе со сторонней библиотекой.
Но в некоторых случаях, когда какой-то наш модуль сильно завязан на 3party, то вполне можно протестировать корректность его поведения как black box, вместе со сторонней библиотекой.
Не факт, что готовые либы будут идеально решать наши задачи, скорее всего мы будем тем или иным образом их использовать, конечный результат их использования мы и должны тестировать. Сторонний код выстрелил — написал тест, решил проблему, больше это не повторится.
Покрытие кода сервисного и core слоя отлично помогает моментально находить неочевидные проблемы при изменении реализации класса.
Покрытие кода сервисного и core слоя отлично помогает моментально находить неочевидные проблемы при изменении реализации класса.
НЛО прилетело и опубликовало эту надпись здесь
Здравствуйте. Спасибо за хорошую статью.
Учитывая приведенные Недостатки (а именно «Больше времени» и «Поддержка тестов»), как Вы считаете, хорошим ли компромиссом будет использовать TDD подход только по отношению «критически важным» классам?
Критичность в таком случае, естественно, оценивается самими программистом/командой уже в зависимости от конкретного проекта.
Учитывая приведенные Недостатки (а именно «Больше времени» и «Поддержка тестов»), как Вы считаете, хорошим ли компромиссом будет использовать TDD подход только по отношению «критически важным» классам?
Критичность в таком случае, естественно, оценивается самими программистом/командой уже в зависимости от конкретного проекта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка через тестирование в iOS