［動画で解説］和田卓人の“テスト駆動開発”講座：第4回 ナントカテスト ―― ユニットテスト，単体テスト，機能テスト，結合テスト，受け入れテスト｜gihyo.jp
［動画で解説］和田卓人の“テスト駆動開発”講座 第4回ナントカテスト ―― ユニットテスト、単体テスト、機能テスト、結合テスト、受け入れテスト ニコニコ動画：https://www.nicovideo.jp/watch/sm2195489 前回、テストをDeveloper Testing、Customer Testing、QA Testingの3つに分類しました。ここまでで何か質問はありませんか？ 担当からの質問 「受け入れテスト」というのはCustomer Testなんですか？ はい、そうです。 テストというと、よく「○○テスト」という言葉を聞くと思います。たとえば「受け入れテスト」以外にも、「ユニットテスト」「単体テスト」「機能テスト」「結合テスト」など、いろんな何々テストという言葉があります。質問にお答えする前に、まずテストの分類に対する視点を整理しましょう。 テストの分類に
TypeSpec、Orval、Storybook を使ってフロントエンドのモック生成を自動化する
はじめに フロントエンド開発において、効率的かつ一貫性のあるモック生成は非常に重要です。本記事では TypeSpec、Orval、Storybook の 3 つのツールを使用して自動生成でモックを実現する方法を紹介します。 TypeSpec は、大規模な API を提供するために Microsoft が開発し、使用している新しい API 記述言語です。 Orval は、OpenAPI 仕様から TypeScript のクライアントコードを生成するツールです。これにより、最新の API 仕様に基づいたクライアントコードを常に保持し、API との通信がスムーズに行えるようになります。 Storybook は、コンポーネントを独立して開発・テストするためのインタラクティブなツールです。コンポーネントの見た目や動作を個別に確認できるため、UI の一貫性を保ちながら効率的に開発を進めることができます
Poku
🐷 What's Poku?A cross-platform test runner that brings the JavaScript essence back to testing. ⚡️ Quick Tutorials
各種Prompt Engineeringの日本語実例集（Zero-CoT、mock、ReAct、ToT、Metacog、Step Back、IEPなど） - Qiita
各種Prompt Engineeringの日本語実例集（Zero-CoT、mock、ReAct、ToT、Metacog、Step Back、IEPなど）Python機械学習入門ChatGPTLLM CoT、Zero-CoT、ToT、mock、ReAct、Step Back、Metacog、IEPなど、各種Prompt Engineering手法の概説と、日本語での実際のプロンプト例をまとめた記事です。 各種Prompt Engineering手法を日本語で実装したい方向けの記事となります。 本記事で取り扱う手法は以下の通りです。 項目数が多いため、記事右下の目次リンクもご活用ください。 本記事の内容 01: 通常のPrompt 02: Few-shot Learning 03: CoT（Chain of Thought） 04: 出力形式の指定方法 05: Zero-shot CoT（≒
サーバ不要でバックエンドAPIのモックを実現する「Mock Service Worker 2.0」正式リリース。Fetch API、ストリームAPI対応など新機能
サーバ不要でバックエンドAPIのモックを実現する「Mock Service Worker 2.0」正式リリース。Fetch API、ストリームAPI対応など新機能 Webアプリケーションのクライアントを開発する際に、本来ならばサーバ上で稼働するWebアプリケーションのバックエンドのAPIを呼び出してデータを受け取って表示するといった動作を作り込みたいけれども、まだバックエンドのAPIも開発中であったり、何らかの理由でバックエンドを稼働させる環境を用意できなかったりすることは、しばしば起こりえます。 そうしたときにサーバを立てることなく、バックエンドのAPIをモックとして簡単に設定し提供してくれるソフトウェア「Mock Service Worker」の最新版「Mock Service Worker 2.0」が正式にリリースされました。 Announcing MSW 2.0! Migratio
同じソースツリーでテストが通っていたらテストをスキップする | おそらくはそれさえも平凡な日々
tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,
GitHub - httptoolkit/mockrtc: Powerful friendly WebRTC mock peer & proxy
Let's write an automated test with MockRTC. To test WebRTC-based code, you will typically need to: Start a MockRTC mock session Define rules that match and mock the traffic you're interested in Create a WebRTC connection to a mock peer, by either: Using MockRTC's offer or answer directly. Applying the provided MockRTC.hookWebRTCConnection hook function to your RTC connection, and then connecting t
(自分の) JavaScript のユニットテストの書き方
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
フロントエンドテストプラクティス in open 8
2021/09/13 Open8 で発表したフロントエンドテストプラクティスの話です。
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
モックは必要悪で、しないにこしたことはない - blog.8-p.info
Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値
モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説
モバイルアプリ用テスト自動化ツール「Appium 2.0」まもなく登場。ドライバーの分離、プラグインによる拡張対応など、新機能を開発者Jonathan Lipps氏が解説 モバイルアプリケーションのテスト自動化ツールの代表的なツールが、オープンソースで開発されている「Appium」です。 そのAppiumの次期版となる「Appium 2.0」正式リリースが迫っています。Appium 2.0ではAppium本体から各プラットフォームへ対応するためのドライバが分離され、ドライバの開発が容易になります。 また、Appiumの機能を拡張するプラグイン機構も提供されるため、今後さまざまな拡張機能の登場が期待されるでしょう。 これらAppium 2.0の新機能について、AppiumのプロジェクトリードであるJonathan Lipps氏が、Appiumベースの商用サービスであるHeadSpinを国内で
新規開発におけるシフトレフトアプローチ - スタディサプリ Product Team Blog
こんにちは。QA Engineer の@testtattoです。 今自分は新規開発プロジェクトのスクラムチームの一員として参画しています。 今回はチーム内で行っているテスト活動をシフトレフトアプローチの事例として紹介いたします。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 アジャイルプロセスの中でのテスト活動を知りたい方 ウォーターフォールプロジェクトだが、上流からアサインされて困っている方 テスト、QA のことなら何でも知りたい方 まえがき 読んでもらう前にいくつかの前提を共有します。 シフトレフトとは この記事では シフトレフト(shift-left) を 「テスト活動を早期に行う」 という少し広い意味で使っています。 シフトレフト自体はWikipediaにおいて複数のタイプに系統分けされていたりしますが、国内におけるシフトレフトはテスト 7 原則の「早期テスト
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
GitHub - Typescript-TDD/ts-auto-mock: Typescript transformer to unlock automatic mock creation for interfaces and classes
A few years ago we've created this project with the idea in mind that typescript transformers would be easier to configure. Unfortunately the typescript team has no intention to improve the developer experience. You can see more information at this link. We believe that stop developing new features is the best decision to inform who is currently using it and who find it for the first time. We will
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reactアプリケーションのテスト戦略
Internet Explorer デベロッパー センター
アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer
開発者向けのテストの本いろいろ
