Java или JavaScript для автоматизации тестирования SOAP-сервисов?

Ребята, есть небольшой вопрос. SOAP UI поддерживает скрипты как на JavaScript так и на Java, но я не знаю ни того, ни другого. Насколько реально разобраться в Java, на достаточном для тестировщика уровне за несколько месяцев. Или лучше сконцентрироваться на JavaScript как на более простом языке? С другой стороны, на Java есть много популярных фреймворков, а JavaScript в этом плане менее привлекателен.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я бы посоветовал отдать предпочтение groovy/java имхо в soapui у них больше возможностей.

Если быть точным, то в soapui используется groovy, a не java. Но груви интепритатор так же исполняет и джава код(код груви интерпретируется в байт код который исполняется jvm). Груви проще в освоении чем джава т.к. в нем как и в javascript’e нет строгой типизации.

JavaScript сложнее Java. И чем более существенная по объёму разработка, тем больше волосы дыбом. А вообще — разбирайся с фреймворком, и не так важно на чём он. Там знания языка нужно минимальное, больше обезьяньей работы.

Да, и тебе не нужны «больше» популярных фреймворков. Возьми один. И только когда разберёшься, тогда берись за следующий — тогда и определишься.

Почему язык не нужно особо знать: тестовые программы имеют короткий цикл жизни, и выполняются чаще всего под контролем. К реальному софту, не тестовому, есть серьёзные требования — по стабильности, по скорости, по интеграции в другой софт, по устойчивости после сбоев, и конечно по удобству для пользователя. Это львиная доля того что делают программисты. Тебе это всё не нужно. А то что нужно — можно поднять за неделю, при условии что базовые навыки программирования у тебя есть. Если нет — тут сложнее и дольше.

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

Строгая типизация новичку — огромная помощь. Да и профессионалу на три порядка удобнее работать с честными классами и интерфейсами, нежели иметь в виду огромнейшее ХЗ в виде объекта this и всеми прелестями замыканий.

Замыкания хороши там, где понимаешь что и зачем делаешь. То есть в строго ограниченном кусочке кода. Иметь их по-умолчанию — это грёбаный ад.

JavaScript хорош именно как скриптовый язык. Когда основные объекты построены и работают, а он по-мелочам делает маленькие понятные вещи. Я считаю, давно пришло время выпускать нормальный типизированный язык для веб-программирования. Но... если даже с войной html-тегов производители браузеров за только лет покончить не могут, то с языком может оказаться что сами браузеры сдохнут раньше чем договорятся.

PS. Но если его таки выпустят, это будет Java. И скорее всего, поставляться в виде плагинов в браузер, позволяющими работать с конкретным большим ресурсом. Особенно в части энтерпрайза и всех его клиентов. Так что Microsoft действительно опередил время, но ослик сдох от старости и упрямства в вопросе монополии. Смешно сказать — осёл устроил войну стандартов, сам сдох, а война всё ещё идёт :)

Замыкания хороши там, где понимаешь что и зачем делаешь.
так, не надо смешивать.
замыкание(как механизм ссылок на переменные в месте объявления) и контекст с его изменениями.
методы объекта в месте объявления будут создавать замыкания на окружающие переменные.
метод объекта при запуске вида obj.methodName() никак не меняет this
Да и профессионалу на три порядка удобнее работать с честными классами и интерфейсами, нежели иметь в виду огромнейшее ХЗ в виде объекта this и всеми прелестями замыканий.
сами по себе «классические» классы/интерфейсы ни плохи, ни хороши.
зависит от архитектуры.
монстр на полдюжины слоев абстракции, где изменение структуры хранения одной сущности вызывает каскад правок — это ли удобство?
и классы-интерфейсы не спасут в таком случае. да, дебаг будет немного быстрее. и всё.

Если речь идёт о написании тестов для соап вебсервисов, то в большенстве случаев там не нужно разводить каких-то сложных ооп архитектур с классами и интерфейсами, зачастую там все укладывается в пару строк кода(подставить в запрос текущую дату или сгенерить uuid в запросе и т.п.) и сделать assert. Т.е. сам код является больше вспомогательным чем основным средсвом.

«Но если его таки выпустят, это будет Java. »

Упаси боже. Да и, вроде бы, уже можно использовать (или уже нет?) во всех популярных браузерах, но как-то особой популярностью не пользуется.

Я считаю, давно пришло время выпускать нормальный типизированный язык для веб-программирования.
Уже выпустили www.impredicative.com/ur
JavaScript сложнее Java
хорошая шутка от джависта )))

Я оцениваю прежде всего способность читать чужой код. Либо свой же но спустя много времени. Владея и тем и другим, я знаю что по мере рефакторинга и правок количество комментариев в коде Java резко снижается. А в JavaScript постоянно растёт. И если код предназначен для чтения кем-то другим, то >50% уже отлаженного кода занимают комментарии. И ещё два по столько — документация.

А вообще холивар. Всё равно от нас нихрена не зависит. Если через 10 лет все будут кодить на китайском — выучим китайский.

Не вивчимо. Люди англійську не можуть вивчити самі (щоб правально всі часові форми юзати, всякі там активи і пасиви), а ви — китайську. Буде «It’s all Greek to me»

Согласен, JS очень быстро становится трудно читаем с ростом кодовой базы, особенно если написано как следует, т.е. лапшой, с функциями 10-ти кратной вложенности, сплошными колбеками, call/apply тут и там и так далее. Я очень удивляюсь когда говорят о JS как о простеньком языке для старта, как по мне то даже С++ проще будет.

сам по себе JavaScript прост и намного проще C++ и Java. Но это как легковес боксер — в своей категории хорош, однако с тяжеловесами не стоит тягаться. Действительно в больших проектах JavaScript сложно воспринимать, но это только потому, что он и не создавался для больших проектов.

если вы в рамках соап юи то там еще Groovy был

Подписаться на комментарии