Вы абсолютно правы. Термин не совсем подходящий. Под оффлайном имелось в виду оплата непосредственно на кассе (qr/nfc-табличка, в которые вшита ссылка), а сам способ является онлайн, скорректировала в статье. Спасибо!
Спасибо за комментарий. Информацию, которую вы хотите получить, рассказана в докладе моего коллеги "Платежные ссылки и где они обитают". Целью этой статьи является общее ознакомление с платежными ссылками СБП и их работой в мобильных платформах.
Я всегда пишу сначала тест, потом код. Это мне очень помогает в написании новой функциональности и правке багов, экономя мое время и помогает концентрироваться на самом важном и не хранить в голове кучу разных кейсов, а после написания тестов быть уверенной что моя новая фича готова и ее никто не сломает(плюс тестов).
Обожаю TDD. Являюсь практикующей этот способ при написании/доработки фичи/фикса багов. Эффективная методология для разработки. Очень меня спасает, использую ее и каждый раз спасает. Не удивляюсь, что кто-то не понимает этого и хейтит ее, видя в ней смысл лишь в виде "правки тестов". Сделала вывод для себя: чтобы понять TDD и вообще тесты, нужно мыслить по-другому чтоб использовать преимущества, но к сожалению, у разработчиков возникает сразу отторжение в виде непривычки и негатива.
На своем опыте поделюсь кейсами: в проекте 7 разрабов, есть фичи/API/компоненты и модули которые все юзают. Однажды, на ревью чел выкатывает pr, в котором удалил одну из строчек. Попросив его запустить юнит-тесты, результат: упало два, моя фича сломана, ну и какого черта такое произошло? Как оказалось, удалил случайно. Вывод: в общей команде, когда каждый день правки и фиксы, тесты являются ГАРАНТОМ сохранности фичей.
Далее: фича по работе с картой, нужно формировать запрос к бд чтобы на карте отобразилось то, что соответствует запросу. Значит входных параметров для запроса 4, в общем вариантов для параметров получается >30, и что, мне теперь написав код, запускать прогу и руками смотреть что все корректно работает+в голове держать и помнить все нюансы и варианты? СЕРЬЕЗНО? Учитывая, что с каждым часом я могу поменять структуру кода и придется заново проверять что все варианты работают. Нет, спасибо, итого пишу тест на строку формирования запроса(31 тест) за несколько млск отработал и показал что все работает, значит код готов, прогу один раз запустила просто полюбоваться. И можно код менять, т к тесты гарантия что все ок + в команде над этой фичой есть ещё разраб. Захотел он поменять мой код, поменял. Я спрашиваю, а тесты ты запускал? Нет, зачем и так все работает? Серьезно?! Запусти-ка! Упали ? Тесты не трогай, код в порядок приведи.
И третий кейс: тестировщик нашел баг, мне что теперь его воспроизводить руками как он? Пошла, тест к текущим написала, ну да красный, ща поправлю, поправила, все тесты запустила, все зелёные, ничего не сломалось, збс! А ещё, иногда от сервера нужно подставить ответ и посмотреть что все ок, тогда мок ответа в тест и расслабляешься, все ок (без всяких чарлизов, дебагеров в рантайме и без сетевых задержек). Ещё я люблю писать тесты контрактов чтобы, например, если появился новый формат даты, добавить его и тесту дать эти форматы - значит зафиксировано ?
Итого: TDD - сохраняет и гарантирует что все работает, сохраняет фичи при правках(регресс) и самое важное для разраба - автоматизирует его время разработки ❤️ это был крик души, потому что дедлайны жёсткие, качество требуют, спасаюсь как могу TDD. Моя любимая цитата: Good developers write good code, and great developers test their good code.
Практически ко всему, что описано, я приходила через боль и ошибки при изучении и применении в своей разработке. В итоге, приходишь ко всем решениям естественным путем. А после, уже понимаешь этот кайф от написания теста, влюбляешься в это и главное, меняется сам взгляд к разработке и видение написанного кода!
Выявила полезность написания теста для себя, по методу Test Last:
во время написания теста всегда нахожу ошибки и баги, которых не заметила бы сразу либо он воспроизвелся бы в очень в редких кейсах — это же круто!
во время написания теста всегда смотришь на структуру кода и где можно оптимизировать код и улучшить для лучшего чтения и его логической расстановки — сам себе ревьювер несколько раз (+правило Бойскаута оставить после себя лучшее)
когда забываешь как работает кусок кода, а тебя спрашивает бизнес что где-то не работает либо как работает, смотришь на тест и быстро и четко можешь ответить и для доказательства привести ссылочку на тест-кейсы — вопросы сразу уходят.
Вы абсолютно правы. Термин не совсем подходящий. Под оффлайном имелось в виду оплата непосредственно на кассе (qr/nfc-табличка, в которые вшита ссылка), а сам способ является онлайн, скорректировала в статье. Спасибо!
Спасибо за комментарий. Информацию, которую вы хотите получить, рассказана в докладе моего коллеги "Платежные ссылки и где они обитают". Целью этой статьи является общее ознакомление с платежными ссылками СБП и их работой в мобильных платформах.
Есть ещё один удобный способ платить по QR-коду - с помощью мобильного приложения СБПэй
Спасибо за комментарий, учту ваши пожелания.
Я всегда пишу сначала тест, потом код. Это мне очень помогает в написании новой функциональности и правке багов, экономя мое время и помогает концентрироваться на самом важном и не хранить в голове кучу разных кейсов, а после написания тестов быть уверенной что моя новая фича готова и ее никто не сломает(плюс тестов).
Обожаю TDD. Являюсь практикующей этот способ при написании/доработки фичи/фикса багов. Эффективная методология для разработки. Очень меня спасает, использую ее и каждый раз спасает. Не удивляюсь, что кто-то не понимает этого и хейтит ее, видя в ней смысл лишь в виде "правки тестов". Сделала вывод для себя: чтобы понять TDD и вообще тесты, нужно мыслить по-другому чтоб использовать преимущества, но к сожалению, у разработчиков возникает сразу отторжение в виде непривычки и негатива.
На своем опыте поделюсь кейсами: в проекте 7 разрабов, есть фичи/API/компоненты и модули которые все юзают. Однажды, на ревью чел выкатывает pr, в котором удалил одну из строчек. Попросив его запустить юнит-тесты, результат: упало два, моя фича сломана, ну и какого черта такое произошло? Как оказалось, удалил случайно. Вывод: в общей команде, когда каждый день правки и фиксы, тесты являются ГАРАНТОМ сохранности фичей.
Далее: фича по работе с картой, нужно формировать запрос к бд чтобы на карте отобразилось то, что соответствует запросу. Значит входных параметров для запроса 4, в общем вариантов для параметров получается >30, и что, мне теперь написав код, запускать прогу и руками смотреть что все корректно работает+в голове держать и помнить все нюансы и варианты? СЕРЬЕЗНО? Учитывая, что с каждым часом я могу поменять структуру кода и придется заново проверять что все варианты работают. Нет, спасибо, итого пишу тест на строку формирования запроса(31 тест) за несколько млск отработал и показал что все работает, значит код готов, прогу один раз запустила просто полюбоваться. И можно код менять, т к тесты гарантия что все ок + в команде над этой фичой есть ещё разраб. Захотел он поменять мой код, поменял. Я спрашиваю, а тесты ты запускал? Нет, зачем и так все работает? Серьезно?! Запусти-ка! Упали ? Тесты не трогай, код в порядок приведи.
И третий кейс: тестировщик нашел баг, мне что теперь его воспроизводить руками как он? Пошла, тест к текущим написала, ну да красный, ща поправлю, поправила, все тесты запустила, все зелёные, ничего не сломалось, збс! А ещё, иногда от сервера нужно подставить ответ и посмотреть что все ок, тогда мок ответа в тест и расслабляешься, все ок (без всяких чарлизов, дебагеров в рантайме и без сетевых задержек). Ещё я люблю писать тесты контрактов чтобы, например, если появился новый формат даты, добавить его и тесту дать эти форматы - значит зафиксировано ?
Итого: TDD - сохраняет и гарантирует что все работает, сохраняет фичи при правках(регресс) и самое важное для разраба - автоматизирует его время разработки ❤️ это был крик души, потому что дедлайны жёсткие, качество требуют, спасаюсь как могу TDD. Моя любимая цитата: Good developers write good code, and great developers test their good code.
Классная и полезная статья, спасибо!
Практически ко всему, что описано, я приходила через боль и ошибки при изучении и применении в своей разработке. В итоге, приходишь ко всем решениям естественным путем. А после, уже понимаешь этот кайф от написания теста, влюбляешься в это и главное, меняется сам взгляд к разработке и видение написанного кода!
Выявила полезность написания теста для себя, по методу Test Last:
Записала свои ui-тесты, кому интересно, вот ссылочка: https://photos.app.goo.gl/SJbzyb7cKzmNAnow9