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

[dotcom]

Ну и речь шла про простоту эмуляции ползовательского ввода, вроде ж как поднимаемая задача?

Тут не спорю. Это просто. Сложнее потом проверить вывод.

[dotcom]

Так что тоже очень простая функциональность. Налепил скриншоты для разных компонент (опять же используя штатные функции) и дальше все это автоматизируется несколькими строчками кода.

Monkeyrunner не пользовался, но почему-то люди его больше ругают, могу уточнить почему. В iOS проекте мы в одном проекте начали Automation, но там пока только самое элементарное тестируется.

[Интеррапт]

Мне такой подход не нравится потому что на каждое изменение в УИ не относящееся к тематике теста нужно перегенерить все скриншоты.

А с custom UI (где отрисовываешь собственные компоненты) - по другому сложно что-то придумать. И не нужно все скриношты заново генерить, только те, которые планово изменились и только для отдельных компонент (а не для всех экранов, где используется эта компонента). Так что вполне нормальный подход, Гугл не зря эту функциональность добавил в андроидовский monkeyrunner.

[Интеррапт]

Так что тоже очень простая функциональность. Налепил скриншоты для разных компонент (опять же используя штатные функции) и дальше все это автоматизируется несколькими строчками кода.

Monkeyrunner не пользовался, но почему-то люди его больше ругают, могу уточнить почему. В iOS проекте мы в одном проекте начали Automation, но там пока только самое элементарное тестируется.

Monkeyrunner - это один из примеров. Для Андроид и iOS вот этот проектик набирает популярность:
http://appium.io/

К тому же там интеграция с selenium есть (WebDriver протокол поддерживается), а также с другими сторонними инструментами.
Но честно скажу, что я только-только с ним начал разбираться, так что никаких конкретных оценок от меня пока не будет.

[dotcom]

Не видел его раньше. Спасибо. Посмотрю.

[АццкоМото]

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

Я напоминаю, что юнит-тесты пишутся до кода. Откуда возьмутся скриншоты?
Вся эта возня с манкираннером и скриншотами ВООБЩЕ никакого отношения к юнит-тестированию не имеет

[АццкоМото]

Как уже неоднократно писали user interaction и работа с сетью легко эмулируется, чем больше вы покроете таких кейсов тем качественнее ваши тесты.

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

[Boriskin]

Может проще работать чуть качественне, чтобы просто не делать тривиальных ошибок?

Да-да. Кодировать так, чтобы не было багов. Звучит заманчиво, конечно...

Баги будут всегда, особенно в системах больших размеров и высокой сложности, но большую часть банальных багов действительно можно тупо "не написать".

[Ljolja]

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

Может пример какой накарябается для ликбеза студентов?

по поводу архитектуры или жизнеутверждаюшего ? Пчему-то мне кажется, что Вас больше архитектура интересует.
1. Прежде чем что-то писать, сесть и немножко подумать:
а) ultimate goal (что приложение должно делать, чего в рамках етого проекта предполагатся достичь)
б) какие шаги А,Б,Ц нужно предпринять
ц) деление на простое и сложное
д) в чем возникнут сложности
2. Оценка имеюшихся ресурсов (люди, их знания, ентузиазм и способность к обучению), имеюшиеся готовые или полу-готовые решения, кот. м-но задействовать (frameworks в класическом смысле), известные технологии кот. м-но использовать (библиотеки)
3. Как лучше всего разруливать сложности
4. делается обший spec, распределение ролей и пр.
...
смотрим на разницу м/у желаемым и действительным, производим соответствуюший adjustment

[Ljolja]

Может проще работать чуть качественне, чтобы просто не делать тривиальных ошибок?

Да-да. Кодировать так, чтобы не было багов. Звучит заманчиво, конечно...

Баги будут всегда, особенно в системах больших размеров и высокой сложности, но большую часть банальных багов действительно можно тупо "не написать".

Boriskin, посмотрите на ето чуть с другой точки зрения. К вам на проект пришел новый человек, вы его совсем не знаете, может он "индус". имхо слишком самонадеяно с самого начала предполагать, что он будет сильно напрягаться на вашем проекте, может будет просто писать, как рука легла на клавиатуру. Вам хочется потом тыкать его носом в возникшие баги (common you're a nice guy and excellent team player ), так пусть уж лучше пишет унит тесты и система ему сразу просигналит где и что надо подпилить

[Boriskin]

Boriskin, посмотрите на ето чуть с другой точки зрения. К вам на проект пришел новый человек, вы его совсем не знаете, может он "индус". имхо слишком самонадеяно с самого начала предполагать, что он будет сильно напрягаться на вашем проекте, может будет просто писать, как рука легла на клавиатуру. Вам хочется потом тыкать его носом в возникшие баги (common you're a nice guy and excellent team player ), так пусть уж лучше пишет унит тесты и система ему сразу просигналит где и что надо подпилить

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

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

[Интеррапт]

...

Наличие юнит-тестов никак не отменяет того, что нужно делать code review (и vice versa).

[Boriskin]

Консенсус?

[kis05]

а можно ли жениться на гражданке сша имея брак на территории рф?

[Stanford Wannabe]

а можно ли жениться на гражданке сша имея брак на территории рф?

Можно, но это незаконно. Если когда нибудь прознают, лишат гринки и даже гражданства.