タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Testとprogrammingとjavascriptに関するItisangoのブックマーク (5)

  • フロントエンドのテスト基盤を Jest から Vitest に移行した話

    こんにちは。ナレッジワークの torii です。 7 月にフロントエンドエンジニアとして入社してもうすぐ半年、そろそろ技術記事の一つも書きたいなと思っていたところに、ちょうどいいネタを見つけたので投稿してみます! Jest から Vitest に移行してみた 早速やったことですが、フロントエンドのテストフレームワークを Jest から Vitest に移行しました。理由としては、Jest が CJS を前提として動作しており、ESM 前提のモジュールを動かすのに一手間も二手間もかかるからです。 ナレッジワークのフロントエンドNext.js を採用しており、テストフレームワークには Next.js と相性の良い Jest を採用していました。関数単位のテストや UI コンポーネントのテストを書く分には問題なかったのですが、それより上層(ページなど)になるとたちまち ESM 互換性の問題を

    フロントエンドのテスト基盤を Jest から Vitest に移行した話
  • リーダブルなテストのための、jest モックファクトリー関数

    単体テストを書く時、モジュール間の関連を検証するため、一部のモジュールをモックする必要が出てくることがあります。モックは様々な手法がありますが、書き方によって、メンテナンス性やテストの可読性が変わります。一般的に行われるモック手法を確認しつつ、よりリーダブルなテストを書く方法を紹介します。 ログイン API を呼び出す Web API クライアント 今回紹介する、モック対象の Web API クライアントです。Native Fetch API を関数でラップした、自作の Web API クライアント(ログインするためのlogin関数)です。 export type Data = { redirectUrl: string; }; export type Input = { email: string; password: string; }; export async function l

    リーダブルなテストのための、jest モックファクトリー関数
  • モック関数 · Jest

    モック関数によりコード間の繋がりをテストすることができます。 関数が持つ実際の実装を除去したり、関数の呼び出し(また、呼び出しに渡されたパラメータも含め)をキャプチャしたり、new によるコンストラクタ関数のインスタンス化をキャプチャできます。 そうすることでテスト時のみの返り値の設定をすることが可能になります。 関数をモックするには、次の2つの方法があります。 1つは、テストコードの中でモック関数を作成するという方法。 もう1つは、manual mockを作成してモジュールの依存性を上書きするという方法です。 モック関数を利用する​ forEach 関数の実装をテストすることを考えてみましょう。 この関数は、与えられた配列の各要素に対して、コールバック関数を呼び出します。

    モック関数 · Jest
    Itisango
    Itisango 2022/08/19
    マニュアルに書いてある通りに記述しているつもりですが、mockが私の期待通りに動かないでいます。試行錯誤中。
  • 初めから厳密すぎるテストを書くのは筋悪なのではないかという話 - 愛と勇気と缶ビール

    これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。 何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。 例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。 { valid: true, foo: 10, bar: 0 } で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のke

    初めから厳密すぎるテストを書くのは筋悪なのではないかという話 - 愛と勇気と缶ビール
    Itisango
    Itisango 2013/10/25
    “同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。”
  • JavaScriptでソフトウェアの正しさを数学的厳密に証明してみた - yukobaのブログ

    現在、Shibuya.js が開催中です!Ustream で http://www.ustream.tv/channel/shibuyajs にて放送されています。これから、このブログの内容をしゃべります! 今回「テスト」がテーマなうえ、Shibuya.js は「役に立つ話担当」「ネタ担当」に分かれていて、僕は「ネタ担当」なんですが(笑)、いつも通りネタです。でも、遠い未来の役立つネタです! きっかけは、id:t-wada さんに、GUIの自動テスト関係の質問をしたら、凄くいいことを教えてもらいました。 全てのテストはサンプリングテストである (少し表現違ったらごめんなさい)話の流れで、部屋を移動しなくていけなくて、たしか、それしか話ができなかったのですが、要するに、サンプリングテストである以上、全ての入力パターンをテストすることは不可能であり、できることは、限られたコストの中で、効率よく

    JavaScriptでソフトウェアの正しさを数学的厳密に証明してみた - yukobaのブログ
  • 1