動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
テストを自動化するのをやめ、自動テストを作ろう
July Tech Festa 2020 TrackB https://jtf2020.peatix.com/
自動テストに限界を感じた私がなぜ形式手法に魅了されたのか - 若くない何かの悩み
長らく自動テストとテスト容易設計を生業としてきましたが、最近は色々な限界を感じて形式手法に取り組んでいます。 この記事では、既存の自動テストのどこに限界を感じてなぜ形式手法が必要なのかの私見を説明します。なお、私もまだ完全理解には程遠いため間違いがあるかもしれません。ご指摘やご意見はぜひ Kuniwak までいただけると嬉しいです。 著者について プログラマです。開発プロセスをよくするための自発的な自動テストを支援する仕事をしています（経歴）。ここ一年は R&D 的な位置付けで形式手法もやっています。 自動テストの限界 自動テストとは 私がここ数年悩んでいたことは、iOS や Web アプリなどのモデル層のバグを従来の自動テストで見つけられないことでした。ただ、いきなりこの話で始めると理解しづらいと思うので簡単な例から出発します。 この記事でいう自動テストとは以下のようにテスト対象を実際に
なぜE2Eテストでidを使うべきではないのか ｜Autifyブログ
こんにちは。AutifyのSET(Software Engineer in Test) 、末村(@tsueeemura)です。 皆さん、E2Eテストしてますか？以前はほぼSelenium一択みたいなところがありましたが、最近はPuppeteerやCypress、TestCafeなどいろいろなフレームワークがあり、ついつい目移りしてしまいますね！ さて、どのフレームワークを使うにせよ、E2Eテストを書く上で共通で意識しないといけない重要なファクターがいくつか存在します。 その一つが ロケータ です。操作や検証の対象となる要素を指定するためのキーのことです。 ロケータにはCSSセレクタやXPathが利用でき、idやclass、name といった属性を利用するのが一般的です。 今回はこのロケータについての話を書こうと思います。 ロケータとは 要素を一意に指定できさえすればロケータに使うものは何で
『テスト駆動開発』を読んで - まめめも
テスト駆動開発posted with amazlet at 17.10.12Kent Beck オーム社 売り上げランキング: 563 Amazon.co.jpで詳細を見る オーム社さまから電子書籍を贈本いただきました。ありがとうございます。 本書はテスト駆動開発（TDD）の原典で、たいへん有名な本です。が、自分は食わず嫌いで読んだことがありませんでした。 というか、TDD 自体もちゃんと理解したことがありませんでした。なんだろう、なんか怖かった。 そんな自分が今回この本をいまさら読んでみたら、なるほどこれは確かにいい本でした。なんというか、語りたくなる感じ。ということでご紹介。 紹介 テストとプログラムを交互に書いていく開発方法 TDD を、例題を用いて実演していく本です。 TDD というと「プログラムより先にテストを書く」というところだけ強調されますが、正直それではよくわからないのでし
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する| PLAID engineer blog
CircleCI上で、BrowserStackを利用したマルチブラウザJavascript Test,Selenium Test を実現している方法についてご紹介します。Selenium webdriver, CircleCI, BrowserStack
小さく始める JavaScript のテスト - Qiita
書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io
ABテストで「女の子クリエイティブ」の神話崩壊。まったく出会えないチャットアプリ「ひまチャット」が教える、意外だったABテスト事例4 | アプリマーケティング研究所
ABテストで「女の子クリエイティブ」の神話崩壊。まったく出会えないチャットアプリ「ひまチャット」が教える、意外だったABテスト事例4 まったく出会えないチャットアプリ「ひまチャット」さんにお話を伺いました。 ※ALTR THINK株式会社 CEO 森口拓也さん（左）、森岡さん（右） 「ひまチャット」について 「ひまチャット」について教えてください。 森口： 「ひまチャット」は出会わない系のチャットアプリです。「ども！」というボタンから、日本中のいろんなヒマな人たち（匿名）に話しかけて、ヒマつぶしをすることが出来ます。 いまどのくらいのユーザーがつかっていますか？ 森口： いまのところ、登録ユーザー（≒ダウンロード数）が約100万人、MAUがざっくり20万人です。男女比としては半々くらいですね。 メッセージ数でいうと、全体で月に6,000万メッセージ（累計でいうと10億メッセージ）くらい、や
テスト(コード)レビューの方針 書きなぐり版 - うさぎ組
牛尾さんのブログをはてブったら、「じゃぁ、その手本を見せろやゴルァ」と言われたので書きました。雑です。すみません。 元記事 「自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である」 Blogs - Live DevOps in Japan! - Site Home - TechNet Blogs 僕のコメント 「だいたい同じ意見だけど、これで単体テスト仕様書がいらない理由にはならないかなぁと思った。テストレビューの成長方法について書かれていないしなぁ。出来る人いない現場は諦めろってことかな？」 はてなブックマーク - kyon_mm のブックマーク - 2016年1月25日 牛尾さんのコメント「どっかに書いてありますか？もしあったら記事にはります。」 僕のコメント「書いていません！」 僕のコメント「書きました！」 僕の主張 本記事は僕の実験結果（経過報告）であり、
Travis CI上でPHPアプリのWebベースのテストを自動化する | Engine Yard Blog JP
PHPなどのさまざまな言語のオープンソースプロジェクトのCI環境として利用されているTravis CIでWebベースのテストを実行してみました。 通常は純粋なコードベースのユニットテストを実行する事が多いかと思いますが、CMSやEコマースエンジンなどオープンソースで配布し、インストールして使うようなソフトウェアではWebブラウザベースでの機能テストを自動化したいというニーズがあるでしょう。Travis CIにはfirefoxがインストールされておりブラウザベースのテストが出来る事は知っていたのですが、今回年末年始の宿題的にテストを実行する為の設定をひと通り行ってみました。 説明を抜きにして動作が見たい方はGitHubとTravis CIへどうぞ yandod/candycane https://github.com/yandod/candycane candycane on Trav
GoutteとPHPUnitでレガシーなPHPアプリケーションをテストする
Goutte という PHP 製の Web スクレイピングライブラリを使って Web ブラウザを操作するテストを書いてみたのでサンプルを紹介します。 Goutte とは、Symfony 開発者の Fabian が手がけるライブラリです。Symfony コンポーネントの BrowserKit, CssSelector, DomCrawler ほか Guzzle HTTP というライブラリを使っていて、PHPUnit と組み合わせることで Symfony のファンクショナルテストと同じ感覚でブラウザテストを書くことができます。 レガシーな PHP アプリケーションのテストに悩んでいる方は選択肢のひとつとして参考にしてみてください。サンプルは karakaram/goutte-sample - GitHub に置いておきます。 動作確認環境 PHP 5.6PHPUnit 4.7Goutte 2.
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
自動テストの誤解とアンチパターン in 楽天 Tech Talk
