長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています(経歴)。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
Mercari Advent Calendar 2019も、この記事を入れてあと3個となりました。最後まで読んでくださいね。 23日目はAutomation&QAグループで、Webのテスト自動化を行っている@AHA_oretamaがお送りします。 今回はWebの自動テストについて、この1年やってきたことを振り返ってみようかと思います。 Webのリアーキテクチャ 現在、Webではリアーキテクチャを進めています。 進め方としては既存のモノリシックなWebアプリケーションを残したまま、パス(例えばトップ /jp/ や検索ページ /jp/search/ )ごとに新しいWebアプリケーションにマイグレーションする方法をとっています。 影響範囲を小さくしつつその範囲の中でチャレンジが行えることがこの方法の利点です。 詳しくは去年のMercari Tech Confの資料をご覧ください。 speaker
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです(これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE)。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
はじめに 10分でわかるブラウザ処理自動化!初心者向けSelenium IDE入門ガイドでSelenium IDEを使い始めるためのガイドを書きました。 そこでは、条件分岐やループ処理など一部のコマンドについての解説を書きました。 本記事では v3.12.0(2019/09時点での最新)のコマンド全部をサンプルコード を書きながら解説しています。 今回作成したサンプルコードはGithubに置いています。 https://github.com/RustyNail/SeleniumIDEDemo の SeleniumIDEcommand.sideをインポートすれば実行できます。 Selenium IDEのコマンド一覧 新しいSelenium IDEがでた当初はコマンドが少なくて「今までやっていたことができなくなってる?使えないのでは?」とちょっと不安でしたが、今では随分コマンドが増え充実してき
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、E2EテストをSelenium WebdriverからCypress.ioに移行した話をしたいと思います。 一休のE2Eテスト事情 あれから、数年が経過して、、、 どうしてこうなった??? SeleniumではSPAへの対応が難しくなってきた なんでもかんでもSeleniumで頑張ろうとした弊害 いざリプレイスへ・リプレイスをする上で気をつけたこと 開発者フレンドリー 安定性 然るべきレイヤーでテストする(何でもかんでもブラウザテストにしない) 技術選定 Cypress.io とは? Cypress.io のいいところ セットアップが楽 テストを書くことだけに集中できる CI連携が楽 Cypress.io の頑張って欲しいところ その他、移行に関しての細かい話 重複テストケースの排除 Page Objec
こんにちは!dely でフロントエンドの開発をしています @all__user です。 今回は kurashiru のフロントエンド開発に導入されたビジュアルリグレッションテストについてご紹介したいと思います。 【反応を多くいただいた点について記事の最後に追記しました】 目次 目次 ビジュアルリグレッションテストとは 導入の背景 フロントエンドのテスト? SPA移行前後の比較 ツール reg-suit Loki Wraith BacksGitHub + CodeBuild + BacksGoogle スプレッドシートで管理 結果を S3 にアップロードして Slack に通知 まとめ 【追記】 運用が大変ではないか? 1pxの違いにそこまで工数かける? 広告が差し込まれたり変わっただけでテストが壊れるのでは? ビジュ
この記事は12/21 クローラー/Web スクレイピングの記事です。 最近、自社システムのシナリオテストの実施方法周りの調査をやっているのですが、
Selenium を使って、ブラウザの操作を自動化するときに、どのリンクをクリックするか、どのフォームに値を入力するかを指定する必要があります。 画面上のどの要素を操作するかを指定するための情報をSeleniumではlocatorといいます。Seleniumでは、ブラウザ(厳密にいうとSelenium Server)とクライアント間の仕様としてJSON Wire Protocolが定められており、利用できるlocatorもそれに従います。 要素を探索する場合 /session/:sessionId/element に、locatorを含むJSONをPOSTするのですが、その locator として、class name、xpath と様々なものが利用できます。 様々なものが利
CircleCI 2.0 を使い倒そうというタイトルでトークしたものです
Web技術の標準を策定するWorld Wide Web Consortium(W3C)のBrowser Testing and Toolsワーキンググループは、「WebDriver」が6月5日付けで勧告に到達したことを発表しました。 WebDriverは、Webブラウザを外部から操作することを可能にし、Webアプリケーションのテストなどの自動化を実現する技術です。 主要なWebブラウザにはすでにこのWebDriverの機能が用意されています。Seleniumに代表されるWebブラウザ自動化ライブラリを利用することで、WebDriverを用いてWebアプリケーションのUIテストなどを自動化することが可能です。 SeleniumからW3Cへ もともとWebブラウザには外部から操作を行う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く