Next.js 13 結合テストに挑戦してみた
Next.js 13 新機能の App ディレクトリの勉強がてら、結合テストをどう書いていったらよいか考察しました。参照している公式ドキュメントが beta 版なのはもちろん、App ディレクトリそのものが beta 版なので、実運用には使えるものではないと思うので予めご了承ください。一応こんな感じで書けそう、という話です。 結合テストの準備 本稿が指す結合テストとは、App ディレクトリのルートセグメントを構成する、特別なファイル（Special Files）が、与えた状態に応じてどのように表示されるかを検証するテストを指します。 ルートが外部から受ける要因として大きいものが、URL に含まれるクエリパラメーター・パスパラメーターです。コンポーネントは、これらの値を参照して API サーバーにリクエストしたり、ORM ライブラリからクエリーを発行したりなど、コンポーネント表示に必要な処理
jestでDBありのテストを高速化する
課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t
Strykerを使ってTypeScriptでMutation Testingする
概要 JavaScript/TypeScript向けのMutation Testing FrameworkであるStryker-jsがいい感じになってきたので紹介してみます。簡単な紹介のみです。 対象読者 Strykerの概要を知りたい人 Mutation Testingよく知らないJSer/TSer Mutation Testing導入したいけどJS/TS用のツールが見つからなかった人 Mutation Testingとは テスト対象のコードを変更(Mutate)するミュータントを仕込み、Unit Testが正しくそれらのミュータントを退治できるか測定するものです。 一般的には退治できた割合が高いほど意味のあるUnit Testを書いていると言えます。 Wikipediaの項目にもある通りFuzzingの一種とも言えます。 Mutation Testing自体はGoogleが論文出してた
「スタートアップだからテストを書かない」は正しいか - An Epicurean
スタートアップのCTOクラスの人がたまにそういうことを言っているのを聞くことがあります。もしくは「スピード優先だからテストを書かない」等です。 それは真ではなく、言ってしまえば、未熟だからテストを書「け」ない、のではないでしょうか。ただ、スタートアップという言葉に未熟であるという意味が含まれているのであれば「スタートアップだからテストを書かない」という問は真になるかも知れません。スタートアップは得てして未熟なものだし、それでも良いからです。 テストを書かないというジャッジをするのは構いません。でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。状況のせいにするのではなく、徹底的に自分ごと化する。それがスタートアップに求められる姿勢です。少なくとも技術のトップが自分たちの技術力に向き合わないのはまずいでしょう。 「スタートア
Drone and Docker, Open Source CI · drone.io
Posted by Brad Rydzewski on 2014-02-05 Today we’re excited to announce an open source edition of the Drone CI server! You can find the project at github.com/drone/drone And a very nice writeup in VentureBeat by Jordan Novet: Drone.io’s shift hints at the future of sending software to clouds Built on Docker We believe containers have a bright future and we’re ready to make a big bet on Docker. Dr
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
テストにコケる度にシーザーが死ぬ仕組みを作りました - その手の平は尻もつかめるさ
タイトルは釣りです。 App::WithSound をリリース致しました。 https://github.com/moznion/App--WithSound https://metacpan.org/module/MOZNION/App-WithSound-v1.0.2/with-sound (2013.03.06 追記) App::WithSound はv1.1.0 にバージョンアップしました。 コマンドの成功・失敗時だけでなく、コマンドの実行中にも音声を再生出来るようになっています。 https://metacpan.org/module/MOZNION/App-WithSound-v1.1.0/with-sound (追記ここまで) App::WithSound? コマンドが成功するか失敗するかによって、その結果に対応した音声が流れるアプリケーションです。 まず、このモジュールはm
テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる, tDiary 3.0.2 リリース - 会長@腹部日記(2011-04-29)
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
whitewashing.de :: Test your Legacy PHP Application with Function Mocks!
Much talking is going on about Unittesting, Mocks and TDD in the PHP world. For the most this discussions surround object-oriented PHP code, frameworks and applications. Yet I would assert that the reality for PHP developers (me included) is dealing with PHP 4, PHP 5 migrated, or non-object oriented legacy applications which are near to impossible to bring under test. Still this code works, is in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
