Интересно было бы узнать больше подробностей как раз о том как данные забираются из разных банков. Просто Playwright (или что подобное), и сценарии которые ходят, кликают и скачивают? Есть конечно инициатива открытого банкинга, но увы, пока не нашёл там решений которые позволили бы получать по API нужные данные.
Привет, спасибо за статью. Есть несколько вопросов и замечаний:
в самом начале раздел “Заглушки (Stub)” кажется лишний, его содержимое появляется чуть позже под заголовком “Заглушка (Stub)”
По поводу «Мать объекта», первый раз сталкиваюсь с таким термином, это нечто распространённое? По быстрому не загуглилось. Просто по-моему назвать это «Фабрикой», как-то понятней, привычней. Да и в вашем примере, выглядит так, что удобнее использовать шаблон «Builder».
“[TODO]” в под заголовком “Зависимости”, кажется потрачен текст :)
Не пишите код 1:1: один класс — один тест. Это приводит к хрупким тестам, что затрудняет рефакторинг.
Хотелось бы услышишь аргументы по поводу этого утверждения. На мой взгляд, юнит тестирование подразумевает тестирование одного конкретного класса. Все его зависимости при этом мокаются, чтобы их поведения не сказывалось на данном классе. Как профит — нам проще вычленить конкретные краевые условия для него и обработать их все. В интеграционных тестах такое сделать может быть крайне трудно из-за большого количества сочетаний.
Честно, не понял идеи вот такого написания тестов. В чём профит?
t.Log("Given the need to test TaxiDriver's behavior at different time.")
{
testID := 0
t.Logf("\tTest %d:\tWhen working in the morning.", testID)
{
...
}
По поводу kubernetes, пробовали ли дома раскрутить k3s? Позиционируется как легковесный кубик. Я его запускал и использовал на облачной машинке 1 ядро памяти 1 гиг и 30 гигов диск. Для пет проектов - полёт нормальный.
А смотрели ли вы https://github.com/spf13/viper? Выглядит так, как-будто решает проблему. Можно пойти дальше и взять https://github.com/spf13/cobra как фреймворк для написания CLI.
Интересно было бы узнать больше подробностей как раз о том как данные забираются из разных банков. Просто Playwright (или что подобное), и сценарии которые ходят, кликают и скачивают? Есть конечно инициатива открытого банкинга, но увы, пока не нашёл там решений которые позволили бы получать по API нужные данные.
Хотелось бы услышишь аргументы по поводу этого утверждения. На мой взгляд, юнит тестирование подразумевает тестирование одного конкретного класса. Все его зависимости при этом мокаются, чтобы их поведения не сказывалось на данном классе. Как профит — нам проще вычленить конкретные краевые условия для него и обработать их все. В интеграционных тестах такое сделать может быть крайне трудно из-за большого количества сочетаний.
Честно, не понял идеи вот такого написания тестов. В чём профит?
Не проще ли писать так:
Из плюсов - можно запустить конкретный тест.
По поводу kubernetes, пробовали ли дома раскрутить k3s? Позиционируется как легковесный кубик. Я его запускал и использовал на облачной машинке 1 ядро памяти 1 гиг и 30 гигов диск. Для пет проектов - полёт нормальный.
Покупал на binance.
Довольно странно. Пару дней назад купил немного крипты на бирже с карты Альфабанка, никаких проблем.
Пожалуйста поправьте текст. Go 1.17 ещё не зарелижен, там только второй релиз кандидат вышел.
Есть маленькое замечание:
Тут битая ссылка, на sn.angry.im/@PeterCxy/104169722601610276