TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する
はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
フロントエンドでTDDを実践する（react-testing-libraryを使った実践編） - Qiita
この記事は、フロントエンドでTDDを実践する（理論編）の続編として書きました。 本記事では、react-testing-libraryでReactでTDDする方法をサンプルを使って解説します。 react-testing-libraryは、PayPalのエンジニアでありフロントエンドのTDDの第一人者であるKent C Doddsが、enzymeのリプレイスを意図して作ったReactのための新しいテストユーティリティです。 設計思想は、The more your tests resemble the way your software is used, the more confidence they can give you. enzymeのように実装そのもののテストをするよりも、ユーザーが使うようにテストされるべきというフィロソフィーがAPIに強く反映されています。 実際には、いくつか
Introduction | Pact Docs
Pact is a code-first tool for testing HTTP and message integrations using contract tests. Contract tests assert that inter-application messages conform to a shared understanding that is documented in a contract. Without contract testing, the only way to ensure that applications will work correctly together is by using expensive and brittle integration tests. Do you set your house on fire to test y
API documentation - Sinon.JS
These docs are from an older version of sinon. Do you want the latest docs? API documentation - Sinon.JS - v18.0.0 This page contains the entire Sinon.JS API documentation along with brief introductions to the concepts Sinon implements. General setup Fakes Spies Stubs Mocks Spy calls Promises Fake timers Fake XHR and server JSON-P Assertions Matchers Sandboxes Utils Migration guides Migrating from
puppeteer + express + mocha で快適 TDD している話 - ジンジャー研究室
TDD という用語を使うとテストおじさんがやってきて、それはそうじゃないとか色々言い出すと思うんだけど、それが趣旨ではないので勘弁して欲しい。予防線ここまで。 Puppeteer でテスト Puppeteer が世間的にも個人的にもブームだ。ヘッドレス Chrome を操ってクローリングしたりスクリーンショットを撮ったり色々出来る。 github.com で、あれこれと遊んでいるうちにテストに使えるんじゃね？ということに気づいたので実践してみたら快適だったという話。ブラウザ操作してテストというのは昔から Selenium というのがあり、こちらはクロスブラウザで出来たりするんだけどまあ大掛かりでだるさを感じてしまう。メリットデメリットの比較はさておき、どうせならナウいやつを使ってみたい。よし使おう。 何をテストするか 普段から画面を見ながら開発しているので、どこに何が表示されているべきとい
ScalaのシンプルなテスティングライブラリMinitestを使ってみる - たけぞう瀕死ブログ
Twitterで以下の記事を見てMonixの開発用に作られたというMinitestというテスティングライブラリの存在を知りました。 alexn.org GitHubのリポジトリはこちらです。 github.com ScalaのテスティングライブラリというとScalaTestとSpecs2が双璧ですが、Minitestはこれらと比べると非常にシンプルなライブラリで、ScalaTestのFunSuiteからの移行がしやすいようデザインされているようです。使い方は上記の記事とGitHubのREADMEを見れば大体わかると思います。 試しに簡単なテストをMinitestで書いてみたのですが、ScalaTestのFunSuiteからであれば概ね以下のような作業で移行できそうです（FunSuiteとの互換性重視ならassertThrowsを敢えて変えなくてもよいのではという気もしますがなんで変えている
プログラマーも手動テストしようぜ 〜 忍者式テストのすすめ 〜 - Qiita
はじめに プログラマの中には、TDDのような自動テストを整備すれば、手動テストは必要なくなると考えている方もいるようです。本記事では、主にプログラマー向けに、手動テストの大切さとはじめ方を書きます。 はじめ方に忍者式テストが出てきます。 プログラマーが得意なテスト、不得意なテスト プログラマーはCheckingが得意です。Testingは不得意です。 テストには Testing と Checking の二つの作業がある Michael Boltonという人のお言葉があります。 Testing vs. Checking « Developsense Blog Checking Is Confirmation Testing Is Exploration and Learning テストにという行為はCheckingとTestingの二つの行為の分けられます。 Checkingは既知の不具合が
実践 Pact:マイクロサービス時代のテストツール - クックパッド開発者ブログ
技術部の taiki45 です。 以前「サービス分割時の複雑性に対処する: テスト戦略の話」という記事で、サービス間のインテグレーションテストにおける問題について紹介しました。現在のクックパッドではこの問題の解決のために Pact というツールを導入して運用しています。この記事では、その運用の知見を紹介できればと思います。 Pact Pact は Consumer-Driven Contract testing (CDC testing) を実現するためのツールです。"Consumer"、"Provider" という見慣れない単語が出てきますが、この記事ではだいたい「Consumer = Web API クライアント」、「Provider = Web API サーバー」と対応ができます。この記事では具体的な Pact の利用例を通じて CDC testing がどういうものなのかについても
e2e_sushiとtemplate_literal_sushiでPageObjectパターンの話をした
vivaldi_sushiとe2e_sushiと隣でやってたtemplate_literal_sushiに参加した #template_literal_sushi と #e2e_sushi のログ - Togetterまとめ ログはいつもどおり記憶だよりで色々間違ってる気がするので気になるところは本人に聞こう Vivaldi_sushi Vivaldiの話 付く前に終わってた Testium - azu 自分はTestiumとPageObjectパターンの話をしました。 Testiumって何？ 同期的なWebDriver API PageObjectパターン という感じの内容です。 Testium関係で色々報告したりPR送ったりしたので、自分が気になるところは大体直った感じがします。 後はgroupon-testium/webdriver-http-syncのAPIが順次実装されていけば、
マイクロサービス時代を乗り越えるために、Rack::VCRでらくらくアプリケーション間テスト - クックパッド開発者ブログ
新規アプリケーションの構成 Rack::VCR リクエストの記録 リクエストのモック リクエストの再生 おまけ: Androidアプリのテスト 弊社での利用例 未来 こんにちは、会員事業部の小室 (id:hogelog) です。気づけば弊社に入社してから２年と2ヶ月が経っていました。 今回はその2年2ヶ月で初めて会社プロダクトを rails new したRailsアプリケーションと、そのアプリケーションで利用したRack::VCR (https://github.com/miyagawa/rack-vcr) について簡単に解説します。 新規アプリケーションの構成 今回私が新規に作成したRailsアプリケーションは仮にここではomoikane（仮）と呼ぶことにします。omoikaneはリクエストがあると社内の汎用APIサーバにアクセスし、APIサーバから取得した情報を元にレスポンスを返すアプ
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Mailtrap
GitHub - localmed/api-mock: Creates a mock server based on an API Blueprint
GitHub - enzymejs/enzyme: JavaScript Testing utilities for React
ハイパフォーマンスSeleniumテスト＠サイボウズ
GitHub - yosuke-furukawa/stubcell: Stubcell is simple stub module