E2Eテストコードのメンテナンス性に立ち向かう - Qiita
はじめに E2Eテストコードを書くにあたって、一番の心配事は テストが壊れる ことでしょう。 アプリ側の変更に伴いテストをすべて書き直すことを恐れるQAエンジニアは多いと思います。 例えば 機能はまったく変わってないのに、デザインリニューアルでテスト全部書き直しだ〜〜〜！ みたいなやつですね。 ここでは、自分が実際に「メンテしやすい」テストコードを試行錯誤する過程で得られた気づきをまとめていきたいと思います。 なお、自分の活動範囲は主にWebアプリのテストですので、基本Webアプリの話題になりますが、「いやネイティブアプリはこうやねん」みたいなツッコミもお待ちしております。 また、文中に登場するサンプルコードは CodeceptJSで記述しています。 使ったことがない方は気合で読んでください。 メンテしやすい vs メンテナンスフリー はじめに強くお伝えしておきたいことは、メンテナンスしや
Google Maps APIで50万以上使っていた話 - Qiita
この記事は Wano Group Advent Calendar 2019 の7目の記事となります。 アドベントカレンダーに「なにか」書くといって7日を予約していたんですが、特にネタを考えてなかったら、前日にネタが降ってきたという話です。 ※後日談を追加しました(2019/12/15) 始まりは経理担当者のSさんの指摘 ちょうど昨日(12/06)のことです。経理担当者のSさんに「Google Cloud Service から38,653円がクレジットカードの明細にあるのですが、証憑がないんですが…」と相談を受けました。月初は会社に対する請求の確認作業があり、請求書がない引き落としとかは問題になりますので、たまに確認されることがあります。 新しくサービスを開始する際に、AWSやGCPとか有料サービスのアカウントを新しく作る必要があったりすると、そんなことが起きたりします。要は経理担当にメール
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
