サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは、アプリケーションエンジニアの鈴木です。 先日、私が担当しているtebiki現場分析をReact v18 から v19 にアップグレードしました。 この対応は半年以上前から計画されていたものの、私自身初めての経験が多く、なかなか着手できずにいました。 今回ようやくリリースまでこぎつけたので、特に大変だったポイントや、やっておいて良かったことまとめます。 「依存ライブラリの対応状況の調査」が大変だったReact 側の変更点はアップグレードガイドを読めば理解できます。 一方で「React に依存しているライブラリがReact 19 をサポートしているのか」をどう調べればよいのかがわからず、ここが最初の大きな壁でした。 主要ライブラリのメジャーアップデート対応は初めてだったため、ネット検索・issue 調査・deep research など、使える手段を総動員して調べる日々。それ
はじめに はじめまして、テックドクターでバックエンドエンジニアをしている筧と申します。 最近、弊社ではAPI の品質を担保するために「API シナリオテスト」をプロダクトに導入しました。今回は、このAPI シナリオテストのツールであるPostman(+Newman)、Tavern そして runn を比較し、最終的に runn を選んだ理由をご紹介します。API シナリオテストとは？API シナリオテストとはなんでしょうか？ 開発におけるテストといえば、ユニットテストや結合テスト、API テストや E2E テストなどをよく耳にします。しかしAPI シナリオテストという言葉はあまり聞き馴染みがないという方も多いかもしれません。API シナリオテストはAPI テストの一種で、複数のAPI を連鎖的に呼び出して実行するテストです。以下の特徴を持っています。 複数のAPI を順序
はじめに この記事では、フロントエンドの開発において意義のあるテストはなにか？ それらをコスパよく実現するためにはどうすればよいか？ について考えて、作った構成を紹介します。 前提 下記の技術スタックを利用していますが、これ以外のスタックでも応用可能な仕組みが多いと思います。Next.jsStorybookplaywright msw msw-snapshot （拙作） 注意事項 この記事の構成は、まだまだ実験的な機能だったり怪しい技術が一部採用されています。 msw-snapshot 拙作のライブラリであって、動作が怪しい可能性がめっちゃあります。Next.js の testmodeplaywright + msw を実現するために必要でした。 まだまだ全然まともに動かないかもしれません。（サンプルリポジトリの単純なテストは動いた） サンプル 下記のリポジトリにサンプルを用意
CodeZine編集部主催のウェビナー「CodeZine Night」の第一回発表資料 https://codezine.connpass.com/event/279012
フロントエンドのテストをしよう Webのフロントエンドの自動化を進めようか。という話をしていて、 「そもそもテストってなんだ？」 「フロントエンドに特有のテストってなんだ？」 「〇〇ってツール流行ってるらしいってどうよ？」 みたいなことを話をしていました。そうしたときに、やっぱり知識足らねぇなぁ。と思ったので、2,3日でゴリゴリと内容をまとめてみる作業をしてみました。 あんまりこういう書き方はしないんですが、私自身散発的な思考で、フロントエンドのテストを調べることをしたので、そのような語り口で書いてみようと思います。 以下の内容は、あくまで例なので、別にこういう仕事があったわけではないです。 とりあえず投げられた要求・仕様 とりあえずなんか仕事が振ってきた。パラパラと要求を聞いてみると、こんな感じだった。 承認のダイアログが欲しい メッセージのフォントはOswald メッセージは変更できる
2024/04/17: 更新 内容を更新した記事を書きましたので、よかったらこちらも併せて、ご覧ください。zenn.dev こんにちは！フロントエンドエキスパートチームの@nus3_です。kintone のフロントエンド刷新プロジェクト（フロリア）では、品質を保ったまま開発を加速させるためにフロントエンドのテストを積極的に行っています。 今回はそんなフロントエンドのテストの実装例をいくつか紹介します。この記事がフロントエンドのテストを行う上での参考になれば幸いです。 テストに使用する主なパッケージ コンポーネントのテスト 補足: Testing Library の記法をチェックしてくれるeslint-plugin-testing-library カスタムフックのテスト 補足:React v18 では @testing-library/react の renderHook を使う 参考
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
１．フロントテストとStorybook の活用 フロントテストのどこにコストがかかるのか バックエンドのテストはシンプルな入力と出力が多いので、テスト作成は比較的簡単です。一方、フロントエンドのテストはUI イベントや動的な要素も含まれ、複数の出力があるため、テスト作成はより複雑になります。これにより、テスト作成のコストが増大します。 生 jest で書くフロントテストと心の目 Jest は主にJavaScript のユニットテストをサポートするツールであり、UI レンダリングのテストを行うためには対応するライブラリが必要です。Jest は DOM イベントをエミュレートすることはできますが、ユーザーの操作と同様のインタラクションを再現することは困難です。機能の多いコンポーネントをテストする際に、Jest を使用するとテストコードが複雑になりがちです。そして最大の問題は、視覚的な部分
![[Next.js]フロントテストのコストはStorybookで削減出来る](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f92b7b04788f510c30709cc61df382bfe13d5b11a%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fres.cloudinary.com%252Fzenn%252Fimage%252Fupload%252Fs--nAeOk0Ql--%252Fc_fit%25252Cg_north_west%25252Cl_text%253Anotosansjp-medium.otf_55%253A%2525255BNext.js%2525255D%252525E3%25252583%25252595%252525E3%25252583%252525AD%252525E3%25252583%252525B3%252525E3%25252583%25252588%252525E3%25252583%25252586%252525E3%25252582%252525B9%252525E3%25252583%25252588%252525E3%25252581%252525AE%252525E3%25252582%252525B3%252525E3%25252582%252525B9%252525E3%25252583%25252588%252525E3%25252581%252525AFStorybook%252525E3%25252581%252525A7%252525E5%25252589%2525258A%252525E6%252525B8%2525259B%252525E5%25252587%252525BA%252525E6%2525259D%252525A5%252525E3%25252582%2525258B%25252Cw_1010%25252Cx_90%25252Cy_100%252Fg_south_west%25252Cl_text%253Anotosansjp-medium.otf_37%253A%252525E7%252525A9%252525BA%252525E9%2525259B%252525B2%25252Cx_203%25252Cy_121%252Fg_south_west%25252Ch_90%25252Cl_fetch%253AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2VlZTgzMDYyMDQuanBlZw%253D%253D%25252Cr_max%25252Cw_90%25252Cx_87%25252Cy_95%252Fv1627283836%252Fdefault%252Fog-base-w1200-v2.png&f=jpg&w=240)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 自分は2021年に新卒でweb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りの開発をメインで行なっていなす。 今回は実務でNext.jsプロジェクトにテストを導入することになり「React-Testing-Library」と「Jest」について改めて学び直したのでその内容を紹介します。 はじめに「React-Testing-Library」と「Jest」の概要を説明しその上で具体的なテストコードを何パターンか書いていきます。 この記事の
メルカリの自動化＆品質保証グループ（Automation & QA Group：通称AQA）の おれたま@AHA_oretama です。 私は普段、テスト自動化やCI / CD を主に行っています。 今回は、Appium×Android E2Eテストのテスト結果の見やすさを改善し、テスト結果を可視化することで気づきが生まれた話について、紹介していきたいと思います。 テスト結果の見やすさ、可視化の重要性について いま使っているテストレポートの課題 Allure Framework 並列化した分だけレポートも分かれてしまうことへの対処 スクリーンショット、スクリーンレコード以外のアタッチメントを追加することができないことへの対処 過去のテスト結果と比較できないことへの対処 他の改善点 テストのタイムラインが見える トレンドも表示できる Looker 生まれた気づき 課題 終わりに テスト結果の
概要 試験工程をスプレッドシートで管理していたがそろそろ脱却したいと思ったので色々探してみました。 すると、同じことを考えている先駆者さんがいらっしゃったので参考にさせていただきました！ 導入に至った経緯 QA体制が未成熟 3名までなら無料で利用できる テスト計画・テスト結果をエクスポートできる 入力項目が整理されているので試験表の質を一定にできる 自動化したテストケースを管理できる 手動テストと自動テストの結果を併せて一覧できるAPIにより自動テストの実行結果を自動的に反映することができるetc これは、中々良いツールなんじゃないか！？ ということで導入してみました 実際の導入方法を説明していきます 事前準備 以下からサインアップしてください サインアップ完了後、ダッシュボードに遷移した状態からスタートとします それぞれの設定方法は以下を参照してください 新しいプロジェクトを作成 プ
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」（Test Driven Development、以下「TDD」）は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。本稿では、そうしたTDDの発展や、振る舞い駆動開発（Behavior Driven Development、以下「BDD」）など他のテストファースト手法への展開についても解説します。 ※編集部注：ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
今日は、テスト自動化と、ブラウザ自動テストツールSeleniumについて、知らない方でも分かるようイチから解説したスライドを作ったのでご紹介します。 このスライドは、2014年2月28日に開催された「Enterprise ×HTML5 Conference」の発表スライドに、時間の関係で省略した多数の未発表ページを加えたものです。 イチから分かる解説についてはこれで終わりですが、せっかくですのでスライドの見どころをご紹介しましょう。
iOSのアプリケーションではモデル周りのテストと同じぐらいUI周りのテストが重要な気がするのですが、画面のテストってちょっと面倒ですよね。その上Xcode標準のテストフレームワークでは画面遷移などのテストができません。そこで、統合テスト用のテストフレームワークを使う必要がでてきます。 選択肢はいくつかありますが、使い方がシンプルで導入も容易なKIF Frameworkを紹介します。 KIF FrameworkGitHub - kif-framework/KIF: KeepIt Functional - An iOS Functional Testing Framework KIFは決済サービスSquareが自社アプリケーションの統合テストのために開発したフレームワークだそうです。KIFを使ったテストではボタンをタップして画面遷移したり、画面遷移した先のUIの存在を確認したりといったこと
対象読者と環境 Webブラウザを使ったテストを自動化するOSSのツール「Selenium2（WebDriver）」のインストール手順と基本的な使い方をご紹介します。想定読者は、テスト自動化に興味のあるプログラマーです。 SeleniumにはSelenium IDEというブラウザ操作を記録できるツールがあり、SeleneseというSelenium1に対応したコマンドをHTML形式で保存します。これによってノンコーディングでテストスクリプトを作成することができるのですが、WebDriverやプログラミングによる効率化の恩恵を受けることができません。本記事はSelenium IDEを活用しながらWebDriver使ったテストスクリプトをJava（JUnit）形式で書いていくための手引きとなっています。 今回筆者が使用した環境は以下のとおりです。 OS：Windows 7Java：1.7 Fir
本シリーズは、WebブラウザをUIとして利用した業務システムやアプリケーション（以下、Webシステム、Webアプリケーション）のテストをテーマとして、Webブラウザを使ったテストを自動化するOSSのツール「Selenium2」を紹介します。業務システム開発の現場で適用してきたノウハウを元に、これまでSelenium2について知らなかった人から以前使った経験がある人まで、より実践的な「使える」内容を盛り込んでいきたいと思います。本シリーズのスコープと対象読者本シリーズはWebシステム・Webアプリケーションのテストの中でも「Webブラウザを操作して実施するテスト」をスコープにしています。開発工程としては、1モジュールとして単体テストに位置付けられる場合もあれば、複数のモジュールやシステムと連携して結合テストや総合テストに位置付けられる場合もあるでしょう。これらのテストのことを、本シリーズ
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
