チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
新しいスタイル VS テスト駆動開発「Limbo on the Cheap」のなかで、新しいプログラミングワークフローを考案しました。テストが成功するたびにコードをコミットする「test && commit」というものです。Oddmund Strømme（私が最初に出会った、私と同じく対称性に取り憑かれたプログラマ）が、テストが失敗したらコードをリバートすべきだと提案してくれました。私はこのアイデアが大嫌いだったので、とりあえず試してみることにしました。 そのコマンドは「test && commit || revert」になります。テストが失敗したら、コードはテストが最後にパスしたときの状態に戻るのです。 私は「test && commit || revert」に賛同はしていませんし、そのトレードオフについて説明するつもりもありません。動作はするでしょうけど、あんまりうまくいかないんじゃな
2019/1/26 に
"テストが辛いを解決するテスト駆動開発のアプローチ" at
Oct 31, 2018 at
Deleted art技術で実際にコストが大きく異なるなと気づいて書いた次第です
こんにちは、メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の 根本 征 です。 私は普段、テスト自動化・CI / CD改善・その他社内の生産性を上げるための自動化を行っています。 今回はiOSのUIテスト自動化について、最近の改善をまとめてご紹介したいと思います。 ざっくり言うと HTMLレポートに出力し、失敗原因を見やすくするようにしました リトライ実行するためのfastlaneプラグインを作りました テスト実行環境をJenkinsからCircleCIに移行しました Slack Commandを使って、簡単に実行できるようにしました これまでのiOSのUIテスト自動化 AQA(旧QA-SET)では去年から、JP版アプリ(iOS / Android)のUIテスト自動化に取り組んでいます。 去年のMercari Tech Conf 2017では、
テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering By Hiroyuki Ito | 2018.07.09 2021.01.08LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。 はじめに こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。 2018年6月27日（水）に、電気通信大学の西 康晴さん（以下「にしさん」と表記）をお招きして、「
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ブラウザには外部から操作を行う
こんにちは、テストエンジニアリングチームの園です。 先日、『Cybozu Meetup テスト自動化 ～失敗から学ぶ、テスト自動化導入で大切なこと～』を開催しました。 技術的な内容よりも導入手法に重点を置いたお話を予定していたため、参加枠が埋まるか不安でしたが、参加募集開始から予想を裏切り、最終的に参加枠を大きく超える130名の方からお申し込みをいただきました！ テスト自動化がトピックとして扱われるようになって久しいですが、まだまだ注目される話題であり、導入に悩まれている方も多いのだと改めて認識いたしました。 cybozu.connpass.com 本エントリでは、Meetupで話した内容のまとめと、話し足りなかったことを補足させていただこうと思います。 テストエンジニアリングチームのご紹介 このセッションでは、サイボウズのテストエンジニアリングチーム(以下、TE)の紹介と、活動内容の紹介
こんにちは。ショッピングアプリ「BASE」のiOSアプリを担当している竜口です。 背景：あの改修の効果測定用のログ、送られてる？ ショッピングアプリ「BASE」内で、施策の効果測定やKPIの経過観察で様々なログを使用しているのですが、細かい改修などで特定のログが送られない事象があり、効果測定が出来ずに多部署の作業が止まるということがありました。 そこでアプリ（今回はiOSのみ）でログが正しく送られていることを保証するために、ログのテストをするようにしました。 全体の流れ 次のことをしました。 EarlGreyでUITestを実装 テストの中で送られるログをMockに保持 テスト完了後、Mockにあるログの有無を確認 テストをCircleCIで自動化 これで改修によるログの影響を保証出来るようになります！！ 1. EarlGreyでUITestを実装 EarlGrey Referenceは、
■ モチベーションサービスを継続的に改善していく上で、バグを避けることはできません。そこで、バグが混入した時にそれにいち早く気付ける仕組みが必要になります。 Webサービス開発ではふつう、ユニットテストを書きます。一連のページ遷移（動線）をチェックするE2Eテストを書くこともあります。これらを用いることで、バグに簡単に気づくことが出来ます。 しかし、フロントエンドのエラーには微妙なページデザインの崩れなども含まれます。この場合、単にDOMの存在やページ遷移の可否をチェックするだけでは不十分です。 このようなエラーチェックに関しては、2018年になった今も、人が直接見なければ良し悪しがわかりづらいというやっかいな側面があります。かといって、主要なページを毎日手でチェックするのは非常に手間がかかってしまいます。 ■ 自動でページのスクリーンショットを取るそこで、ChromeをNodeから操作す
2018/02/13追記：「サンプル用のドメインを使おう」の説明に “.example” と “.test” の使い分けについて追記しました。 Web システム開発時のテストデータを作成する時、また各種ドキュメントを書いている時など、サンプルの URL を使う場面は多いと思いますが、その時に適当なドメイン名を使うのはやめましょう、という話です。 知っている方には当たり前レベルの話ですが、意外と IT 企業のシステム開発現場等でも普通に見かけることがまだまだありますので・・・。 よく見かける例 例えば、こんなドメインの URL で開発中システムのテストデータを作っていたり、仕様書に説明が書かれていたりする場面をよく見かけませんか？ test.com aaa.com abc.com sample.com dummy.com hoge.com でも、これらのドメインって存在していて、また実際に利
Webシステムの自動テストを始めたい方を対象に、自動テストの考え方やフレームワークを解説する書籍です。テストのピラミッドやユーザーインターフェイステストの概念など、基礎的な事柄から、レガシーシステムへのUIテストの追加、RESTfulなWebサービスのテスト、ブラウザ上のJavaScriptの挙動をユニットテストでテストする方法など、実践的な事柄までを豊富なイラストとサンプルを使って分かりやすく解説します。さらにテストファーストやモックの活用法、テスターに向けた自動テストのためのプログラミング基礎知識なども詳述。自動テストを書くためのノウハウを網羅した本書は、自動テストをマスターしたいエンジニア必携の一冊です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では
■ 初めての自動テストを読んだ Jonathan RRails やその他のフレームワークによる開発の経験があって、xUnit, xSpec でテストを書いて、ファイルがでかくなってきたから分割して、selenium で E2E テストで遅くてつらくてじゃあテスト戦略どうするというのを考えて、mock と stub 使ってたら実リクエストじゃないと再現しない～...というようなアレコレに「わかるー」という感想がある人は読む必要がありません。 逆に今並べたような内容でイメージできない内容が含まれている人がいたら買って読んでおいた方が良いでしょう。主にテスターやディレクター、ジュニアデベロッパー向けの本としては、テストに関することが網羅的に書かれていたので良い本と思います。 初めての自動テスト ―Webシステムのための
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
