Тестирование приложений

[Fry]

Какими методиками тестирования пользуетесь?

Какими утилитами пользуетесь?

Особенно интересуют применительно к этапам разработки.

[rezak90]

Only unit-tests .

[anber]

Only unit-tests .

А как же manual testing?

[rezak90]

Only unit-tests .

А как же manual testing?

ручное тестирование никто не отменял, но после юнитов тестировать одно удовольствие.

[altwin]

функциональные тесты на этапе разработки(junit, robotium), далее в них нет смысла, так как приложение не протестируешь, только соответствие кода, стараюсь использовать TDD way, но пока лень побеждает. Далее просто подготовка smoke и прогон стандартных кейсов из него(обычно шаги состоят из задач в ТЗ + критичные части), так же смок всегда после изменений. Вот пытаюсь настроить test complete, стобы стандартные шаги смоука проходились автоматом.

P.S. я стараюсь использовать автосборку, потому автоматизация смока помогла бы серьезно. По поводу tdd - мне так легче, задача разбивается на мелкие шаги, пишется провальный тест и далее очевидно в каком порядке и что делать. Но не всегда хватает терпения и времени не пытаться "брать с наскока..".

[Fry]

altwin, круто.
А вы сколько Android-разработкой занимаетесь, если не секрет?

[rezak90]

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

[altwin]

altwin, круто.
А вы сколько Android-разработкой занимаетесь, если не секрет?

месяца 4 точно не считал , но мне скорее пришлось переключится с iOS, просто чтобы не парить себе мозг делаю все то же, что делал работая с django(тут подходы к тестированию, как и некоторые фреймворки буквально передраны с java решений, тот же selenium) ну и с java я раньше познакомился. По android действительно не много примеров использования TDD и подобных практик, но как работая с python я изучал структуры данных на примере java, так и теперь использую практики ruby/python сообществ.

P.S. не уверен, что это все правильно, но опять же я не стремлюсь к красоте кода и мне еще очень многому нужно учиться, потому в основном практичность побеждает стремление к совершенству. А тесты - для меня это требование, работаю в основном с заказчиками из США, а эти ребята без тестов код не принимают, да и качество по покрытию оценивают. Ну а вообще опыта у меня не много, учился сам, зарабатывать программирвоанием начал с php с момента получения сертификата zend engineer в 2011 до этого от IT я был ооочень далек(хотя опять же, если честно база была кое какая..т.е. Канта читал всего и просто потому, что было интересно.) . Так что я скорее пока только "шишки набиваю" Ну и как бы я отношусь к тем, для кого язык и платформа - это не цель, отсюда удобство широты знаний но иногда недостаток их глубины... вот борюсь с этим в том числе тут читая вопросы

[Mikhail_dev]

функциональные тесты на этапе разработки(junit, robotium), далее в них нет смысла, так как приложение не протестируешь, только соответствие кода,

Другими словами, если вы написали под 10 тысяч строк кода, то юнит тесты вам уже особо и не помогут, потому что вы могли делать ошибки не столько в методах, сколько в архитектуре и обработки чего-либо.
Для тестирования советую пользоваться DDMS как дополнение к юнит тестам. Но если юнит тесты не делать, то как обязательный инструмент. Как пользоваться DDMS, смотреть Вебинар 6. Аптечка хорошего разработчика. DDMS. Часть 1, а также часть два.

[Fry]

функциональные тесты на этапе разработки(junit, robotium),.

А unit-тесты разве относятся к функциональным тестам?

m090050, смотрел оба вебинара.
Осталось ощущение, что с помощью профайлинга можно выявить только "неэффективные" куски кода, которые занимают много памяти\процессора.

Или можно еще что-то выявить при помощь DDMS?

[altwin]

функциональные тесты на этапе разработки(junit, robotium), далее в них нет смысла, так как приложение не протестируешь, только соответствие кода,

Другими словами, если вы написали под 10 тысяч строк кода, то юнит тесты вам уже особо и не помогут, потому что вы могли делать ошибки не столько в методах, сколько в архитектуре и обработки чего-либо.
Для тестирования советую пользоваться DDMS как дополнение к юнит тестам. Но если юнит тесты не делать, то как обязательный инструмент. Как пользоваться DDMS, смотреть Вебинар 6. Аптечка хорошего разработчика. DDMS. Часть 1, а также часть два.

Не совсем понял, если я написал 10 тысяч строк кода - тесты, единственное, что может мне помочь. Конечно если тестируется то, что нужно. Тест проверяет соответсвие ожидаемому результату и при большом колличестве кода - тесты единственный выход. Тест это не просто assert, проверяются отработавшие методы, наличие методов в созданных объектах доступность объектов, отработка отладочного вывода и т.д. но все это делается с точки зрения ожидаемого результата. Конечно если код отрабатывает, как положенно, а ошибка всеравно есть, это уже не тестирование а отладка и DDMS - отличный инструмент, но он дополняет тесты(и не имеет к тестам никакого отношения), которые в первую очередь призванны запускаться после внесения изменений. То, что нет смысла я имел в виду то, что проходя шаги смока, тестируется функционал приложения (не код) с точки зрения пользователя, этого не возможно сделать иначе, другое дело что можно автоматизировать, но пока не получается у меня в test complete более менее сложные шаги забить.

[altwin]

функциональные тесты на этапе разработки(junit, robotium),.

А unit-тесты разве относятся к функциональным тестам?

m090050, смотрел оба вебинара.
Осталось ощущение, что с помощью профайлинга можно выявить только "неэффективные" куски кода, которые занимают много памяти\процессора.

Или можно еще что-то выявить при помощь DDMS?

Юнит тесты относятся к модульному тестированию и по сути призванны только отловить регрессию. Отдельно я их не называл, поскольку это простая и не значитальная часть, методы в основном генерируются автоматом и после правки проверяют не была ли нарушенна работа. Функциональные тесты в свою очередь дают возможность проверять точность соответсвия результата задаче. И главное, что важно в том же TDD - возможность сформировать условие. Как я и писал основная задача теста в процессе разработки для меня -это упрощение разработки и сдачи проекта(заказчику это очень нравится), имея ТЗ я строю UML того, что считаю решением, под этот "план" пишу функциональные тесты и далее после доведения "провального" результата до ожидаемого по пункту ТЗ(либо если оно не точно, то пункта плана разбивки задач(не знаю как ео назвать по другому)) я начинаю писать реализацию. Как только тест pass, пишется/генерируется unit тест. Дело в том, что функциональщина хоть и покажет что есть регрессионная ошибка, но покажет это для участка кода. Юнит тест же просто детализирует.
По поводу DDMS -вы правы это интсрумент отладки, не имеет к тестам отношения. Тем более к тестам выходящим за рамки процесса разработки, как уже было замеченно в реальной жизни не всегда есть QA и именно разработчику приходится проводить и смок и регрессию и приемочные тесты. Я сделал для себя это просто, но да - писать код долго... опять же я пока получаю задачи на детали в проектах и не веду весь проект сам(о петах реч не идет у меня не тот уровень пока), возможно чуть позже имея завершенный проект я смогу сделать выводы и внести изменения...

По поводу 10 тыс строк, добавлю.. у нас над проектом из за которого я "влюбился" в android и начал работать недавно работает 15 человек, только я тут случайно оказался и один интерн(2-е на прошлом месте работали в Amazon) у остальных опыт очень серьезный но на написание проекта отведен год. сейчас у нас порядка 200 000 строк кода в репозитории и это даже не половина функционала + у меня не ко всему проекту доступ я не знаю, что там в целом. Тесты - единственно, что позволяет мне хоть что то понимать. Я не читаю код, я открываю тесты и смотрю по шагам что там ожидается. сверяю с текущей задачей и продолжаю план, реализация -наиболее простая часть. Более того тим лид иногда очен помогает тем, что не только описывает алгоритм но и выдает тест.

[Fry]

> Я не читаю код, я открываю тесты и смотрю по шагам что там ожидается.

Вот это впечатлило
А на чем написаны эти тесты, которые вы инспектируете в этом мега-проекте?
На Robotium (который, на сколько я понимаю работает на основе ActivityInstrumentationTestCase2) ?

[altwin]

я использую их как фреймворки в своем форке проекта, к которому имею доступ. Естественно это не попадает в основной репозиторий, весь мой код перед попаданием в продакшен проходит рефакторинг, я понятия не имею что остается. Как и не имею понятия что используют другие. В подробности реализации я не вдавался, поскольку банально лень. Выбрал его, потому что он основан на том же принципе что и selenium с которым я был знаком. И он очень подходит как wrapper для black-box testing, т.е. не вдаваясь в подробности реализации. Остальное делает юнит.
По поводу общего проекта - это совсем не мега, просто очень много мелкого функционала, и очень много "дописанных" частей самого android framework(нам не очень нужно, чтобы это работало везде) я понятия не имею что там есть, никто не имеет доступа к конечному репозиторию самому интересно.

[rezak90]

долой роботиум, переходите на эспрессо, гугл почти все проекты на него перевёл

[altwin]

долой роботиум, переходите на эспрессо, гугл почти все проекты на него перевёл

дело в том, что я еще с этим не до кона разобрался и очень плаваю в android чтобы просто так брать и менять что -то. Ну и как бы я надесюь на то, что в итоге получу доступ к готовому проекту, когда будет релиз и "момент коммерческой тайны" вокруг продукта не будет так важен внутри команды. Вот и посмотрю что и как, где проблемы, тогда и буду искать best practice

[rezak90]

я сам не до конца разобрался, но планирую в этом месяце вебинар по юнит тестам где будет обзор фреймворков и их сравнение

[altwin]

я сам не до конца разобрался, но планирую в этом месяце вебинар по юнит тестам где будет обзор фреймворков и их сравнение

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

[Fry]

rezak90, о, круто! Как раз хотел на форуме оставить предложение о тестировании в качестве темы вебинара )

Просьба тогда сделать упор на самых востребованных, а не обзор из серии вообще всех фрейморков )

[altwin]

rezak90, о, круто! Как раз хотел на форуме оставить предложение о тестировании в качестве темы вебинара )

Просьба тогда сделать упор на самых востребованных, а не обзор из серии вообще всех фрейморков )

Я тут уже пару раз пытался намекнуть, что тесты как бы не маловажно и приводил книги/статьи из django/rails, где весь процесс обучения построен на TDD, да в android таких материалов пока нет, ну и мне говорят люди не захотят тестировать А в тм то и прикол, если челвоеку, который первый раз пришел показать именно такой путь, для него отсутсвие тех же тестов будет проблемой.