タグ

テストに関するd4-1977のブックマーク (64)

  • テスト優先度をあげたくなる実話 - フロントエンド版 -

    Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか?」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。 限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか?」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。 【Storybook】不要な Global CSS を削除できた きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS

    テスト優先度をあげたくなる実話 - フロントエンド版 -
    d4-1977
    d4-1977 2021/10/17
    どんなメリットがあるのかハッキリしてくるとコストと見合うか?を判断できるのでいい!
  • ローコードテスト自動化ツールの mabl がすごい

    というのを使っていて思ったのでレポを書いていきます。 mabl とは - 基的な機能 ざっくり言うと E2E テストをお手軽にメンテできるツールです。 こんな感じでポチポチ画面を操作していくと、それで実行したアクション(ボタンやリンクをクリックするなど)を自動で記録してくれて、E2E のテストを作成することが出来ます。 コードを書かずに E2E テストをサクッと作れちゃうのが魅力な訳ですが、それだけではありません。そんなすごいところを紹介していこうと思います。 mabl のここがすごい Auto Healing 何やら回復魔法みたいな感じでかっこいいですが、何かというと E2E テストがコケるようになった時に自動で修復してくれる機能です。 例えばボタンの位置が変わってしまっても、同じ文脈であろうボタンを自動で探して修復したりしてくれます。 E2E での辛さといえば、やはりテストのメンテナ

    ローコードテスト自動化ツールの mabl がすごい
    d4-1977
    d4-1977 2021/08/07
    おいくらなのか💸お高いんでしょう?
  • Visual Regression Testing はじめました - 具体的な運用 Tips | Recruit Tech Blog

    こんにちは。スタディサプリ ENGLISH Web フロントチームの kazuma1989 です。 先日、私たちのチームは開発フローに Visual Regression Testing を導入しました。Visual Regression Testing は、フレームワークを紹介する記事は見つかるものの、具体的な知見があまり広まっていない印象なので、具体的な設定値や選定理由も含め紹介してみます。 React による Web フロント開発を前提にしていますが、Visual Regression Testing のコア部分は「画像の比較」であるため、他のプラットフォーム開発でも参考になればと思います。 Visual Regression Testing (VRT) とは Visual Regression Testing (日語で 画像回帰テスト、以下 VRT)は、画像の差分を検出する、スナ

    Visual Regression Testing はじめました - 具体的な運用 Tips | Recruit Tech Blog
    d4-1977
    d4-1977 2021/07/24
    なかなか出来ないテストなんだけれど、用意やコストが気になるところ。
  • Cypress Component Test Runner を Vite & React で試す

    Cypress Component Test Runner Cypress 7.0.0 より、 2021/04/10 時点ではまだ Alpha 段階ですが Cypress Component Test Runner という機能が追加されました。(@sekikazu01 さんのツイートで知りました。) E2E テストのようにブラウザ上で実際にレンダリングしつつ、コンポーネントテストのような軽快さで動くという、中間的な位置付けと捉えています。 試してみる (Vite) create-react-app や vue-cli を使ったチュートリアルが用意されているので、とりあえず確認してみたい場合はそちらが良さそうでした。 ドキュメントも存在しており、webpack-dev-server を利用する場合はそちらが参考になりそう。 ただ、そのままやってもテンションが上がらないので、紹介記事には As

    Cypress Component Test Runner を Vite & React で試す
  • フロントエンド(React Testing Library)で TDD(テスト駆動開発)をする

    私はフロントエンドエンジニアとして働いてはいるのですが、巡り合わせが悪いのでしょうか?まともなテストを書いたことがないんですよね。まあ、それもでテストくらい書けないとなぁ。なんて思ってはちょいちょい調べたりする日々を過ごしていました。 そんなある日、たまたま TDD(テスト駆動開発) についての動画を視聴してみました。 TDD 自体は知ってはいて、なんとなく知っているくらいの知識ではありましたが、分かりやすい説明とその思想が好きで、のめり込むように見てしまいました。 その後も何度か視聴して、フロントエンドでも TDD したいなと考え始めました。 普段テストすら書いていないのにいきなり TDD とも思わないこともなかったですが、実際に普段自分がさわっているようなコードに落とし込んで書いていくと、テストする当の意味というものが、より正確に理解できてきたような気がします。 そんなテスト初心者の

    フロントエンド(React Testing Library)で TDD(テスト駆動開発)をする
    d4-1977
    d4-1977 2020/11/23
    React Testing Libraryというのがあるのか。自前で用意する必要があると思っていました💦こうした準備しやすいといいですね
  • 【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita

    はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの?どんなテストを書いたらいいの?と迷っている初心者プログラマさんは意外と多いのではないでしょうか? そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と

    【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita
    d4-1977
    d4-1977 2020/10/22
    方針を示すとアレコレ決めるときの判断基準になるから大切なことだと思いました
  • フロントエンドテストを雰囲気で書いているとハマりがちなところ - Qiita

    この記事の対象読者 Webフロントエンドのテストコードを雰囲気で書いてる人 この記事の前提 テストフレームワークは Jest の利用を想定しています Jest自体のセットアップや使い方は一切触れていません フロントエンドテスト、慣れてないとハマりがち 経験上、フロントエンドのテストコードを書く際には、慣れていないとハマったり混乱してしまうポイントが多くあると思っています。 僕のdivタグ書き換えるコードがテストだと動かない エラーになるテストなのにパスしちゃう 慣れてくると何でもない部分ではありますが、基的な考え方や躓きやすい箇所を整理してみました。 フロントエンドのテストコードはNode.js上で実行される フロントエンド開発では、実行環境として主にブラウザを対象とすることが多いでしょう。つまりWindowオブジェクトの利用やDOM操作が可能です。(たとえば location.href

    フロントエンドテストを雰囲気で書いているとハマりがちなところ - Qiita
  • E2E テスト自動化プラットフォーム「Autify」を使ってシナリオをレコーディングする - kakakakakku blog

    2019年10月に正式リリースとなった「E2E テスト自動化プラットフォーム Autify」を試す.今回は Autify の CTO 松浦さん (@dblmkt) に期間限定の検証アカウントを作っていただいた.ありがとうございます! autify.com 今まで Selenium や Capybara (Poltergeist) を使った E2E (End to End) テストの導入経験はあるし,最近だと Cypress や Puppeteer を使う機会もある.とは言え,技術選択よりも「E2E テストを継続的にメンテナンスすること」に対して課題を感じる.仮説検証を繰り返すためにリリース頻度を上げていくと,あっという間に E2E テストも落ちてしまう.適当に XPath を修正したり,修正を諦めた経験もある. 今回紹介する「Autify」を使うと AI にシナリオのメンテナンスを任せられ

    E2E テスト自動化プラットフォーム「Autify」を使ってシナリオをレコーディングする - kakakakakku blog
  • Testing JavaScript をやってみたら学びがあって良かった話 - Adwaysエンジニアブログ

    こんにちは。リファクタリングが大好きなフロントエンドおじさん梅津です。 自信を持ってリファクタリングするには信頼できる自動テストが必要ですよね。 じゃあ信頼できる自動テストとはなんだろう?どう書いたらいいんだろう?と考えていました。 とくにコンポーネントを含む UI テストに対しての悩みが強かったです。 そんなときに出会ったのが Testing JavaScript です。 この記事ではその Testing JavaScript の紹介をしたいと思います。 Testing JavaScript とは Testing JavaScript は PayPal のエンジニアである Kent C. Dodds によって作成された教材です。 ページを開いてすぐ目に飛び込んでくるテスティングトロフィーが特徴的ですね。 Testing JavaScript では、ここに記されている Static, Un

    Testing JavaScript をやってみたら学びがあって良かった話 - Adwaysエンジニアブログ
    d4-1977
    d4-1977 2020/05/09
    気になる。いまなら、40%引きみたいなので、チャンスかも
  • Shows

    AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Find out how you can use GitHub Copilot, an add-on that is powered by AI, to get helpful suggestions when writing code or documentation. This

    Shows
  • ちょうどよい Rails E2E テスト/enough-good-rails-e2e-test

    Rails には system test (spec) と呼ばれる、Capybara を使った自動ブラウザテストの仕組みが備わっています。これはとても便利で強力なテストではありますが、けして万能ではありません。実行時間が長くなりがちですし、テストコート量も多くなりメンテナンスが大変です。 Ruby

    ちょうどよい Rails E2E テスト/enough-good-rails-e2e-test
    d4-1977
    d4-1977 2020/02/08
    ちょうどよい、を言語化する試みと、試みをチームでシェアするとかが大切なのかな
  • 明日からはじめるテストのあるフロントエンド開発 ~ テスティングトロフィー ~

    Creating an Effective Media Campaign and Attracting Event Sponsors

    明日からはじめるテストのあるフロントエンド開発 ~ テスティングトロフィー ~
    d4-1977
    d4-1977 2019/11/17
    フロントエンドもテストが書けるのが当たり前な時代ですよね。書いていきましょう!
  • エンドツーエンドテストの自動化は Cucumber から Turnip へ

    はじめに テストについてのおさらい テストの種類 内部テストと外部テスト 内部テスト 外部テスト テストファーストとテストラスト テストファースト テストラスト テストツールの進化・変遷 Web 周りテストツールの変遷 テストツールもベタからメタへ 第一世代:Test::Unit 第二世代: RSpec 第三世代: Gherkin (Cucumber/Turnip) 実装者側と利用者側の接点 エンドツーエンドテストツールとしての Cucumber 継続的インテグレーションツールの普及とエンドツーエンドテストの需要の高まり エンドツーエンドテストツールとしての Cucumber のメリット なぜ Cucumber がそれほど普及していないのか Cucumber から Turnip へ Turnip とは Turnip の作者 Cucumber から Turnip で改善された点 Turnip

    d4-1977
    d4-1977 2019/08/19
    この記事いいらしいので読むぞ
  • テスト仕様書 - Qiita

    単体テスト 結合テスト システムテスト(機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト(シナリオテスト) 運用テスト 現場(案件)によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト(Integration Test)以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPMPdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ

    テスト仕様書 - Qiita
    d4-1977
    d4-1977 2019/07/23
    テストで気になることについてしっかりまとめれている👀
  • privateメソッドのテストについての考え方 #yochiyochirb - No Purpose

    よちよち.rbに久しぶりに参加した。 yochiyochirb.doorkeeper.jp 今日の回はjnchitoさんがゲストとして招かれていて、あれこれ質問できるという会だった。 「昔からよちよち.rbに参加してくれてる人も是非」と言ってもらったので参加させてもらった。 jnchitoさんといえば、今でもRSpecのまとめ記事やRubyの新しいバージョンのまとめ記事はよく拝見するし、 自分がある程度RSpec書けるようになったのは、jnchitoさんらが翻訳された「Everyday Rails - RSpecによるRailsテスト入門」に支えられたところもあり、 お話してみたいと思っていた。 それもあって、最近職場で話して他の人の意見も聞いてみたいと思っていたことを、事前にアンケートフォームから質問として投げた。 #yochiyochirb で伊藤淳一さんに「プライベートメソッドにどう

    privateメソッドのテストについての考え方 #yochiyochirb - No Purpose
    d4-1977
    d4-1977 2019/03/05
    設計を見直すというのも手だと思うし、不安だったら書いていいんじゃない?というようなチームで目線合わせするのいいな、思います
  • 2018年のアウトプットまとめ - t-wadaのブログ

    2018年は公私ともに忙しい年でした。このエントリを書いている時点でもう年が明けてしまいましたが、1年のふりかえりとして、またある種のポートフォリオとして、1年間のアウトプットをまとめたいと思います。 手元のスケジュールを確認したところ、講演/ワークショップを53回、インタビュー/対談/Podcast出演を5回、社内読書会ゲスト参加を3回、執筆、増刷作業を6回、主要OSSプロダクトのリリースを3回行っていました(小さなモジュールはカウント外)。これらが2018年のアウトプットです。 新作登壇(6回) 私は再演が多い講演者で、登壇依頼のほとんどは既存の講演/ワークショップの再演です。それでも2018年に新しいテーマの講演をいくつか行いましたので、それら「新作」がアウトプットの筆頭となるのではないかと思います。 技術選定の審美眼(2月15日) 2月15日に「技術の進化の歴史は振り子ではなく螺旋

    2018年のアウトプットまとめ - t-wadaのブログ
  • 外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck

    Oct 31, 2018 at AWS Dev Day Tokyo 2018 #AWSDevDay #AWSTDD

    外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
  • TestProf: Ruby/Railsの遅いテストを診断するgem(翻訳)|TechRacho by BPS株式会社

    概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: TestProf: a good doctor for slow Ruby tests 公開日: 2017/08/25 gemリポジトリ: test-prof/test-prof 著者: Vladimir Dementyev サイト: Evil Martians’ team blog 2017/10/10: 初版公開 2023/07/04: 更新 テストを書くことは、開発における重要なプロセスであり、RubyRailsのコミュニティには特に当てはまります。私たちはテストでgreenが点灯するまで長時間待たされていることに気づいて、初めてテストスイートのパフォーマンスというものに関心を寄せるようになるものです。 私はテストスイートのパフォーマンスの分析に多くの時間を費やし、テストを高速化するテクニックを編み出すとともにツールを開

    TestProf: Ruby/Railsの遅いテストを診断するgem(翻訳)|TechRacho by BPS株式会社
  • ユーザーリサーチを考える(2018年夏まとめ)|Yoko Nishida|note

    2018年夏はユーザーリサーチについて考える機会が多かったので、印象的だった学びを振り返ってみます。 ・プロジェクト:小学校、フィリピン ・CIID : シンガポール、Studio Opt、サマースクール共有会 ・Podcast : Automagic、Takram Cast ・勉強会:THE GUILD STUDY、s-dev talks ・ブログ:デザイナーがスタートアップをつくり、EXITするということ ・書籍:UXリサーチの道具箱、ユーザビリティエンジニアリング、ユーザーストーリーマッピング、「欲しい」の質ユーザーテスト 「ユーザーテストでプロダクトを磨き込む」の記事にまとめた知識を、当時担当していたプロジェクトで実践してみました。ユーザービリティの評価基準が明確にしたことで、以前よりも分析や改善点の洗い出しがスムーズにできました。 CIID Service Design Thi

    ユーザーリサーチを考える(2018年夏まとめ)|Yoko Nishida|note
    d4-1977
    d4-1977 2018/09/25
    ユーザーリサーチやアクセス解析って デザイナーだけのスキルではないよなあ、と思うけれど何も出来てない😢
  • 時間に依存したテストへの取り組み

    こんにちは、技術開発部のnakamoriです。普段は法人向けサービス「FiNC INSIGHT」の開発に携わっています。 エントリでは、ステージング環境でのQA時に頻発する「時間」についての課題と取り組みについて述べています。 テストにおける「時間」の問題「FiNC INSIGHT」では「FiNCウェルネスサーベイ」と呼ばれる組織の健康課題を分析する質問の受検・収集・分析や、遺伝子検査・血液検査結果の開示管理ができます。 これらのサービスには、例えばFiNCウェルネスサーベイでは質問票をいつ発行していつ集計し、いつ結果を開示するかといった時間に関連したイベントが存在します。検査系のサービスでは、いつ検査結果を取り込み、いつ結果を開示し、いつその予定をユーザーに通知するかといったものが存在します。 このようなサービスに機能を加えQAを行っていく場合に「時間」が課題になります。 例えば、ユ

    時間に依存したテストへの取り組み
    d4-1977
    d4-1977 2018/07/20
    時間が関係するテスト難しい