2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
フロントエンドのテストは皆のためのもの | POSTD
テストとは人によって反応が分かれるものの1つであり、大喜びする人もいれば、見ないようにして去ろうとする人もいます。あなたがどちらの側であるにせよ、ここではフロントエンドのテストは皆のためのものであるということを説明します。実際、テストには多くの種類があり、それがテストに対して初めに恐れや混乱を感じる一因なのかもしれません。 この記事では、特に有名で広く利用されている種類のテストを扱います。なかには目新しいものはないと感じる読者の方もいらっしゃるかもしれませんが、少なくとも復習にはなるでしょう。どちらにせよ、筆者の目標は、この記事を通じて世の中のさまざまな種類のテストについて理解を深めてもらうことです。ここではユニットテスト、統合テスト、アクセシビリティテスト、ビジュアルリグレッションテストなどを一緒に見ていきます。 さらに、Mocha、Jest、Puppeteer、Cypressなど、各種
ローコードテスト自動化ツールの mabl がすごい
というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基本的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ
【Flutter】3種類のテストをGithub Actionsで自動化する
本記事でわかること Flutterの3種類のテストの実装方法Flutterの3種類のテストをGithub Actionsで自動化する方法 Flutterのテストはユニット・ウィジェット・インテグレーションの3種類 Flutterには下表に示すような3種類のテストがあり、内容は以下のようになっています。 テストの種類内容ユニットテストFlutterの機能ではないDartオンリーな部分のテストを行う。 UIとは切り離された部分のテストである。ウィジェットテストFlutterのWidgetを操作しながらテストを行う。 ユニットテストのWidget版とイメージしてもらうと分かりやすい。インテグレーションテストアプリ全体の統合的なテストを行う。他のテストとは異なり、 実際にエミュレータを立ち上げ、事前に設定しておいた操作が行われる。 本記事では、これらのテストを実装し、Github Actionsで
【Flutter】Widget テストの「あれ、これどうやるんだろう？」集 - Qiita
この記事は Flutter Advent Calendar 2019 3日目 の記事です。 この記事では、自分が実際のアプリのコードで Widget テストをいろいろと書いていて「あれ、これどうやってテストすればいいんだろう？」とつまづいた部分を箇条書きで紹介したいと思います。 なるべく参考にしたサイトを載せているので、この記事はそれぞれの項目の入り口として、リンク先でより詳しく調べる感じで読んでいただけたらと思います。 Widget テストの基本 Widget テストの基本については、まずは公式ドキュメントをご参照ください。 WidgetTester の基本的な使い方や find による Widget の取得方法、テキスト入力やタップのエミュレート方法が簡潔に書かれています。 An introduction to widget testing | Flutter 本文 ↑ の公式ドキュメ
FlutterのWidgetTestで待ち(疑似スリープ)を入れる - Qiita
環境 訳あって最新版を使っていません(macをCatalinaにアップデートできない==Xcodeの最新版を入れられないので)。 従って、バージョン違いによる不動作などあるかも知れません。お気づきの点があったら是非コメント下さい。 ※本稿は特に、Flutterテストパッケージの今後のアップデートにおいて、動作・仕様が変わる可能性があります。 $ flutter --version Flutter 1.12.13+hotfix.5 • channel stable • https://github.com/flutter/flutter.git Framework • revision 27321ebbad (4 months ago) • 2019-12-10 18:15:01 -0800 Engine • revision 2994f7e1e6 Tools • Dart 2.7.0
『FFVII リメイク』は自動デバッグで、休日、夜間問わず、毎日数百回も通しプレイ中。ゲームのバグを自動で検知するシステムを開発【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
本記事では、1日目におこなわれた『ファイナルファンタジーVII リメイク』（以下、『FFVII リメイク』）のデバッグに関するセッション“"FINAL FANTASY VII REMAKE"における自動QAシステムの構築と運用”をリポート。 本セッションで語られたのは自動QAシステムについて。まずQAとは、Quality Assuranceの略称で、日本語で言えば、品質保証。ゲーム開発においては、ゲームが正しく動作しているか、バグが発生しないか、検証する仕事・部門・チームのことを指す。ゲームファンにとっては、デバッグと言ったほうが伝わりやすいかもしれない。つまり、自動QAシステムとは、自動でデバッグをおこなうシステムということだ。 セッションには、スクウェア・エニックスのAIエンジニアを務める太田健一郎氏が登壇した。 ゲームに最適化した自動QAシステムを目指して ゲームというのは、そもそも
TDDはゆるく実践しても大丈夫 - 千里霧中
最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての
Seleniumアレルギーのための処方箋 - Qiita
何年も前、SeleniumやWebDriverの話で盛り上がった記憶があります。ただ、その当時はまだRailsなどバックエンド中心の文脈でした。今、フロントエンドに軸足が移る中、ブラウザテストの状況はどうなったのでしょう? 不思議なことに、フロントエンド界隈でそれほど話題に上がって来ないですよね (私の周りだけ?)。結構大事なのに。実は皆さん、「Seleniumアレルギー」なんじゃないですか? 公式サイトに漂う ゼロ年代感(下図)。Javaへの躊躇、「めんどくさい」と聞かされ続けた過去、無意識に避けてしまうのがSeleniumです。 ただ、フロントエンドの文脈でこそ、ブラウザテストは重要度を増しています。そこで「Selenium触りたくない病」の筆者が、 四苦八苦した背景 と、2016年だからこそ 見えてきた落とし所 を書いてみたいと思います。 註: 思ったより長文になってしまいました。先
Robot Frameworkとは - Qiita
この記事は「Robot Framework Advent Calendar 2017 - Qiita」の1日目の記事です。 この記事では、Robot Frameworkとは何かというものと、そもそもAdvent Calendarを始めたきっかけを書いていこうと思います。 はじめに 今年、Robot Framework にふれる機会がありました。 幸いなことに、既存のRobot Frameworkを使ったテストコードがあったため、どのように使われるのかが分かりやすい状況でした。 また、Robot Frameworkはドキュメントがしっかりしていたため、既存のソースコードの意味も理解しやすかったです。 一方、新規のテストコードを書こうと思った時には悩みました。 既存のテストコードとドキュメントをきちんと読めば何とか書けたものの、クックブック的な情報がなかったので、時々悩みました。 ということで
idやclassを使ってテストを書くのは、もはやアンチパターンである - Qiita
いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと
An Overview of JavaScript Testing in 2020
(Updated on: 21.11.2021) This guide is intended to catch you up with the most important reasoning, terms, tools, and approaches to JavaScript testing for the year 2022. It combines information from the best articles recently released (they are referenced at the bottom) and adds from my own experience. It’s a little long but whoever reads and understands this guide, can safely assume they know the
Storyshotsが最高すぎる件 - Qiita
こんにちは、@takanoripです。 今回は最近導入したStoryshotsというやつを紹介していきたいと思います。 StoryshotsはStorybookのアドオンで、Storybookに登録されているコンポーネントのスナップショットテストをしてくれます。できることはjestのスナップショットテストとほぼ同じです。 Storyshotsを使うと、コンポーネントごとにテストファイルを用意しなくて良いので手軽にスナップショットテストを導入することができます。 すでにStorybookを導入していれば、下記ファイルを追加するだけでOKです。 簡単でしょ？ また、Storyshotsを使うと、スナップショットテストができること以上に良い効果をProjectにもたらすことができます。その効果について説明していきます。 Storybook Storybookは皆さんご存知だと思うので説明を省略し
「WebDriver」がW3Cの勧告に到達。Webブラウザのテスト自動化などを実現
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ブラウザには外部から操作を行うAPIなどはなく、WebページやWebアプリケーションをWebブラウザで表示した際に画面が正常に表示されている
【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita
はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と
マニアが潰したテスト駆動開発〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （５）
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutter: testing shared preferences
Unityテスト完全に理解した(実機、自動、利のあるテストに食らいつく話)
Unityプロダクトにテストを導入していくまで
アプリを十数個作った僕が初めて書いたテストの話
