вторник, 27 ноября 2012 г.

Deadlock SoapUI

Пока писал циклы с использованием "Conditional Goto" SoapUI задолбал падать... Никак не мог понять почему... Сначала подумал, что сам дурак...  написал assert в TearDown Script к тест-кейсу, но все оказалось не так просто.

Сначала словил первый баг: когда assert не выполнялся soapUI "засеривал" (дизейблил) все элементы интерфейса кроме главного меню, но как оказалось - это еще полбеды...

Убрал я TearDown Script, добавил шаг Groovy Script с необходимыми проверками (вне цикла) и попытался запустить тест несколько раз снова.
Если цикл повторялся несколько раз, то SoapUI зависал с deadlock на  AWT-EventQueue-0... и тогда приходится убивать процесс с SoapUI, причем если отключить добавленный groovy script вроде как все проходит нормально (возможно повезло). Как этот скрипт влияет на цикл, ведь он находится вне его и до конца цикла обычно еще далеко, не понятно.

Шаги тесты следующие:
1. request
2. property trasfer
3. request
4. Delay
5. Groovy script для обработки пропертей
6. Goto step 3, если не выполнены условия
7. Groovy script with assertion

Есть подозрение, что падает чаще всего именно на Delay. Также под подозрением собственный Garbage Collector SoapUI.
В общем запостил баг разработчикам SoapUI, посмотрим что ответят...
------------------------------------------------------------------------------------------------------------

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

Комментариев нет:

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