пятница, 6 марта 2009 г.

Тестирование на Opensource

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

  1. API инструмента не всегда удобен
  2. Не все заявленные функции поддерживаются в полной мере
  3. Наличие багов в самом инструменте
  4. Отсутствие поддержки современных технологий

Теперь подробнее порассуждаем на счет этого на примерах некоторых опенсорс (opensource) инструментов.

API инструмента не всегда удобен

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

Возьмем к примеру язык программирования Java. В нем есть выработанные "Code Conventions for the Java Programming Language", так почему те кто пишет инструменты на Java не используют их? Сложно прочитать или там много непонятных букв?

Вот вам пример:

Java Naming ConventionsWatij
Methods: should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Examlple: getForms(), setForm(...) and so on. Class IE - Metods: form(...), forms(), frame(...), frames(), label(..), labels()

Не правда ли это прямое нарушение Java Naming Conventions? Смириться конечно можно... Но это нервы и время...

Не все заявленные функции поддерживаются в полной мере

Берем API инструмента, читаем, что есть в наличии методы обеспечивающие выполнение необходимых нам операций. Отлично! А что на самом деле?

Пример Watij:

public void checkForHttpError(WatijBrowser watijBrowser) throws NotImplementedYetException //!?
{
throw new NotImplementedYetException();
}

или
public Dimension clientAreaSizeRequested(Dimension dimension) {
return null; //To change body of implemented methods use File...
}

или
public boolean navigationErrorOccured(WebBrowser webBrowser, String string, String string1, StatusCode statusCode) {
return false; //To change body of implemented methods use File...
}

или
public void downloadBegin() {
//To change body of implemented methods use File...
}

Мы видим кучку незаконченных методов, хотя в API они заявлены. Я понимаю, что это делается до того, что если тебе надоест эта недоделка, ты сам заимплементируешь ее и зальешь создателем инструмента (конечно если у самого на это есть подходящая квалификация).

Но будете ли вы этим заниматься, когда ваша работа писать автотесты и тестировать, а не фиксить баги в инструментах?

Наличие багов в самом инструменте

Эта проблема сродни предыдущей, когда функция заявлена а ее на самом деле нет. Ждать фикса проблемы можно вечно. На моей памяти есть пример:
нашел багу в httpunit с работой с сookies. Написал им багу, ждал ответа, так не получил. В итоге сделал свою заплатку и забыл. Через года 2-3 получаю письмо, в котором они просят больше информации по существу бага. Причем говорят, что бага не критическая и скорее всего как было так они и оставят, чтобы не сломать ничего.

Как вам это? Сможете вы ждать 2-3 года пока создатели инструмента пофиксят проблему?

Отсутствие поддержки современных технологий

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

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

"Думайте сами, решайте сами, иметь или не иметь"


14 комментариев:

Алексей Лупан комментирует...

Я не за и не против опенсоурса - использую и в быту, и в работе софт из обеих областей.

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

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

Поэтому там были и всегда-всегда будут NotImplementedYetException() :)

Решение "будем переходить на опен-сjehc, ибо оно бесплатно" - прерогатива незнающих, или тех, кому знания уже не помогут.

Что послужило источником для написания заметки? Автора кто-то заставляет использовать в работе только опен-соурс, а ответить мудаку в лицо не получается по копроративным обстоятельствам?

Alexey Bulat комментирует...

Начну с конца :)
1. Никто мне ничего не навязывал, просто стало интересно решить кое какие реально рабочие задачи с помощью опенсорс инструментов. В итоге остановился на htmlunit. В нем конечно есть и свои минусы, но по моему он "зэ бэст". Конечно не работает он в реальном браузере, ну не любит он майкросовтовские веб апликухи, но под него приятнее писать. По крайней мере мне :)
2. Статья написана под впечатлением от исследований некоторых опенсорс инструментов, т.к. моему руководству не важно чем автоматизируется приложение (компания большая, есть лицензии на инструменты от IBM, HP, т.е. я свободен в выборе инструмента).

3. На счет того, что я когда-то не выложил свой патч, то скажу, что во-первых это не моя работа писать опенсорс приложения, а во-вторых - проект httpunit тогда был дохленький... :) Конечно это звучит эгоистично, но сорри, если авторы взялись что-то сделать для всех и бесплатно, нечего бросать работу на пол пути и без присмотра.
Если мы покупаем тул, то мы в нагрузку получаем еще и саппорт. Что не всегда есть в бесплатных инструментах. В них саппорт - это желание автора или кого-то со стороны, желающему помочь решению вашей проблемы.

Вот. Спасибо, что читаете нас :)

Алексей Баранцев комментирует...

С моей точки зрения коммерческие инструменты не в меньшей степени страдают от перечисленных четырёх проблем, чем открытые. И даже пофиксить невозможно, в отличие от опенсорса...

Alexey Bulat комментирует...

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

Алексей Баранцев комментирует...

У меня от использования некоторых коммерческих инструментов ТАКОЙ аффект -- ни одному опенсорсу не приснится. Я, например, в полнейшем шоке от того, что в QTP в режиме DesignView не работает undo -- удалил что-нибудь и привет. Как такое можно допустить, а?

Alexey Bulat комментирует...

от QTP у меня шок уже давно... По всей видимости зажрались они...
Знали бы вы, как я был доволен WinRunner-ом и как был расстроен, что его выкинули на свалку.

По поводу опенсорса, он всем хорош (кроме того, что я ниписал в основном посте), пока есть те кто его сапортят и не ленятся помогать фиксить баги. Дальше это превращается в грабли, которые нужно дотачивать самим. И проблема тут получается та же, что и с платными тулзами без саппорта.

Вот.

rkononov@gmail.com комментирует...

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

alex.ikhelis комментирует...

Алексей, привет. Спасибо за статью. Согласен с предыдущими ораторами, особенно с резюмирующим комментом от "rkononov@gmail.com". Поэтому на тему "за" и "против" писать не буду :)

Хочу сделать только два комментария:
1) К счастью есть более менее удачные и развивающиеся open-source средства, где документация, поддержка, постоянное совершенствование и комьюнити пользователей - достаточные для эффективного использования. Но в любом случае требования к квалификации пользователей высокие. это понятно :).

Например, родоначальник идеи - Watir развивается лучше, чем его "соседи". Я так понимаю, ты специализируешься в java. Смотрел в сторону Selenium?

2) Предполагаю, что в основе API Watij просто лежит немного другая парадигма. Наследованная от Watir, где coding conventions другие (не причина, согласен), в ruby сознательно размывается грань между методом/полем/обьектом, все есть объект. Так вот эта парадигма смотрит на написание автотестов с точки зрения автотестера. Элемент на странице ищется в иерархии DOM: ie.form(how,what).checkbox(how,what). Где пользователю проще считать что form() это объект, а не метод getForm(). Например, в том же QTP такой же подход. Дело привычки. Поэтому еще раз рекомендую взглянуть на Selenium :)

Alexey Bulat комментирует...

Спасибо, Alex на селениум смотрел, не могу насмотреться... :) Вы очень хорошо объяснили про Watij спасибо, теперь у меня многое прояснилось...

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

Alexey Bulat комментирует...

И еще, Селениум не многим лучше Watij-a, может немного дальше ушел, но в основном таже свалка кода...

Alexey Bulat комментирует...

В продолжении обсуждения Watij хочу привести еще одни пример:
package watij;
class: BaseHtmlFinder
например, method:
public Button button(Finder... finder) throws Exception {
return buttons(finder).get(0);
}

Примечание: подобную имплементацию имеют почти все методы этого класса...

Допустим, что на странице не нашлось вообще ни одного button, тогда в результате метод выкинет нам NullPointerException. Ну что за лажа, как так можно писать? Я просто в шоке, я плачу... Почему нельзя было сделать хотя бы так:

public Button button(Finder... finder) throws Exception {
Buttons buttons = buttons(finder);
return (buttons != null) ? buttons(finder).get(0) : null;
}

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

Alex Ikhelis комментирует...

Алексей, в Watir таких проблем не наблюдал. Там коммьюнити продумывало поведение в таких случаях, возвращать null или выкидывать _соответствующий_ ексепшн.

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

Direvius комментирует...

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

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

Алексей Булат комментирует...

Ответ достойный уважения. Но хочу заметить, что создатели получают взамен благодарных пользователей, которые в свою очередь могут превратиться в постоянных "клиентов", способных в будущем помогать в разработке... Как говорится: "мы в ответе за тех кого приручили." Поэтому если уж начал писать инструмент, выложил его в опенсорс, то будь добр следи за ним и правь его. Иначе пусть пишут большими словами: "Делайте с ним все что хотите, мы больше не при делах"

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.