動作するきれいなコード: 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 です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
ディープラーニングで簡単に自動テストスクリプトが作れる「Magic Pod」 | 品質向上ブログ
今日は、今話題のAI(人工知能)技術「ディープラーニング」を使い、誰でも簡単にモバイルアプリの画面自動テストスクリプトが作成できるWebサービスのお話です。 ※2017年7月24日よりオープンβ版を提供開始しました！ AppiumやSeleniumのような画面を自動操作するテストツールはとても便利ですが、一方で、こうしたツールを利用していないプロジェクトもたくさんあります。何がツールの導入を妨げているのでしょう? 筆者は、次の2つがとりわけ大きな問題だと考えています。 システムの内部情報をある程度理解しないと、テストスクリプトを書くこと・読むこと・編集することが難しく、それなりのスキルが必要。 テストスクリプトの作成に時間がかかりすぎる。特に、読みやすく変更に強いスクリプトを作成しようとすると、かなりの手間がかかる。 これらの問題を、ディープラーニングによる画像認識を使って解決しようとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
