idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
受け入れテストの自動化 ～ OpenCVの「眼」で捉え、Pythonの「脳」が思考し、Appiumの「指」で動かす - Speaker Deck
2017/02/03 JaSST’17 Tokyo
xUTPの著者から教えてもらった「テストのクラフトマンシップ」 - PoohSunny's blog
はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma
「観点の蒸留」 | Qualab
～腕利きソフトウェアテストコンサルタントが支える優理の事件簿・アドベントカレンダー2016/12/15番外編～ 著者： にし やすはる 「あ～、忙しい忙しい。やることは山ほどあるのに、時間は全然足りないよ。でも早く一人前のQAマンにならなくちゃ。頑張るぞ！」 鳥刈は誰かに聞いて欲しいわけでもなく、しかし独り言にしてはずいぶん大きな声で呟きながら会議室のセッティングをしていた。今日はいつも先輩が受けているコンサルティングを自分一人で受けられる、またとないチャンスだ。勉強ならたくさんしている。本もいくつも読んだ。いろんな勉強会に出席した。SNSでも凄い人たちと友達のように会話できる。その成果をコンサルの人に誉めてもらおう。奥村先輩はいっつも「お前は熱心なんだけどさ、ちょっと空回りなんだよなぁ．．．。」と苦笑するけど、あんな呑んでばっかりの人じゃ分かってくれない。優秀なコンサルなら分かってくれる
UIテスト自動化でSIerのExcelスクショは滅びるのか - てんてんのぶろぐ
先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。 直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。 @backpaper0 さんの当日の資料は以下になります。 Selenideを試行錯誤しながら実践するブラウザ自動テスト 考えるきっかけになったのは、@khasunuma さんの以下ツイート。 @khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。 Selenide導入した
Facebookが2000台の端末をテストする圧巻のモバイルラボを初公開 専用ラックの設計を公開へ
Facebookがフラグメント化したあらゆる環境で自社アプリを問題なく稼働させる目的で運営しているモバイルラボの画像を初公開した。32台の端末を自動稼働させる専用テストラックの設計をオープンソースで公開する計画だ。 米Facebookは7月13日（現地時間）、16億5000万人のユーザーに快適なアプリ体験を提供するためのモバイル端末ラボを初公開した。 Facebookのユーザーは世界中で様々な仕様の端末を使っている。同社は自社アプリを頻繁にアップデートするため、アップデートしてもすべてのユーザーが快適なFacebook体験を享受できるようにすることがラボの目的という。 このラボは同社のオレゴン州プラインビルのデータセンター内にあり、多様なバージョンのOSをインストールした多機種のモバイル端末（iPhoneおよびAndroid端末）2000台以上で各種公式アプリを自動稼働させている。 テスト
TDDを諦める
この記事は，TDDに見切りをつけたある大学教授の経験と，Uncle Bobの反論を要約したものだ。 ソフトウェア工学の大学教授を退官したIan Simmerville氏には，“Software Engineering, 10th edition”を含む数冊の著書がある。同書の第８章はすべてソフトウェアテストに関する内容であり，特に8.2章ではTDDを取り上げている。それらの章で紹介された考え方を何度も引き合いに出しながら，Sommerville氏は先日の記事に，“TDDはソフトウェア工学の大きな進歩です。いくつかのクラスのシステムにおいては，それが有効であることが明らかです。”と述べて，次のような“TDDフレンドリ”なシステムの一覧を紹介している。 階層化アーキテクチャ 合意された成功基準を持ち，それに準拠したテストに基づいて構築されるシステム。 自身のコントロールを越えてシステムと対話す
三角形問題で必要なテストケース数 - A Lifelong Software Tester (生涯一テスター)
Myersは「ソフトウェア・テストの技法」で自己診断テストの採点用チェックリストを示しています。このリストには「xxxのテストケースをもっているか」という13の項目と、「期待出力結果を書いているか」という項目の合計14項目が書かれています。13項目の中には3つの整数値の入力順序を変える(permutation)ものが含まれているので別々に数えると、Myersのチェックリストに合格するには最低22個のテストケースが必要になります。 では、Myersの三角形問題の正解のテストケース数は22個なのでしょうか? ソフトウェアテスト・ヒストリー(ソフトウェアテストPRESS Vol.8)のコラム「三角形問題の正解」で、米国のテスト・コンサルタントRoss Collardの"Exercise: Analyzing the Triangle Problem"を紹介しました。Collardは三角形問題のテ
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015 テスト自動化研究が主催するイベント「システムテスト自動化カンファレンス 2015」が、2015年12月13日に、六本木のヤフー株式会社で開催されました。 午前中に行われたセッション「自動家は見た～自動化の現場の真実～」には関西のコミュニティ「おいしが」のメンバーが登壇。テストを含む開発環境を自動化しようとしてきたエンジニアの、現場での苦悩と苦労をリアルに紹介しています。 その内容を前編、中編、後編の3本の記事にまとめました。この記事は前編です。 自動家（オートメータ）は見た！ 自動化の現場の真実。 「おいしが」の前川博志氏。 おいしがから来ました。グループ名にあんまり深い意味はありません。 自動化で発表される事例は、わりと恵まれた環境で、すごい能力を持って
『クックパッドにおけるテストエンジニアのあり方』参加レポート #cooketn - ブロッコリーのブログ
告知ページ connpass.com スライド 20151021 cookpad talk_test_engineer from Kazuaki MATSUO www.slideshare.net 自己紹介 発表者 松尾和昭 登壇者 和田卓人 今日は開発者視点のテストについて話していきたい 諸橋恭介 開発者だが、Cucumberに興味あり 庄司嘉織 E2Eテストが大嫌い 経歴 テストとクックパッドの働き方 大学時代は暗号系・分散コンピューティング系を研究 教授の影響でQAに興味を持つように ACCESS入社 テストを志向して入社 主にサーバーサイドをやっていた 異動したけど、テストをやり続けたかった クックパッド入社 Cookpadでは品質を向上させるためにテストを行う QAとは何をする役割なのか？ Googleの場合 Test Engineerはマニュアルテストをする人ではない QAの役
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】DevLOVE Test Dayでお話しました
振る舞い駆動開発のアンチパターン
振る舞い駆動開発の体験