Поэтому позволю себе ответить

Если проект идет, есть прод-окружение, на котором заказчик периодически принимает этапы, но проект не сдан - конечно сообщаем

Если все принято и внезапно что-то там поняли - это уже доработки

Кто это сказал?

Господа, вы из-за допущений срач развели

Русскоязычное коммьюнити в естественной среде обитания, ничего необычного

Сообщаю. Но только в том случае, когда дополнительная инфрмация, это заявление о том, что баг исправлен или будет исправлен *оч близкая дата/время*. Но, всегда стараюсь прикрутить причину к важным изменениям, которые связаны с правками заказчика (не помню, чтобы было без них) или не ясным толкованием ТЗ (охохох).

Спасибо ;)

Да, я привожу в порядок.

Спасибо ;)

Не думаю что сильно помог)

5 копеек: немного непонятно если продукт был сдан заказчику, он уже в проде, и заказчик не просил доработок и т.п., то зачем там было искать баги и тем более зачем что-то править в АПИ без запроса со стороны заказчика?) собственно поэтому сообщать/не сообщать) если действительно все так как я написал выше, то сообщать это считай свою фирму подставить на деньги выходит

Например апи общее, для других заказчиков

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

Например апи общее, для других заказчиков

эт даже не костыль, это крышка гроба))

Проблемы аутсорса столь прекрасны в своем безумии.

Вот все говорят: "Продукт сдан заказчику!" Что вы имеете ввиду?

нет у нас и проблем таких, это предположение к вопросу выше

Вы при итеративной разработке каждые две недели подписываете бумаги?

Вот все говорят: "Продукт сдан заказчику!" Что вы имеете ввиду?

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

Если проект идет, есть прод-окружение, на котором заказчик периодически принимает этапы, но проект не сдан - конечно сообщаем

Вы при итеративной разработке каждые две недели подписываете бумаги?

и при той же итеративной разработке конец проекта все же имеет место быть ))

Я же говорю, у вас конфликт из-за допущений

Т.к. Александр имеет в виду, что проект идет, какие-то рез-ты по итогам итерации показываются

А большинство воспринимает как законченный проект

Когда договор истек, деньги уплочены

Я же говорю, у вас конфликт из-за допущений

По-моему, изначальный вопрос был без всяких допущений.

Коллеги, сообщаете ли вы клиенту об обнаруженных ошибках в продакшен приложении? И какую-то дополнительную информацию при этом?

Вот как раз с допущениями, информации маловато

Т.к. возможно 3 варианта

1. Проект идет. 2. Проект сдан, но идет поддержка 3. Проект сдан окончательно

Поэтому кто как понял )

Ну, ок. 4. Просто потроллить.

Как тестировать диктовку? ☺️

Голосовой набор текста

Громкость Скорость Робот / человек Язык

Ещё в зависимости от тз уровень шума фонового можно проверить

Справляется только в идеальной тишине? Или на улице надиктовывать тоже можно?

Спасибо! )

Не забудьте дефекты речи

акценты мб) впомнился видос про шотландцев в лифте

Дефекты речи, акценты, устройства ввода, шумы, плохой сигнал, да.

акценты мб) впомнился видос про шотландцев в лифте

а мне вспомнились все таксисты)

Здравствуйте. Такой вопрос по поводу тестирования АПИ. Может быть где то философский, а может есть четкий ответ.

1 делаем PATCH в АПИ по одному полю 2 получаем ответ, смотрим что в ответе поле имеет измененное значение Вопрос: нужно ли делать ГЕТ и смотреть, что там тоже измененное значение?

Лично я не вижу смысла проверять один метод другим. Сходи в базу, если хочешь посмотреть на изменённое значение

Лично я не вижу смысла проверять один метод другим. Сходи в базу, если хочешь посмотреть на изменённое значение

+

Если в ответ приходит вся entity - то смысла в повторном гете действительно мало. Если нет - то смысла чуть больше.

В базу, конечно, железобетонный вариант, но это не всегда применимо, увы.

1 делаем PATCH в АПИ по одному полю 2 получаем ответ, смотрим что в ответе поле имеет измененное значение Вопрос: нужно ли делать ГЕТ и смотреть, что там тоже измененное значение?

А вдруг разрабы закешировали GET ответы или что-то в этом роде, конечно надо сходить.

А вдруг разрабы закешировали GET ответы или что-то в этом роде, конечно надо сходить.

а что, кэширование гет ответов это баг?

Даже не знаю что ответить, какой-то явный наброс )

ну мы например специально кешируем некоторые геты

Нет, кеширование гет ответов это не баг, а нарушение когерентности кеша - это баг, так то!

к когерентность

А если для глупого - что такое нарушенная когерентность кеша? Обновил модель, но кеш не инвалидировался и пришла старая модель из кеша?

Ага

У меня такое было точно 1 раз

ERROR: S client not available

Как известно в разработке есть 2 самые большие проблемы - инвалидация кеша и именование функций (с)

Мне бы ваши проблемы (с)

1 делаем PATCH в АПИ по одному полю 2 получаем ответ, смотрим что в ответе поле имеет измененное значение Вопрос: нужно ли делать ГЕТ и смотреть, что там тоже измененное значение?

Если GET вы проверяли уже до этого, и там вернулся правильный ответ, то не нужно

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

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

http://fy.chalmers.se/~appro/nt/TXMouse/

или это https://www.autohotkey.com/

Всем привет. Следующая ситуация - мы покрываем наше приложение е2е тестами при помощи webdriverIO, но делаем это неправильно и не можем их нужным образом их перезапускать. Вот пример теста: describe('Documents', () => { it('is possible to create document') it('is possible to preview document') it('is possible to edit this document') it('preview after edit has right values') }) Как я уже сказал, проблема данного теста в том, что он неперезапускаем при помощи встроенных средств mocha, потому что при ошибке, будет перезапущен it блок, в котором она произошла, а не весь файл заново. Допустим, на 3 этапе что-то произошло не то, форма отправилась с неверными значениями и на 4 этапе mocha просто проверит несколько раз то, что одно значение не совпадает с другим, вместо того, чтобы провести edit заново. В связи с этим встает вопрос о том, как правильно тестировать такие штуки. И чтобы при этом, прогон теста был максимально приближен к UI настоящего пользователя.

Можно, конечно, поместить весь тестовый сценарий под один it блок, но мне кажется это диким.

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

всем привет. кто нибудь работал плотно с GitHub? у меня вопрос по поводу issue. у них какие могут быть состояния? только открыт или закрыт? issue может быть удаленным?

Там же в описании в гит ишью всё написано 0_о

https://developer.github.com/v3/issues/ ты про это?

state string State of the issue. Either open or closed.

Именно.

может я чтото пропустил или не учел, отсюда и вопрос

я в жире столько проработал, мне неуютно осознавать, что issue нельзя удалить

а зачем удалять?

Собственно, я и в джире не пойму зачем удалять.

создал какую нибудь чушь, и чтоб никто не увидел ЭТО

спасибо вам!

Сравнивать джиру и гитхаб эт конечно хорошо.

создал какую нибудь чушь, и чтоб никто не увидел ЭТО

так отредактировать )

Сравнивать джиру и гитхаб эт конечно хорошо.

Ну, не гитхаб, а гит ишьюс.

удалить проще - думать не надо

ок

?

http://fy.chalmers.se/~appro/nt/TXMouse/

Огромное спасибо! это именно то что я искала!! ?