※この記事は「Autifyアドベントカレンダー2021」の記事です。 Autify for Web には「ロケータ」という機能があります。 AutifyのメンテナンスAIは、ページ内に変化があっても継続的に要素を選択できるよう、要素が持つ複数の特徴から総合的な判断を行い、前回と最も一致度の高い要素を見つけ出します。 その一方で、まれにテストの対象によってはAutifyのAIに頼らずに特定の要素を選択し、クリックや入力、アサーションを行いたいケースが発生する場合もあります。 (略) このような場合には「ロケータ」機能を使いましょう。 ※「Autify for Web Help Center」から抜粋 Autify でシナリオにロケータを追加してCSSセレクターを指定しようと試みた際に、どのようなCSSセレクターを指定したら良いのかわからない場合は、Google Chrome デベロッパーツー
Dataform CLI からテストコードを実行して、BigQuery UDF のユニットテストを実施してみる。 こんにちは、みかみです。 犬×3と暮らしていると、なでられていない誰かがおこるかすねるかし始めるので、腕が3本欲しいです。 やりたいこと BigQuery UDF のユニットテストを実施したい GitHub `bigquery-utils` リポジトリで公開されてる、Dataform の BigQuery UDF ユニットテストを実行してみたい bigquery-utils/dataform/examples/dataform_udf_unit_test ｜ GitHub 前提 本エントリでは、Cloud Shell から Dataform CLI を実行しています。 また、Dataform や BigQuery などの操作に必要な API の有効化と権限付与は完了しています。
はじめに Playwright を使うことで比較的簡単に E2E テストを実装することができます。しかし、通常テストコードは実装したら終わりということではなく、継続的にメンテナンス（保守）が必要になります。その際に保守しやすいように実装するため、Playwright の公式ドキュメントに記載されているベストプラクティスの中で参考になりそうな部分を確認しておこうと思います。 テストの独立性を高める 可能な限りテスト間の依存が無いようにして、テストを分離すると良いというプラクティスです。各テストが独立していることで、 １つのテストが失敗しても他のテストに影響しない テストの順序を考慮する必要がない テストをシンプルに保つことができる あたりのメリットがあるかと思います。また、特定の処理（例えば特定の URL に遷移する処理）の繰り返し実装するのを避けるために before and after
テスト仕様書を作成する時に下記の項目をチェックしておく。 ０件テストは行ったか。 エラー時は適切な処理（中断、スキップ等）を行っているか。 処理件数等、ログは出力されるようになっているか。 無駄なログは出力されていないか。 ジョブの処理順序は正しいか。 パフォーマンスに問題はないか。
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した結合テスト計画書のテンプレートをご提供しております。 テスト計画を立てたことがないという方もいらっしゃるかもしれませんが、この計画は品質に直結する内容となるため、なんとなくテンプレートに沿って、書いていけばよいと考えているかたは、要注意です。 非常に重要な作業となりますので、計画書の各章に記載すべき内容や何のための項目なのかをしっかり理解してから記述するようにしてください。 また、テスト計画書については、外部結合テスト以降の工程では、自社だけではなく他社も含めて検討するべき事項やお客様の運用を考慮した運用テストの内容なども盛り込んでいく必要があるため、しっかりとコミュニケーションをとって、抜けもれなく計画書に盛り込むようにしましょう。 結合テスト計画書（章立て） 今回は、結合
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。 サンプルダウンロード サンプルのダウンロードはこちらから。 作成してみる では、作成していきましょう。 作成方針・ポイント 内容としては、まずテストのサマリを報告し、必要に応じてそれぞれのテストの詳細やエビデンスを記載するのが一般的かなと思います。 構成（目次）を考える 今回は下記のような項目を記述してみました。 テスト結果 全体サマリ 機能テスト：単体テスト結果サマリ 機能テスト：結合テスト結果サマリ 非機能テスト：全体サマリ エビデンス（各テスト） 記述例（サンプルから抜粋） では、サンプルの主要なページについて少し解説したいと思います。 表紙 特に補足はありません。 目次 こんな感じ。 テスト結果 全体サマリ まず、テスト計画で実施を定義したテスト全体の結果をサマリ
ファイルからインポートはまだ未実施なので今後追記する。 その他設定 テストスイートに対して複数のテストケースを作成した場合、Repository画面でテストケースの順番を変更することが可能。 順番を変更したいテストケースをドラッグ&ドロップで移動が可能 3.2. テスト計画の作成 テストスイート及び、テストケースが正常に作成できたあとはテスト計画を作成する。 Test Plansをクリック後、Create new test planをクリック。 Plan details(計画詳細) Title：テスト計画のタイトルを設定 Description：テスト計画の説明を設定 リストや太字、イタリック、コード表記を行うことが可能 Choose cases(ケースの選択) テスト計画に追加するテストケースを選択する。 左のテストスイートにチェックを入れた場合はテストスイート内のすべてのテストケースに
ペアワイズ法を使うことで、効率的にテストケースを絞り込めることがわかったかと思います。 --- 2019/10/31 追記 --- どうしてテストケースを絞り込んでも大丈夫なのか？という意見がSNSやはてブのコメントで見受けられたので、フォローアップエントリを書きました。こちらも合わせてご覧ください。 ペアワイズ法は本当に有効なのか？組み合わせテスト技法と上手に付き合う方法 ｜ DevelopersIO ペアワイズ法を支えるツール「PICT」 ペアワイズ法が有効なことはわかりましたが、この組み合わせをどうやって作れば良いでしょうか？条件の数が少なければ前述のように手作業でもやれないことはありませんが、現実の問題はもっと複雑ですので、到底無理でしょう。 そこで役に立つのが、ペアワイズ法のテストケースを生成してくれるツール「PICT」です。 microsoft/pict: Pairwise I
きっかけ あるとき、○○ちゃんに、「SQLの単体テストケースってどうやって考えればよいの？」と問われ、「うっ」となりました。 SQLの単体テストケースの考え方 そんなことも答えられないのに、「網羅的なテストぉー！」だとか、「カバレッジはどのくらいを狙っているの？」などと偉そうに言ってきましたが、なんとなくを整理して、改めて理解してみます。 どこから手を付けるか？ テスト対象はDDLなのか、DMLなのか。日常よく使うSELECT文を単体テストケースの考え方の対象とします。SELECT文を概念的に(内部実装は置いといて)、「1.構成する要素(○○句)と実行順序」、「2.その要素の挙動」に整理、理解して、「3.単体テストケース」を考えます。 調査 書籍「プログラマのためのSQL 第4版 すべてを知り尽くしたいあなたに」をメインにSELECT文の実行順序と挙動を調査。 SELECT文の挙動調査元ネ
こんにちは。EGの深町です。 EGの中には、「プログラム書くのは大好きだけど、テストは得意ではない」 という方が多くいるのではないでしょうか？ 今回は、そんな人のためにテストパターンの洗い出しだけでも簡単に・早く・正確にできる手法を紹介します。 複数の入力条件の組み合わせを列挙し、それぞれの場合にどのような動作をするのかまとめた表です。 何が良いの？ 慣れると作成が楽になり、かつパターン漏れがなくなる 完成したテストケースを見てパターンが網羅できていることがわかりやすい デシジョンテーブルの構成 デシジョンテーブルは以下のような要素で構成されています。
概要 試験工程をスプレッドシートで管理していたがそろそろ脱却したいと思ったので色々探してみました。 すると、同じことを考えている先駆者さんがいらっしゃったので参考にさせていただきました！ 導入に至った経緯 QA体制が未成熟 3名までなら無料で利用できる テスト計画・テスト結果をエクスポートできる 入力項目が整理されているので試験表の質を一定にできる 自動化したテストケースを管理できる 手動テストと自動テストの結果を併せて一覧できる APIにより自動テストの実行結果を自動的に反映することができる etc これは、中々良いツールなんじゃないか！？ ということで導入してみました 実際の導入方法を説明していきます 事前準備 以下からサインアップしてください サインアップ完了後、ダッシュボードに遷移した状態からスタートとします それぞれの設定方法は以下を参照してください 新しいプロジェクトを作成 プ
最近、golangでプログラムを書く機会が増えてきた。golangでTDDをする場合、標準のtestingパッケージを使うのが一般的なようだ。ただし、標準パッケージだけだとちょっとテストが書きづらいので、stretchr/testifyを使っている人も多いと思う。 関数のテストをしたいときは標準パッケージなりtestifyを使うなりで良いのだけど、振る舞いをテストしたい、つまりBDDをしたいなーと思った時にちょっと調べらたらGinkgoというのが良さ気だったので、ちょっと試してみる。 Ginkgoとは 表現力があって包括的なテストを効率良く書くためのBDDスタイルのテストフレームワーク。GomegaというMatcherライブラリと併用すると良い感じらしいけど、単体でも充分使えるらしい。 今回はドキュメントに従い、GinkgoだけでなくGomegaもインストールした。 インストール go g
Firestoreのセキュリティルールをテストする方法としてコンソールから使えるシミュレーターが以前からありましたが、今回発表されたのはローカルで実行できるエミュレーターです。 これを使えば、CI上でセキュリティルールのテストをルールをデプロイせずにできます。 試した環境は firebase-tools 6.0.1です。 最初は6.0.0で試してみたのですがどうやら日本語環境ではエミュレータがエラーになるようで6.0.1で一旦デフォルトで英語になるように修正されました。 ローカルエミュレーターローカルエミュレーターはFirebase Summit 2018で発表された手元の環境でFirebaseのデータベースであるRealtimeとFirestoreのセキュリティルールをテストすることができます。 今までセキュリティルールをテストしようと思うとコンソール上のシミュレーターで手動でテストをす
はじめに こんにちは。NIKKOエンジニアのS.TKです。 皆さん、テストはしていますか？最近の開発手法であれば、ほぼ確実にテストが考慮されているので嫌でもしていますよね。ただ、テストって実は結構難しかったりします。特にテストコードを書くとなると、プロダクトコードの設計によってはかなり苦労させられます。 そこで、今回はユニットテスト（単体テスト）に焦点を当て、テストコードを楽に書くためにMock（モック）を利用する方法をご紹介します。私はGMO MARS DMPの開発・運用を担当していますが、今回ご紹介する内容は普段の業務で実践している内容になります。 言語はJavaで、テストフレームワークはJUnitを使うことにします。 ユニットテストを書こう まず最初に、ユニットテストを書くことの意義について再確認してみたいと思います。今更感がすごいですが、ちょっとだけお付き合いください。 一番期待さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
