v
Оценить риски обработки потоков информации через 1 систему?
Size: a a a
2021 February 15
GK
vito
А можете пояснить про подумать?
Почитайте agile integration architecture или distributed integration architecture, что одно и то же
v
Ок, спасибо
GK
vito
Оценить риски обработки потоков информации через 1 систему?
Всё сложнее, стоит почитать )
v
Ок, спасибо
SB
Почитайте agile integration architecture или distributed integration architecture, что одно и то же
даже у IBM были хорошие статьи на эту тему, ЕМНИП
GK
даже у IBM были хорошие статьи на эту тему, ЕМНИП
Да, у IBM и RedHat
v
даже у IBM были хорошие статьи на эту тему, ЕМНИП
Уже нашёл, как раз их. Спасибо большое за помощь
p
F
Мы некоторое время назад начали делать простенький MVP. Django+Vue, что может быть проще. Так вот после первого же релиза MVP мы сели нашей командой в два человека и написали тесты на API с обеих сторон (ну не вот полноценные контракт-тесты). И надо сказать, за несколько месяцев это сэкономило нам много нервов и времени, и главное нервов. И я считаю, на этапе MVP тесты тоже нужны, потому что, в частности, что MVP постоянно меняется и можно всё легко сломать. Другой вопрос про баланс и покрытие. И я тоже придерживаюсь мнения, что %% покрытия тестами - так себе метрика. Я работал в одном проекте, где покрытие было типа 95%, но вечно были проблемы, потому что тесты не тестировали то, что нужно. Проверяли, например, что у Персоны создаётся Адрес. А что Адрес с неверными полями - не проверяли :)
Mvp выкидывается после подтверждения гипотезы или ее опровержения. А вы тесты сверху, а потом в прод. Это много что может быть, но никак не mvp.
GK
В одном проекте мы делали процедуры первичной загрузки в MDM
Такие процедуры выполняются, понятное дело, один раз
Решили не писать тесты
Горько пожалели, потому что процедуры оказались сложными и нужно было их постоянно выполнять на разных средах до вывода в прод
В данных постоянно что-то ломалось
Точнее, мы делали MDM, всё ядро покрывали тестами. А процедуры первичной загрузки нет.
Такие процедуры выполняются, понятное дело, один раз
Решили не писать тесты
Горько пожалели, потому что процедуры оказались сложными и нужно было их постоянно выполнять на разных средах до вывода в прод
В данных постоянно что-то ломалось
Точнее, мы делали MDM, всё ядро покрывали тестами. А процедуры первичной загрузки нет.
VN
А можно на пальцах от чего считают "покрытие"... Ну т.е. как понять покрыто оно или нет...
Если крышый дом покрывают, то тут понятно - дождь пошел и оно либо течет либо не течет и если течет, то уже разбор полетов:
- не всю покрыли
- плохо покрыли (щели, черепицу не в том порядке положили)
- ветром сдувает
- и т.п.
Если крышый дом покрывают, то тут понятно - дождь пошел и оно либо течет либо не течет и если течет, то уже разбор полетов:
- не всю покрыли
- плохо покрыли (щели, черепицу не в том порядке положили)
- ветром сдувает
- и т.п.
SB
Mvp выкидывается после подтверждения гипотезы или ее опровержения. А вы тесты сверху, а потом в прод. Это много что может быть, но никак не mvp.
MV используется для подтверждения или опровержения гипотезы, как это делать без реальных пользователей - я с трудом представляю :)
АЛ
Лучший код - это код, который не написан. Был кейс, когда посадили пару человек в call-центр и на ручном приводе с записями в тетрадке прогнали первых пользователей по бизнес-процессу. Опа, выяснилось, что не летит модель. Ну ок, выгнали людей из Call-центра :) Затраты на разработку софта - 0 р.
F
V N
А можно на пальцах от чего считают "покрытие"... Ну т.е. как понять покрыто оно или нет...
Если крышый дом покрывают, то тут понятно - дождь пошел и оно либо течет либо не течет и если течет, то уже разбор полетов:
- не всю покрыли
- плохо покрыли (щели, черепицу не в том порядке положили)
- ветром сдувает
- и т.п.
Если крышый дом покрывают, то тут понятно - дождь пошел и оно либо течет либо не течет и если течет, то уже разбор полетов:
- не всю покрыли
- плохо покрыли (щели, черепицу не в том порядке положили)
- ветром сдувает
- и т.п.
Да ни как, показатель ради показателя. Такое же извращение, что и с agile получаем. Крайность.
D
MV используется для подтверждения или опровержения гипотезы, как это делать без реальных пользователей - я с трудом представляю :)
Не, можно. Гипотезы бывают разными. Например "Выполнить вот такой расчёт можно за 10 минут".
F
Да если даже нельзя в кейсе, зачем тесты, прогнал на группе с багами, получил данные, выкинул (ну максимум идею кода оставил, идею). Начал писать уже альфу там. И покрывай узкие места через tdd уже.
VN
Да ни как, показатель ради показателя. Такое же извращение, что и с agile получаем. Крайность.
Не... У меня то как раз вопрос к тем кто считает, чтобы понять КАК они это считают?
SB
V N
Не... У меня то как раз вопрос к тем кто считает, чтобы понять КАК они это считают?
Считается кол-во (обычно строчек) кода, которые работали в ходе выполнения тестов:
https://www.jacoco.org/jacoco/trunk/doc/counters.html
https://www.jacoco.org/jacoco/trunk/doc/counters.html
VN
Считается кол-во (обычно строчек) кода, которые работали в ходе выполнения тестов:
https://www.jacoco.org/jacoco/trunk/doc/counters.html
https://www.jacoco.org/jacoco/trunk/doc/counters.html
Хм... Т.е. из описания 146% вполне себе возможный результат...
А есть практический смысл в таком подсчете?
Или может я неправильно на само тестирование смотрю (кстати тестирований кмк тоже много разных видов, для разных целей)... :(
А есть практический смысл в таком подсчете?
Или может я неправильно на само тестирование смотрю (кстати тестирований кмк тоже много разных видов, для разных целей)... :(