Перейти к содержимому

Фотография

Модульное тестирование: JUnit VS TestNG


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 5

#1 yvaronin

yvaronin

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Воронин Евгений Васильевич

Отправлено 21 апреля 2009 - 09:05

Добрый день, уважаемые коллеги!

Помогите, пожалуйста, новичку с чисто практическим вопросом:

Считается, что Java-разработчики могут легко тестировать свои методы при помощи JUnit.

1. Может ли кто-то компакто по пунктам популярно объяснить, по каким причинам следует использовать взамен JUnit пакет TestNG?

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

А что есть еще интересного в TestNG, позволяющее остановить выбор именно в его пользу?

2. И еще один вопрос: бытует мнение, что использование языка Groovy облегчает разработку и использование модульных тестов совместно с JUnit. Так ли это интересно, что стоит дополнительного изучения и последующего использования?

Большое спасибо за Ваши ответы и замечания.
  • 0

#2 Troubleshooter

Troubleshooter

    Опытный участник

  • Members
  • PipPipPipPip
  • 398 сообщений
  • Город:Киев

Отправлено 22 апреля 2009 - 08:29

Добрый день, уважаемые коллеги!

Помогите, пожалуйста, новичку с чисто практическим вопросом:

Считается, что Java-разработчики могут легко тестировать свои методы при помощи JUnit.

1. Может ли кто-то компакто по пунктам популярно объяснить, по каким причинам следует использовать взамен JUnit пакет TestNG?

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

А что есть еще интересного в TestNG, позволяющее остановить выбор именно в его пользу?

2. И еще один вопрос: бытует мнение, что использование языка Groovy облегчает разработку и использование модульных тестов совместно с JUnit. Так ли это интересно, что стоит дополнительного изучения и последующего использования?

Большое спасибо за Ваши ответы и замечания.

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

#3 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 22 апреля 2009 - 10:42

1. А чем плох список преимуществ от разработчиков?
Как-то давно я исследовал применимость JUnit/TestNG вместе с Selenium, TestNG мне больше понравился. Почему я не помню.

2. Это мнение имеет под собой основания.
Если вам нужно писать именно модульные тесты, то их наверняка пишут разработчики. Тут есть два варианта:
а) они захотят учить второй язык
б) они не захотят его учить
Мне кажется для модульных тестов, которые пишут разработчики все равно какой вариант, им виднее.

Если же тесты будут писать тестировщики (я надеююсь это будут не модульные тесты?) тогда Groovy лучше и проще т.к. это динамический язык, без синтаксического overhead, с клевыми фичами, которых нет даже в Java.
Сравните
println "Hello, World!"
В Groovy и то, что необходимо написать в Java для того же результата.
Если надо кого-то обучать программировать с нуля или с небольшого старта, то мне кажется, Groovy в частности и динамические языки вообще, это отличный способ.
А если ваши тестировщики уже пишут на java и полет нормальный, зачем что-то менять?
  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#4 yvaronin

yvaronin

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Воронин Евгений Васильевич

Отправлено 22 апреля 2009 - 11:26

1. да, большое спасибо за ответы, да, речь идет именно о тестировании своих классов разработчиками, а не тестировщиками, то есть так называемом development testing. Да, я читал о преимуществах от разработчиков, но мне было бы интересно услышать от бывалых людей, которые попробовали и в свое время сделали соответствующий выбор.
Еще вчера удалось найти вот эту интересную статью, которая мне немного прояснила ситуацию.

2. У нас такая ситуация, часть разработчиков (работающих на одних хозяев) использует некий коммерческий тестовый фреймворк, базирующийся на groovy-unit тестах. Специфика среды такая, что легко тестируются там также и GUI-интерфейсы. Вторая часть разработчиков (работающая в других проектах) используют junit. Вот и возникает вопрос, стоит ли перенимать практику первых (но речь идет не о среде, а только о Груви как средстве), то есть позволит ли такая методика далее после освоения Груви сократить время разработчикам на модульное тестирование, или лучше не дергаться и идти в старом русле. Также речь тут же идет и о TestNG как возможном альтернативном варианте, в связи с чем и был первый вопрос. Знаю, что многие также комбинируют TestNG и JUnit в работе, так как типа JUnit вместе со своими расширениями (например StrutsTestCase) смотрятся более рационально, чем сам TestNG. В связи с этим и возникли мои вопросы.

P.S. Наши другие проекты связаны в основном с ява-клиент-серверными приложениями в области логистики, работающими с базами оракл.
  • 0

#5 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 22 апреля 2009 - 13:17

Коллеги, у вас что, разработчики сами не могут сообразить, что им удобнее использовать, Java или Groovy (или JRuby, или Jython, или ещё что-нибудь)?

Чем хорош JUnit? Тем, что он есть везде, встроен во все среды разработки, средства автоматизации сборки, непрерывной интеграции, и т.п. Поэтому не надо предпринимать никаких дополнительных действий по развёртыванию и встраиванию TestNG в какое-нибудь хитрое место (типа фейковый EJB- или сервлет-контейнер). Если это хитрое место хитро работает с класс-лоадерами, в этом случае есть шанс, что TestNG вообще без модификации не взлетит. У меня были случаи, когда тесты на TestNG не запускались из-за того, что в проекте использовалась какая-то навороченная библиотека для динамической генерации запросов к БД. В общем, если у вас сложная конфигурация и/или окружение, есть вероятность того, что TestNG не взлелит.

Чем хорош TestNG? Фичами. Их там гораздо больше, чем в JUnit, даже с учётом наличия разных расширений (да, есть возможность и в JUnit сделать параметризованные тесты или зависимости, но это требует дополнительных усилиий). Но некоторые фичи в TestNG работают не совсем так, как ожидается. Ну или документировано не совсем так, как работает :)

Ещё в JUnit есть потрясающая штука @RunWith, которой нет в TestNG, но это совершенно отдельная история...
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#6 yvaronin

yvaronin

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Воронин Евгений Васильевич

Отправлено 22 апреля 2009 - 14:09

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

Пробую подвести итог:

Значит, я понимаю, что JUnit и TestNG интереснее комбинировать, и в зависимости от специфики приложений (или фичей в приложении) выбирать в качестве основопологающего фактора при development testing.

Теперь это будет легче объяснить руководству и указать несколько примеров, где что лучше работает.

То же будет касаться и использования скриптовых языков при тестировании.

Большое спасибо, коллеги! Поправьте меня, если я серьезно неправ.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных