Size: a a a

Software Design/Architecture/Zen

2021 June 11

SP

Sergey Protko in Software Design/Architecture/Zen
ну если проект не шибко масштабный то ты можешь взять QA (или сам) и тулы которые умеют "записывать" твои действия. Благо их валом.

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

Да, такие тесты это просто смоук но в целом уже неплохо так риски снижает. И оч дешево
источник

SP

Sergey Protko in Software Design/Architecture/Zen
есть сча нынче всякие стартапы которые там "машин лернинг смоук тесты" где "тип вообще делать ничего не надо и оно само"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну просто если никто не знает как это работает где гарантии что "это вот условие или ситуация которую в коде обрабатываем все еще нужна"?
источник

A

Andrew in Software Design/Architecture/Zen
как
источник

SP

Sergey Protko in Software Design/Architecture/Zen
есть еще прикольные штуки - например можно на совсем диком легаси расставить по коду метки - tombstone - мол глянуть что мертво что живо
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Я пока считаю более эффективно находить сгустки какой-то логики, покрывать тестами, смотреть на покрытие (какой код запускался, какой подключался), формировать тесткейсы, и ререализовывать их сбоку, а потом переключать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну смотря на каком уровне. на уровне API это может быть полезно. На уровне отдельных компонентов - врядли
источник

SP

Sergey Protko in Software Design/Architecture/Zen
но по ситуации конечно, я ж не знаю специфики у тебя
источник

ST

Serguei Tarassov in Software Design/Architecture/Zen
"Все знания в коде" - это как? Ни одной неявной зависимости, семантика кода на уровне модели ПрОбл (с помощью комментариев 😂)?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
по сути при работе с легаси то о чем я говорю это избегать подходов которые называются "Feature parity"
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Это так что чтобы понять как именно работает код надо знать какими действиями он задействуется весь (все варианты полиморфизма, логических ветвлений и т.д) .
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну то есть условно ты юзаешь "тесты" как "запустить кусочек глянуть че там в рантайме"?
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
ага
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ты мог бы делать сэмплами с прода)
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
и зафиксировать результат
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну мол для 5% запросов делать вот трэйсинг логи более подробные и т.д.
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
масштаб большой) я смотрю на маленькие кусочки
источник

SP

Sergey Protko in Software Design/Architecture/Zen
можно добавлять логи если мол ожидания по коду и реальность различаются
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
по опыту даже все 100% трейсов на проде не дают 100% видения всего что может происходить
источник

SP

Sergey Protko in Software Design/Architecture/Zen
короч если тебе удобно так делать с тэстами то ок. я обычно в блакнотике диаграмки рискую и делаю безопасный рефакторинг типа вынос кода в методы с нормальными именами
источник