駅メモ！開発基盤チームの id:xztaityozx です。 今回はテスト実行のボトルネックを OverlayFS を利用することで解消した話と、OverlayFS の動作を調べるためにbpftraceを使った話をします。 かんたん概要 Test::mysqldを使って挿入済みのデータを持ったmysqldをテストごとに起動していた データが増えてきたことでコピーがめちゃくちゃ遅くなり、開発体験が最悪になった コピーを OverlayFS でのマウントに置き換えてすごく速くした 動作について気になる点があったのでbpftrace を使ってトレースを行い、カーネル関数の呼び出しも観察した 前提 この記事で登場する主なツールのバージョンを示します Ubuntu 22.04.4(WSL2) カーネル: 5.15.146.1-microsoft-standard-WSL2 hyperfine 1.1

PHPカンファレンス小田原2024での発表資料です https://fortee.jp/phpconodawara-2024/proposal/4d39c7ef-058c-4648-b1d7-5510497e0d81

はじめに かれこれ１年以上前のことになりますが、今の開発組織でデータベースに接続するJunitを使ったIntegrationTest1 を開発者のPCとCIで実行できる仕組みを作りました。 トライしたきっかけと想い 仕組みの設計・導入をする時に気を付けたこと 具体的な実現方法 トライしてみて感じたこと を記載します。 トライしたきっかけと想い 私が保守開発を担当しているプロダクトは20年近く運用されているWebアプリケーションです。(サーバーサイドはJava) 単体テストの仕組みと文化が無いまま長期間運用されており、大半のコードがレガシーコードという状態でした。 一部テストが書かれている箇所もありましたが、CIでの実行の仕組みはなく腐ってしまっているものも多い状態でした。 そこに @autotaker1984 さんがCIでの単体テスト実行の仕組みを作ってくれて、単体テストを書くべきというマ

いきなり結論を書くと、idやclassはスタイルのためのものなので、テストでそれを使うのはやめましょう。そして、カスタムデータ属性を使いましょう。(idやclassはスタイルのためだけではないという意見はごもっともです！しかし、主にとしてスタイルに使われるということでご了承頂いて以下の駄文に付き合って頂けると幸いです🙇) 先に断っておくと主にreactについての話で、JSXを前提とします。(手法はReactに限りませんが理由は後述) 2020/03/23 追記 この記事は1年以上前に書かれた記事なのでテストフレームワークとしてenzymeを使っていますが、現時点ではTesting Libraryの使用をオススメします。data-testid に対応するクエリを備えています。 React Testing Library · Testing Library はじめに ご存知の通り、ロジックと

PHPerKaigi 2024発表資料 https://fortee.jp/phperkaigi-2024/proposal/f23f927e-2ac8-498e-a047-6376831cbd07

Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド

YAPC::Hiroshima 2024

新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと！！！」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker

この記事は クラスター Advent Calendar 2023 19日目の記事です。 昨日は ChameleonO2 さんの「何か」でした。公開楽しみですね。 クラスター株式会社でソフトウェアエンジニアとして働いている id:Sixeight です。 クラスターではトランクベース開発を実現するためにフィーチャフラグを使っています。 フィーチャフラグを使うことでたとえ開発が途中であっても、変更は完全に動作する状態でトランクに取り込まれます。 今回はフィーチャフラグを使って開発するときに意識しているささやかなTIPSを共有します。 TIPS1: 元のコードはそのままにする フィーチャフラグで分岐を追加するときに、気を利かせて安易にコードの重複を減らそうとしてはいけません。 たとえコードが重複することになったとしても、変更前のコードは出来るだけそのままの形で残るようにしましょう。 なぜならフィ

こんにちは。ＮＴＴテクノクロスの際田です。普段は社内の開発プロセス効率化、テスト自動化周りの支援に携わっています。 最近、ラムダノート株式会社の『実践プロパティベーステスト -PropErとErlang/Elixirではじめよう-』という本を読んで、プロパティベーステストという手法を知りました。 せっかく読んだしやってみよう、と思ったのですが、この本の例はErlang/Elixirという通好み(?)な言語なので、お仕事でも使えそうな言語でできないかと考えました。調べたところ、fast-checkというJavaScript/TypeScriptのライブラリがあるようなので、こちらを使ってプロパティベーステストをやってみたいと思います。 プロパティベーステストとは プロパティベーステストとは、自動テストの手法の一つで、「システムのあるべき挙動を満たす条件」をプロパティと呼び、その条件を満たすで

こんにちは。サービスGの金谷です。 JestにはspyOnという便利なメソッドが用意されています。 Jestオブジェクト · Jest これを使うとJestでのテスト時に指定したメソッドがコールされているかどうかを確認できたりします。 具体的な使い方のイメージは先輩が書かれているこちらの記事が参考になると思います。 jest.spyOn() で Vue.js コンポーネントからのサービス呼び出しをテストする 公式ドキュメントを見ると第一引数にObject、第二引数にメソッド名（文字列）を受け取ると書かれています。 jest.spyOn(object, methodName) では、オブジェクトのメソッドではない、ファイル直下でexportされている関数にはどう使ったらいいの・・・？ と思ったので調べてみました。 以下のようなコードを想定します。 helloWorldService.ts e

追記 2022/11/12 追記 この記事読んで、DI 便利だなって思ったらこちらも併せて読んでみてください。クリーンアーキテクチャーの開設の中で依存性逆転の説明が出てきます。難しいかもしれませんが、一度理解すればつぶしが効く考え方なので腰を据えて読んでみてください。 本文 ここでは、最近のそこそこの規模のアプリだと大体使われてる（と私は思ってる）Dependency Injection（DI）について、何故使ってるのか？というのを私の理解で書いていきたいと思います。 今回の対象言語は C# ですが、DI 使ってる言語であれば大体同じ事情なのかなと思います。 単体テストしたいよね アプリケーションを作るとうまく動いているかテストをすると思います。 たとえ、そのアプリがハローワールドだとしても動かして目視で確認してると思います。 もうちょっとアプリの規模が大きくなってくるとクラス単位やクラス

という考えにたどり着いたので、考えのスナップショットをとっておく。 Go言語における、テスト関数名とサブテストのname引数の値を「テストケースの名前」・「テスト名」と呼ぶことにしている。 (*testing.T).Run(name string, f func(t *testing.T)) bool テスト名に近いものとして、(*testing.T).Errorや(*testing.T).Logの引数がある。これらはテスト実行時の出力に含まれるが、テストケースを分かつものではない。あくまで、特定のテストケース内の情報を増やすものだ。対するテスト名は、（通常は）テストケースを分割できる最小単位である。 テストケースがテスト名の単位で存在するということは、テスト名はそのテストケースを十分に表現できていたほうがよいということだ。さもなくば、検証・変更しようとする仕様に対応するテストケースや、実

もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」