пятница, 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 года пока создатели инструмента пофиксят проблему?

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

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

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

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


Отправить комментарий

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

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