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

[Сабина]

у тестеров, еще чаще чем у девов, бывает дурное начальство, в спокойное время между релизами их заваливают дурацкими отчетами и метриками. Ну и честно скажем, иная фича тридцать раз еще изменится за все итерации а то и будет вообще de-scoped, так что учи/не учи ее заранее, толку не будет.

Ну тут извините у меня своя своя правда . Бестолковго тестера от толкового с полпинка отличу и первых увы большинство. Зато когда попадается второй, то ему никакая указивка от начальства - не проблема. Если баг то не пройдет, как фашисткий танк - и точка

[Интеррапт]

Это безотносительно факта что компетентные тестеры умеют JUnit тесты писать, а значит только появилось что-то - вперед и fail.

О нет, только не это. Если QA пишет unit tests для девелоперского кода, то что-то очень неправильно в датском королевстве. Такого вообще быть не должно. Если продвинутые QA пишут integration tests - это еще понятно, но unit tests должны только разработчики писать (при чем я вообще сторонник подхода - unit test first, т.е. сначала тест, потом код, который удовлетворяет условию юнит теста). По крайней мере ни разу еще такого не встречал, чтобы QA писали unit tests для кода.

[Сабина]

Это безотносительно факта что компетентные тестеры умеют JUnit тесты писать, а значит только появилось что-то - вперед и fail.

О нет, только не это. Если QA пишет unit tests для девелоперского кода, то что-то очень неправильно в датском королевстве. Такого вообще быть не должно. Если продвинутые QA пишут integration tests - это еще понятно, но unit tests должны только разработчики писать (при чем я вообще сторонник подхода - unit test first, т.е. сначала тест, потом код, который удовлетворяет условию юнит теста). По крайней мере ни разу еще такого не встречал, чтобы QA писали unit tests для кода.

Я тоже не сторонник чтобы они их писали, но это сейчас не диковинка совсем. многие и на работу не берут если человек не знает JUnit.
Меня больше волнует обилие QA которые как слепые котята спрашивают у девелопера чего тестировать и просто механически выполняют шаги без понимания дела. Портнову конечно виднее у кого отвественности больше , но в чем же еще заключается отвественность Qa как не в нахождении незамеченного девелопером бага ?

Скажу больше ... У меня на одной из прошлых работ девушка была QA из наших. Она не CS graduate, но баги чувствовала нутром. С виду по ней совсем не скажешь - Барби такая с виду, но в своем деле она была просто ассом. Пофиг ей что там девелопер сказал и как. Он тестировала в основном исходя из бизнес requirements и благодаря ее дотошности и скрупулезному подходу качество было на уровне.

[Komissar]

Девелоперы баги не ищут. Они их пишут.

[Интеррапт]

Я тоже не сторонник чтобы они их писали, но это сейчас не диковинка совсем. многие и на работу не берут если человек не знает JUnit.

Но ты точно с integration tests не путаешь? Все-таки unit tests должны девелоперы писать, это как бы почти аксиома.

[Сабина]

Я тоже не сторонник чтобы они их писали, но это сейчас не диковинка совсем. многие и на работу не берут если человек не знает JUnit.

Но ты точно с integration tests не путаешь? Все-таки unit tests должны девелоперы писать, это как бы почти аксиома.

Ну глянь сам requirements на QA в боль-мень приличной конторе - JUnit is a must

[Komissar]

речь, как я понимаю, об интеграционных тестах, написанных в технологии JUnit.

[Интеррапт]

Девелоперы баги не ищут. Они их пишут.

На самом деле очень многие бы удивились, насколько уменьшается кол-во багов (особенно для продукта с активным циклом девелопинга), когда всю функциональность покрываешь юнит тестами. Mobile dev не исключение. Для того-же iOS настоятельно рекомендую вот эту книгу:
http://www.amazon.com/Test-Driven-iOS-D ... evelopment
Где очень доходчиво обьясняется, каким образом девелопинг нужно строить так, чтобы сначала писать юнит тесты, а потом уже собственно функциональность. Ну и соответственно хорошо описываются инструменты.

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

[Сабина]

На самом деле очень многие бы удивились, насколько уменьшается кол-во багов (особенно для продукта с активным циклом девелопинга), когда всю функциональность покрываешь юнит тестами. .

+100

[Komissar]

У меня на одной из прошлых работ девушка была QA из наших. Она не CS graduate, но баги чувствовала нутром. С виду по ней совсем не скажешь - Барби такая с виду, но в своем деле она была просто ассом.

"Наши" Ж часто косят под Барби, иногда, правда, слегка вульгарно получается.

Но главное я надеюсь, она была-таки асом а не ассом.

[Сабина]

речь, как я понимаю, об интеграционных тестах, написанных в технологии JUnit.

Какая разница каких именно если человек знает JUnit в принципе ?

[Сабина]

У меня на одной из прошлых работ девушка была QA из наших. Она не CS graduate, но баги чувствовала нутром. С виду по ней совсем не скажешь - Барби такая с виду, но в своем деле она была просто ассом.

"Наши" Ж часто косят под Барби, иногда, правда, слегка вульгарно получается.

Но главное я надеюсь, она была-таки асом а не ассом.

И тем и другим

Но лучше ее не было за все 10 лет . Вот такой парадокс.

[Интеррапт]

На самом деле очень многие бы удивились, насколько уменьшается кол-во багов (особенно для продукта с активным циклом девелопинга), когда всю функциональность покрываешь юнит тестами. .

+100

Так у меня это основной reject, при code review. Пишу комментарии к строчкам кода в добавленной функции на уровне "нужен unit test", "нужен unit test". Многих раздражает, но кому сейчас легко

[Сабина]

Так у меня это основной reject, при code review. Пишу комментарии к строчкам кода в добавленной функции на уровне "нужен unit test", "нужен unit test". Многих раздражает, но кому сейчас легко

Тю, разьве это садизм в высшей мере проявления ?
Наш главный любил выдать "не открывайте тред в Teiid форуме пока тест кейс не напишите". А речь про memory problem, которая после 2 часов under 8 users load проявляется. Вот это я понимаю

[Komissar]

Видите? А поставить такого начальником над тестерами? Всю душу вынет.

К вопросу о мало-ответственной работе тестера.

[Сабина]

Видите? А поставить такого начальником над тестерами? Всю душу вынет.
К вопросу о мало-ответственной работе тестера.

А на них и не надеялся никто особо, что в общем-то sad

[vopros]

по н1 проще прогом чем тестером

[Aleksey_Danilov]

А что за виза такая коварная "HB1"?
Никогда о такой не слышал... Знаю только стандартные рабочие... H-1B, H-2A, H-2B и т.п.

Очень странно ТС подходит к выбору профессии, пытается её подобрать для визы в США
Смешно!
Чтобы тебя взяли в США работать прогером по H-1B, нужно знать язык англ, нужно уметь делать восьмерку в воздухе, сальто, при этом жонглировать шарами и шевелить ушами! Ты это умеешь? Если нет - тебе не светит виза.

Меня удивляют люди, которые вместо того чтобы почитать официальную инфу на офф сайтах - лезут на форумы, чтобы дяденьки и тетеньки за них все разрулили... За вас никто и ничего не будет делать! Идите и выполняйте Д\З. А после поговорим!

[АццкоМото]

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);
	}

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

[Kolbasoff]

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

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

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

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

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

[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'ах, копаешься...