Программист. с чего начать?

[Интеррапт]

Unit Testing на UI'ные компоненты натягивать ИМО - пустая трата времени. Они слишком динамичны и проблемы нужно отлавливать функциональным тестингом.

Ес-но многие UI вещи просто покрываются функциональным тестом. Например, для monkeyrunner заскриптовать последовательность действий и автоматически сравнивать полученные скриншоты на совпадение.

[dotcom]

Одна крупная корпорация юнит-тестит и далее автоматизирует абсолютно всё, хоть UI, whatever. Копаешься в этих mock'ах, копаешься...

На то она и корпорация, что там много людей. Оно makes more sense, хотя бы потому что людей много и без расстановки мин в виде unit test'ов какой-нибудь дятел обязательно что-нибудь сломает. Мы тоже в большой очень доброй корпорации assert'или любой чих.
У меня смешанный опыт от минирования проектов. В одном из моих предыдущих проектов мы все дружно решили идти по пути UTDD, и группа товарищей (включая меня) получили лейбл unit test nazi. Пока команда была небольшая, и все понимали, что и как делать, оно работало. А потом команда разрослась, пришли дятлы, и люди стали тратить больше времени на тесты, чем на разработку. Термин "рефакторинг" получил новое значение - хакнуть код так, чтобы тесты не упали. В авральное время разработчики стали игнорировать падучные тесты и.т.п. Ну как обычно. Все кончилось тем, что наш главный архитектор был уволен за срывы всех сроков и плохое качество продукта.
ИМО все же нужен разумный баланс и строгая дисциплина. Иначе unit testing может привести в ад.

[Интеррапт]

ИМО все же нужен разумный баланс и строгая дисциплина. Иначе unit testing может привести в ад.

Просто плохой код приведет туда же и еще быстрее.

[dotcom]

ИМО все же нужен разумный баланс и строгая дисциплина. Иначе unit testing может привести в ад.

Просто плохой код приведет туда же и еще быстрее.

Естественно, оно симмитрично.

[АццкоМото]

Первый кейс наверное проще покрыть каким то функциональным УИ тестом, который будет проверять нажатия на кнопки и что бы правильные надписи появлялись

Согласен и несогласен одновременно. В общем случае мы не знаем, какие вью будут отрисованы. И какие кнопки у них будут
Но общий подход таки да - какой угодно типа тестов, только не юнит

а во втором - засовываете mock fromActivity в метод и потом ставите проверку что метод startActivity вызвался с нужным параметром.

А тут (почти) совсем мимо. startActivity() - метод Ондроедного фреймоворка. В данном конкретном примере я могу чисса тиаритически проверить, что активность стартовала и вызвался уже мой метод onCreate(). Смысла, правда, в такой проверке чуть меньше, чем нифига. Но в общем случае я могу стартовать неопределенную активность - типа как отправить письмо. А ее будет обслуживать "какое-то" приложение, во-первых, мне неизвестное, а во-вторых выбор его может быть определен пользователем. Что тут тестировать?
Но самое главное. Глядя на метод абсолютно понятно, что он делает то, что делает. Как и понятно, что сломать его может только конченный упырь, которого после трех таких сломов нужно забить осиновым колом и пристрелить серебряной пулей

Другое дело что на мой вкус тут мало логики что бы оправдать написание теста, но многие люди со мной не согласны.

я, как раз, скорее согласен. только мое определение мктодов, уместных для юнит-тестирования вообще радикально: юнит-тестировать нужно то, что инвариантно относительно среды, которая включает в себя действия пользователя, что-то, что тянется из энторнэта/сети, из дазы банных и так далее. Т.е. на вход подали Х, получили У. В лучшем случае - с небольшими вариациями

[АццкоМото]

Unit Testing на UI'ные компоненты натягивать ИМО - пустая трата времени. Они слишком динамичны и проблемы нужно отлавливать функциональным тестингом. Mock views делать только ради фунционального или юнит тестинга - это большие затраты времени. А вот на всякие API и логику базы - там unit testing очень даже эффективен. Есть, конечно, всякие специфичные кейсы, когда надо сделать, скажем, load testing и без UI'я не обойтись.

чем меня поражает дотком, так это тем, что раз в полгода согласен с каждым словом

[crypto5]

А тут (почти) совсем мимо. startActivity() - метод Ондроедного фреймоворка. В данном конкретном примере я могу чисса тиаритически проверить, что активность стартовала и вызвался уже мой метод onCreate().

Я не понял мысли, что конкретно мешает послать в метод mock fromActivity? Можно по слогам?

[АццкоМото]

Первый кейс наверное проще покрыть каким то функциональным УИ тестом, который будет проверять нажатия на кнопки и что бы правильные надписи появлялись, а во втором - засовываете mock fromActivity в метод и потом ставите проверку что метод startActivity вызвался с нужным параметром. Другое дело что на мой вкус тут мало логики что бы оправдать написание теста, но многие люди со мной не согласны.

И самое главное, что это все в Андроиде уже есть, включая mock компоненты:
http://developer.android.com/reference/ ... mmary.html
http://developer.android.com/reference/ ... mmary.html

Ну а начинать нужно отсюда:
http://developer.android.com/tools/test ... _test.html
Затем можно посмотреть в Android SDK, та поставляются в examples два приложения - Spinner и SpinnerTest. Неплохая отправная точка.

Это не считая того, что есть и другие неплохие инструменты:
https://code.google.com/p/robotium/

Старик, ну ты бы еще посоветовал гуглить в гугле. На этом всем уже мох давно растет, стыдно даже и ссылки давать.

Абсолютно неверный ответ

Это веско. А если я скажу "абсолютно верный ответ", мы впадем в состояние квантовой запутанности?

Совершенно неверное обощение - т.к. юнит-тестинг и функциональный тестинг в мобилдеве нужен намного чаще, чем многим кажется.
А уж функциональный тест вообще святое дело, в Андроиде и неплохие инструменты есть для этого:
http://developer.android.com/tools/help ... cepts.html

Функциональный тестинг я не опускал. А вот Юнит - я считаю вреден почти всегда

[АццкоМото]

А тут (почти) совсем мимо. startActivity() - метод Ондроедного фреймоворка. В данном конкретном примере я могу чисса тиаритически проверить, что активность стартовала и вызвался уже мой метод onCreate().

Я не понял мысли, что конкретно мешает послать в метод mock fromActivity? Можно по слогам?

Например, тем, что метод mock fromActivity() стопудово вызовется - ну это видно же. Если написано x.y() то стопудово вызовется метод y() у объекта x
А вот реальная активность не будет запущена, если, например, в Манифесте забыли ее задекларировать. И будет позорный крэш при стопроцентно проходящих юнит-тестах. Где PROFIT?

[crypto5]

А тут (почти) совсем мимо. startActivity() - метод Ондроедного фреймоворка. В данном конкретном примере я могу чисса тиаритически проверить, что активность стартовала и вызвался уже мой метод onCreate().

Я не понял мысли, что конкретно мешает послать в метод mock fromActivity? Можно по слогам?

Например, тем, что метод mock fromActivity() стопудово вызовется - ну это видно же. Если написано x.y() то стопудово вызовется метод y() у объекта x
А вот реальная активность не будет запущена, если, например, в Манифесте забыли ее задекларировать. И будет позорный крэш при стопроцентно проходящих юнит-тестах. Где PROFIT?

Юнит тест - это локализированный тест, он тестирует только ваш метод, предполагая что с наружи все работает правильно. Ваш кейс нужно тестить или функциональными тестами, или юнит тестами других классов/методов.

[АццкоМото]

Юнит тест - это локализированный тест, он тестирует только ваш метод, предполагая что с наружи все работает правильно. Ваш кейс нужно тестить или функциональными тестами, или юнит тестами других классов/методов.

Das ist почти what i'm talking about
Как я уже писал, unit test - хорошо, когда на конкретный набор входных данных мы точно знаем набор выходных данных. Отсортировать массив. Найти кратчайший путь в графе. Решить систему уравнений.
Как только встревает потенциально безобразно большой набор внешних данных - ну его нафиг

[Интеррапт]

Например, тем, что метод mock fromActivity() стопудово вызовется - ну это видно же. Если написано x.y() то стопудово вызовется метод y() у объекта x
А вот реальная активность не будет запущена, если, например, в Манифесте забыли ее задекларировать. И будет позорный крэш при стопроцентно проходящих юнит-тестах. Где PROFIT?

Да не будет там никаких 100% проходящих юнит тестов. Если эта активити участвует в юнит тесте - то ты получишь ошибку и юнит тест не пройдется.

Для получения Activity ты вызываешь ActivityInstrumentationTestCase2.getActivity() в твоем оверрайднутом методе setUp() тестового класса.

И именно в этот момент unit test выдаст красивую ошибочку о том, что мол не может резолвнуть это активити. А когда собственная активити не может быть резолвнута, значит нужно первым же делом идти в манифест и проверять наличие этой активти.
Неудачный пример ты выбрал для доказания бесполезности юнит теста

[АццкоМото]

Например, тем, что метод mock fromActivity() стопудово вызовется - ну это видно же. Если написано x.y() то стопудово вызовется метод y() у объекта x
А вот реальная активность не будет запущена, если, например, в Манифесте забыли ее задекларировать. И будет позорный крэш при стопроцентно проходящих юнит-тестах. Где PROFIT?

Да не будет там никаких 100% проходящих юнит тестов. Если это активити участвует в юнит тесте - то ты получишь ошибку и юнит тест не пройдется.

Для получения Activity ты вызываешь ActivityInstrumentationTestCase2.getActivity() в твоем оверрайднутом методе setUp() тестового класса.

И именно в этот момент unit test выдаст красивую ошибочку о том, что мол не может резолвнуть это активити.

Чего вдруг? Я должен в тестируемый метод уже передать активность - субкласс android.os.Activity
И тут два варианта - либо я передаю реальную активность, которой я ничего протестировать не могу, либо специально заготовленную mock активность, которая при своем старте ищет реальную активность и обрабатывавает соответственные беды как ты пишешешь. И в этом моменте возникает 100500 нюансов, о которых нужно думать. А метод, что я привел, был написан примерно за 17 секунд и НИ РАЗУ после этого не правился. А вызывать метод класса с двойкой в конце названия - вообще западло. Нужно дождаться появления ActivityInstrumentationTestCase238 с аннотацией @deprecated - тогда можно

[АццкоМото]

ЗЫ. Нажал на сабмит и понял, что несколько коряво выразился. Либо будет и так понятно, либо придется разъяснять

[АццкоМото]

Вот еще наброс - а на юнит тесты надо писать юнит тесты, чтобы убедиться, что юнит тесты работают правильно? Чтобы быть последовательным, надо бы. И юнит тесты на юнит тесты на юнит тесты - тоже. ну ты понел

[Сабина]

Вот еще наброс - а на юнит тесты надо писать юнит тесты, чтобы убедиться, что юнит тесты работают правильно?

Только в доме который построил Джек

[АццкоМото]

Вот еще наброс - а на юнит тесты надо писать юнит тесты, чтобы убедиться, что юнит тесты работают правильно?

Только в доме который построил Джек

тем не менее, в каждой шутке есть доля правды

[Интеррапт]

Я при code review вообще код не пропускаю, если он не покрыт юнит тестами.

зверский генерал!

А что поделаешь - люди приходят и уходят, а мне разбираться и поддерживать все эти мобильные проекты. Вот я и очень дорожу своим временем и делаю все возможное, чтобы за счет времени других девелоперов сэкономить свое время. А юнит тесты неплохо помогают обнаружить, если где-то чего-то поломалось. Тут пусть хоть Аццко 100 раз рассказывает, что это не так, а я буду в данном вопросе к собственному опыту прислушиваться. Мало того, я уже некоторое время как перешел на test-driven development, когда вначале пишутся тесты для модуля/класса и т.п., а потом имплементируется функциональность. Ведь фактически таким образом ты сначала делаешь спецификацию, декларируя, что ожидается от того или иного метода, а потом эту функциональность уже имплементируешь. Занимает дольше времени? Да. Зато потом намного больше времени экономится за счет того, что меньше багов и меньше всяких глупых поломок, которые приходится долго и нудно искать.
Есть куча хорошей литературы по test-driven development, кто с этим подходом не сталкивался - советую ознакомиться.

[Komissar]

TDD на словах хорошее дело, но я насмотрелся на прохиндеев, к-рые сделали из этого ругательное слово наподобие agile. Типа, сначала долго-долго пишут тесты. Потом неспеша пишут функциональность. Потом прибежал потный маркетинщик и орет "тут и тут поменять, вчера!". Меняют тут и там в коде, но в спешке про тесты все забыли. Теперь валится билд, все бросаются разбираться что к чему... Иногда подумаешь, да ну его нафиг. TDD на самом деле хорошо мэтчит Waterfall, но не Agile.

[Интеррапт]

Типа, сначала долго-долго пишут тесты. Потом неспеша пишут функциональность.

Просто неправильно используют методологию. Не нужно "долго-долго" писать тест. Код разбивается на модули, к которым пишутся тесты и тут же эти модули имплементируются.

Потом прибежал потный маркетинщик и орет "тут и тут поменять, вчера!". Меняют тут и там в коде, но в спешке про тесты все забыли.

Это уже организационные проблемы.

Теперь валится билд, все бросаются разбираться что к чему... Иногда подумаешь, да ну его нафиг. TDD на самом деле хорошо мэтчит Waterfall, но не Agile.

TDD как раз отлично подходит для agile. Да и собственно в любом мало-мальски сложном проекте unit тесты необходимы. И вот если эти юнит тесты писать пост-фактум, вроде как есть уже написанный проект и к нему начинают привинчивать юнит тесты - то можно много чего упустить.

[Komissar]

книжки по TDD обычно иллюстрируют применение на основе закрытого, self-sufficient приложения типа Калькулятор. А когда пишется сложное приложение с интеграцией с другими дата-сорцами и прочей фигней, то часто максимум, что в реальное время можно охватить в юнит-тестах - некие граничные условия.

[Интеррапт]

книжки по TDD обычно иллюстрируют применение на основе закрытого, self-sufficient приложения типа Калькулятор.

А другие методологии сразу что-ли иллюстрируют применение того или иного метода печатая в книге код ядра Linux? Книгам и нужно иллюстрировать применения на простых и понятных примерах.
На самом деле ты утрируешь насчет калькулятора. Иллюстрируют и с использованием UI, сетей и т.п.

А когда пишется сложное приложение с интеграцией с другими дата-сорцами и прочей фигней, то часто максимум, что в реальное время можно охватить в юнит-тестах - некие граничные условия.

Ты уже сюда начинаешь добавлять integration tests, не о них речь идет.

[Komissar]

спорить о достоинствах TDD и Agile - это как спорить о религии. "Если бы ее не было, ее все равно бы изобрели". Потому с поклонами ухожу с ринга.

[Интеррапт]

спорить о достоинствах TDD и Agile - это как спорить о религии. "Если бы ее не было, ее все равно бы изобрели". Потому с поклонами ухожу с ринга.

А при чем здесь религия? У разных людей разные подходы к написанию кода. И к написанию с использованием TDD я пришел далеко не сразу, а только в последние несколько лет.

[Komissar]

есть код (и его много), к-рый по определению не вписывается в ТДД - все 100% ИМХО.