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

[АццкоМото]

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

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% ИМХО.