こんにちは。Autifyの品質エバンジェリストの末村です。 もう5年前にもなりますが、なぜE2Eテストでidを使うべきではないのかという記事を書きました。この記事はありがたいことに長い間閲覧されており、弊社ブログの人気コンテンツの一つとなっています。 一方で、5年という歳月はソフトウェア開発のトレンドを変化させるには十分すぎるほどに長いです。テストツールの面では Playwright が新たな選択肢として加わった他、 testing-library によるアクセシビリティ属性を用いた要素探索が新たなベストプラクティスとして登場しています。 この記事では、E2Eテストにおける要素探索の考え方の変遷をおさらいしつつ、ベストプラクティスについて説明します。 要素選択の考え方まずは、要素選択の考え方についておさらいしておきましょう。要素選択とは、読んで字の如く、Webページ内の特定の要素を探すこと
テストの学習へようこそ！ コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
なぜ執筆プロジェクトを立ち上げたのか？ 2020年の年末から年明けに開催された技術書典10で「はじめてのJest入門」を執筆しました。私自身はIT業界に約10年いますが、受託案件やR&Dのようなプロジェクトに参加することが多く、テストについての経験があまり得られないまま過ごしてきました。そんな中で社内のメンター＆メンティープログラムでTDD（Test-Driven Development：テスト駆動開発）について学ぶ機会があり、セッションを通して学んだことを記憶に残す意味でも、この本を書くことに至りました。しかし、前回の書籍ではTDDやテスト自体の概念についてはあまり触れず、セッションで利用したJestの基本的な機能や使い方についてフォーカスしました。 前回の技術書典10のイベントを通じて、同じような悩みや課題感を持った方多くがいることを知ることができました。JavaScriptは元々フロ
ROI(t) = Δ手動テストに対するテスト自動化の利益 / Δ手動テスト対するテスト自動化のコスト = ΔB(t) / ΔC(t) ΔB(t) = Σ(自動テストによる固定費の削減分)(t) + Σ(n2回手動テストを実施した場合の変動費)(t) - Σ(n1回自動テストを実施した場合の変動費)(t) ΔC(t) = Σ(自動テストによる固定費の増加分)(t) + Σ(自動テストの開発費) - Σ(手動テストの開発費) + Σ(自動テストのメンテナンスコスト) (n1/N) n1 = 自動テストの実行回数 n2 = 手動テストの実行回数 N = メンテナンスが必要になるまでの自動テストの平均実行回数 今回は、この各要素を順に見ていきましょう。 自動テストによる固定費の削減分 「自動テストによる固定費の削減分」から説明します。まず、この「固定費」とは、「テスト計画」「テスト設計」など、「テ
アプリケーションの画面に対してボタンを押したり入力を行い、正しい結果や答えが返ってくるか？ ユーザーインターフェイスを含むテストコードの開発は一般に手間がかかり面倒であり、テスト用のライブラリやフレームワークが欠かせません。 Googleは、Android用のUIテスト自動化のためのフレームワーク「Espresso」をテクノロジープレビューとして公開しました。 Espresso - android-test-kit - a fun little Android UI test API - Testing Tools For Android - Google Project Hosting EspressoはこれまでGoogle社内で、Google DriveやGoogle Maps、Google+など30種類のアプリケーションのテスト自動化に使われてきました。 特徴は、軽量でシンプルな記述
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
ドキュメントベースの単体テスト ソフトウェア開発では、テストケースをExcel等で管理し、テストをテストフェイズで実施する方式（以下、ドキュメントベースの単体テスト）が行われてきました。 ドキュメントベースの単体テストでは、テストフェーズが明確に切られています。テストフェーズでは、テスト担当者がテストを実施し、結果をドキュメントに記録します。必要に応じてエビデンスも残すでしょう。もし、テストが失敗したならば、不具合管理票（バグ票）を起票します。そして、不具合の原因を分析し、仕様書やソースコードを修正します。不具合が修正されたならば、もう一度テストを実行し、不具合がなくなるまでこのサイクルを繰り返し、品質を高めていきます。 このようなドキュメントベースの単体テストは、機能や画面を対象としています。そして、ほとんどの場合は品質保証を目的としています。テスト件数や不具合件数、不具合の発生原因や修
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
あらすじ Androidのテストを自動化したいので、テストツールの選定をしてみたが、昔の記事がヒットする事が多く、何を使えばいいのかよくわからん。 とはいっても、明確に「どんなテストがしたい」という方針もなく、とっかかりとしてどんなツールがあってどのくらい盛り上がってるのかが知りたかった。 環境 Windows 7 AndroidDeveloperTools Build: v21.1.0-569685 とりあえず Win メインで。 とっかかり ロジックまわりのテスト ロジック的なものは、 JUnit 拡張の TestCase クラスを使えば何とか書けそうというのはわかった。 Androidアプリ開発テスト入門（2）：Android SDKでビジネスロジックのテストを自動化するには (1/3) - ＠IT 2011 年の記事だけど、 JUnit で書くという大前提は崩れていないはず…。 画
1. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 「モデル検査」のススメ （ゲームシナリオ進行編） 2013年8月21日 国立情報学研究所 GRACEセンター/先端ICTセンター 長久勝 mailto : [email protected] Twitter : @mnagaku 2. Copyright (C) 2013 National Institute of Informatics, All rights reserved. 2 がいよう 仕様の通りに正しく振る舞うソフトウェアを開発するのは 極めて困難であるが、ソフトウェア工学において検討され てきた「モデル検査」は、ソフトウェアをモデル化し、その 振る舞いを網羅的に検証することで、仕様の通りに正しく 振る舞うソフトウェアの開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
