попробуй втупую char buf[]; <- внутри размер && szBuf = buf;

попробую, но уже завтра, сейчас уже времени нет (. Спасибо за помощь.

попробую, но уже завтра, сейчас уже времени нет (. Спасибо за помощь.

правильно, пятница - святое

правильно, пятница - святое

) ну почти

правильно, пятница - святое

Так уже суббота

у кого как :)

https://www.youtube.com/channel/UCCNNoK7IcTyCss8wv75oyeA/videos?view_as=subscriber Learn selenium from basic to advanced level.

кто может помочь - я тестирую на яве через селениум (на последнем релизе от декарабря 2017) по средством FireFox браузера 58.0.2 версии сайт (веб приложение) и когда у меня возникает попап ADF (по сути JSF - Java Faces) я кликаю кпопку типа ОК и при попыте submit падает приложение автотеста из за того что селениум не может перечитать DOM модель

вопрос - это косяк в веб-приложении или мой автотест кривоей?

ADF - это форк от JSF с AJAX

сами автотесты на фрейворке на JBehave 4

1) что такое попап ADF? 2) что за ошибка? 3) есть пример доступный?

1) что такое попап ADF? 2) что за ошибка? 3) есть пример доступный?

1) html iframe со кодом javascript 2) WebElement уже не в модели DOM - логи могу скинуть в понедельникм 3) нет - он в локальной сети банка - у нас не разрешается выкладывть веб морду наружу

Если stale element - нужно не запоминать, а о новой опросить дом

Т.е более ранний референс на дом будет невалидным

на память типа "this element is dead" а элемент это и есть кнопка ОК в моем приложении

а как я сделаю submit если страница умерла?

на память типа "this element is dead" а элемент это и есть кнопка ОК в моем приложении

can't access dead object

да

мне нужно запоснить форму

Перед кликом который у тебя не срабатывает найди нужный элемент и сразу кликай на него

а driver.navigate().refresh() нельзя - браузер материт что на форме есть не отправленные данные на сервер

Зачем тебе рефреш?

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

сейчас миллион решений можно преположить

заведи вообще за привычку завести методы submit() enter_name() enter_surname()

их реализация: this.get_element(YOUR_LOCATOR) где get_element() - wait.Until......(Expected condition, locator)

т.е. у тебя нет смысла хранить при инициализации теста вообще какие-бы то ни было состояния страницы

она будет у тебя пробегать по дому непосредственно перед вводом текста или клика по странице

т.е. представь что твоя форма - это будет некий описанный классом PageObject набор методов с формами ввода и кликами по кнопкам. вызов методов будет прямо на месте всегда, каждый раз осуществлять поиск DOMа. Зачем так нужно? это помогает в реактивных приложениях и всяких ангулярах или очень злых jquery

ясно

спасибо! всем

Уважаемое собрание, а как в вашей компании ведется версионность требований? Есть ли с этим проблемы, и, если нет, то как организован процесс?

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

ненене

плоха так

В чем ведете?

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

в чем пишется дока?

Уважаемое собрание, а как в вашей компании ведется версионность требований? Есть ли с этим проблемы, и, если нет, то как организован процесс?

docx файл, в шапке пишутся даты с названиями правок (ченжлог). в Word можно увидеть историю правок и комментарии

docx файл, в шапке пишутся даты с названиями правок (ченжлог). в Word можно увидеть историю правок и комментарии

ай нет. Ну есть же системы контроля версий

файл коммитится в систему контроля версий

Все в гит с коммитами, с номерами задач и ченжлогом

это спека, спека коммитится в систему

а зачем вообще требования дублировать?

Зачем одновременно держать и старую и новую версию?

кто сказал, что они дублируются?

я людей попутала)

я думала что это все задавший вопрос человек пишет)

а он писал именно про дублирование)

есть такой принцип Single source of truth. исходя из него 2 факта о системе в разных файлах не могут противоречить друг другу. Наличие двух документов разных версий с пересекающимися "зонами ответсвенности" это плохо

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

да такой вариант вообще бред

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

так что в истории конфли еще и не видно изменений -_-

что одновременно имеется 2 требования, которые друг друга "дополняют" - это понятно, что плохо :) Я предлагал вариант - при значительном изменении создавать новое ФТ (с копипастой актуальной инфы из старой), а старую отправлять в архив. Чтобы актуальный документ всегда был один единственный на один функционал

но чувствую, что это тоже какое-то кривоватое решение

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

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

как page history отображается?

если документ в итоге единый - и аналитики после правки какой-то таблицы, которая должна попасть в отчет, нажали выполнение скрипта, который соберет файл и вставит его на место существующего, то page history должна показать тот блок. который аналитик поменял

ERROR: S client not available

если его работа с кучей документов из разных мест касалась непосредственно одной задачи, то будет хорошим тоном "склеивать" изменения. Т.е. для аналитика не запускать перегенерацию скрипта, чтобы история правок не была слишком длинной и "рваной", до тех пор, пока все его правки в рамках именно задачи не были сделаны

создается страница в конфле и таска+сабтаски в джире. В конфле макросы на рендер контента из джиры. Затем все описывается в джире. Хистори можно посмотреть, только открыл хистори в джире, что само собой такое себе удобство

ФТ эти довольно атомарны

т.е. например есть менюшка и в ней 10 пунктов. Будут 1 ФТ на само меню и отдельные ФТ на каждый пункт

и вот прикиньте, при изменении требований по 1 пункту на него создается еще дополняющее ФТ

при этом они уже 3 месяца не могут структуру вики в виде дерева оформить. Просто всё в кучу свалено в 1 ветке

но вопрос в версионности, да :))

Ну например с меню

Страница в конфе с описанием как меню должно себя вести само по себе

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

Далее пишешь состоит из:

Макросом хуячишь дочерн е

В дочерних создаешь пункты меню

Ушел пункт - страница ушла

Пришел пункт - страница добавилась

И что мешает страницу в конфе тупо делить на итерации

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

меняйте правила, объясняйте неудобства, узнавайте почему сделано так или иначе

Типа итерация 1 статус имплементируетс

Под отбивкой итерация 2 на аналитике

То, что ща добавляется к требованиям, но делать не надо

То, что ща добавляется к требованиям, но делать не надо

ну а как это разграничить в одном доке? Как понять что сейчас надо делать, а что добавилось после? Оно же может за полгода например 5 раз поменяться

меняйте правила, объясняйте неудобства, узнавайте почему сделано так или иначе

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

Вот допустим у вас есть конфля с описанием: "при нажатии кнопки А должно происходить действие Х". А потом требование меняется на "при нажатии кнопки А должно происходить действие У". Как у вас в таком случае это отражается в вики?

Зачеркивается там, внизу подписывается, создается новый док v2 или еще как :)

Скажу так: я считаю вики вести не нужно

фича должна быть индексируема и быть самодостаточна в описании таски

с правильными тегами находится на раз два

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

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