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

[Мальчик-Одуванчик]

обобщение: юнит-тестирование в мобилдеве нужно гораздо реже, чем многим кажется

Они чаще всего вообще не нужны в метапрограммировании.

[crypto5]

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

скопипастил пару функций с рабочего проекта
первая:

Code: Select all

public void recreateAllViews (LayoutInflater inflater) {
        if (mPanels != null) {
            for (Panel panel : mPanels) {
                View v = panel.getView(inflater);
                mRootView.addView(v);
                panel.update();
            }
        }
    }

вторая:

Code: Select all

public static void actionResetPassword (Activity fromActivity, String user, String oldPass, String newPass, int questionCode, String answer) {
		Intent i = new Intent (fromActivity, LoggingInActivity.class);
		
		i.putExtra(EXTRA_USER,      user);
		i.putExtra(EXTRA_PASS,      oldPass);
		i.putExtra(EXTRA_NEW_PASS,  newPass);
		i.putExtra(EXTRA_CODE,      questionCode);
		i.putExtra(EXTRA_ANSWER,    answer);
		i.putExtra(EXTRA_MODE,      MODE_RESET);
		
		fromActivity.startActivity(i);
	}

вопрос: как такие функции юнит-тестировать?
ответ: никак
обобщение: юнит-тестирование в мобилдеве нужно гораздо реже, чем многим кажется

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

[Интеррапт]

Первый кейс наверное проще покрыть каким то функциональным УИ тестом, который будет проверять нажатия на кнопки и что бы правильные надписи появлялись, а во втором - засовываете 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

[dotcom]

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

[Medium-rare]

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

[Интеррапт]

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?

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