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

[stenking]

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

Я бы не горячился по поводу "легко".

Приведите пример когда тяжело?

Ну вот например в том примере что я приводил ( а это довольно стандарт ) используется

1. http://imperavi.com/redactor/

2. http://ivaynberg.github.io/select2/ с тагами и подсказками через аджакс.

3. Добавление новых полей ( add new )

4. Флеш загрузка файлов.

Можно конечно просто сделать самбит полей но это даст вам иллюзию что форма работает.

[crypto5]

dup

[crypto5]

Приведите пример когда тяжело?

Я работал на системой Video Quality Monitoring'а. Свит для тестов у нас по сложности был примерно равен production инфраструктуре. Качество надо было мониторить на клиенте и на сервере одновременно. Свой собственный UI, логгер, бэкенд с тестовыми хуками, трафик шейпер, свой собственный VPN с симуляцией разных сетевых конфигураций, мегабайты тестовых пакетов, видео файлов разных форматов, клиентов под все платформы... Все только для тестов. Это не unit, а system/integration testing, но mocking UI и сети там был совсем непростой и, я бы сказал, мучительный.
В разработке мобильного UI тоже не все так просто. Простые формочки без навороченной навигации смокировать не так сложно. Динамические интерфейсы с анимацией, OGL компонентами... - good luck.

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

[crypto5]

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

Я бы не горячился по поводу "легко".

Приведите пример когда тяжело?

Ну вот например в том примере что я приводил ( а это довольно стандарт ) используется

1. http://imperavi.com/redactor/

2. http://ivaynberg.github.io/select2/ с тагами и подсказками через аджакс.

3. Добавление новых полей ( add new )

4. Флеш загрузка файлов.

Можно конечно просто сделать самбит полей но это даст вам иллюзию что форма работает.

Попозже посмотрю или селениум способен такое проглотить

[Интеррапт]

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

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

[Интеррапт]

А вот в правильных командах собирается статистика, изменения в каких местах потенциально ломают какую функциональность. Причем не только на уровне файлов, но и на уровне функций в них. Тулзом, автоматизированно. И если выходит новая метка, в которой 50 коммитов, ТУЛЗА аггрегирует эти данные и рекомендует, что тестировать. А тестеры еще и смотрят в описание коммитов - подробные, а не разгильдяйские и примерно прикидывают, что ЕЩЕ могло сломаться если корявые ручки кодеров меняли такую-то функциональность.
По сравнению с тупенькими юнит-тестами, это rocket science

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

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

QA смотрит что поменялось с коммита ХХХХХХХХХХХХХХ по сегодня и старается понять где это всё используется. Если видит что поменялась функция "сожрать яблоко" то делает поиск по коду что бы посмотреть где она используется. Если логика в файле то тестирует эту функциональность. Если css то смотрит как оно с изменениями. Т.е. всё ноу хау оказалось в том что бы писать нормальные имена и комментами обяснять что это делает и показать QA как пользоватся гит хабом и как там комментировать

oxrenet! I eto vsego za 20 baksov v chas?

[dotcom]

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

Это конкретный пример. Сам свит, кстати, разрабатывался изначально профессором из Berkeley, который сам пишет cтатьи по тестированию, и он в ваш Гугль ходил читать лекции тоже. Архитектурные кривости, конечно, были, не без этого. Но это отдельный разговор. Во-первых, там большой объем тестовых данных, которые надо тщательно собрать. Кстати, реальная проблема для unit и любых других тестов network'а. Во-вторых, сам environment, включающий кучу компонентов, работающих вместе. Система сложная. В-третьих, UI с тестовыми видое плеерами с кучей хуков и навороченным timing'ом. Такой видео плеер надо сесть и написать. Простого там ничего не было.
Пример с OGL еще более конкретный. Найдите мне mocked компоненты под OGL. Ага?

[Интеррапт]

[Пример с OGL еще более конкретный. Найдите мне mocked компоненты под OGL. Ага?

Для таких вещей как OpenGL не нужны mock компоненты. А вот использовать какой-нибудь Андроидовский monkeyrunner (ну или аналогичные инструменты), где заскриптовать нажатия кнопок и использовать встроенную функциональность для сравнения скриншотов - самое оно. Аналогично, если тестируется какая-то функциональность по рендерингу твоего OpenGL, то точно так же делается - запускается тест, где рендерятся компоненты в различных конфигурациях и автоматизируется процесс сравнения скриншотов для этих компонент. По крайней мере потом видно, что если при сравнении скриншотов вылетит ошибка, то что-то в рендеринге изменилось.
Ес-но никто не пытается довести тестирование до абсурда и ес-ли юнит тесты очень сложно имплементировать для какого-то компонента - то скорее всего это и не нужно делать. Но вот покрыть по максимуму все остальное - очень даже полезно.

[Интеррапт]

QA смотрит что поменялось с коммита ХХХХХХХХХХХХХХ по сегодня и старается понять где это всё используется. Если видит что поменялась функция "сожрать яблоко" то делает поиск по коду что бы посмотреть где она используется. Если логика в файле то тестирует эту функциональность. Если css то смотрит как оно с изменениями. Т.е. всё ноу хау оказалось в том что бы писать нормальные имена и комментами обяснять что это делает и показать QA как пользоватся гит хабом и как там комментировать

oxrenet! I eto vsego za 20 baksov v chas?

Меня удивило другое, что таким толковым QA нужно обьяснять и показывать, как пользоваться github

[dotcom]

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

Направление понятно. Вопрос был про простоту.

[Интеррапт]

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

Направление там понятно. Вопрос был про простоту.

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

[crypto5]

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

Направление там понятно. Вопрос был про простоту.

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

[Интеррапт]

Если заменить сравнение скриншотов на чекание каких то состояний программы и вызов моков API OGL то возможно простота присутствует?

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

[crypto5]

Если заменить сравнение скриншотов на чекание каких то состояний программы и вызов моков API OGL то возможно простота присутствует?

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

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

[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 ), так пусть уж лучше пишет унит тесты и система ему сразу просигналит где и что надо подпилить