こんにちは、ソフトウェアエンジニアの渡邉（匠）です。 「カミナシ 設備保全」の開発に携わっています。 以前、「40,000行のAPIテスト作成で学んだClaude Code Skillsの育て方」という記事を書きました。 AI を使って大量の API テストを生成した話です。 今回はその土台になっている、テストそのものの構成を紹介します。 私たちのバックエンドの API テストは、数十のAPIを対象に、200 本を超えるファイル、1,000 件を超えるテストケースまで育ちました。 本記事の主題は、テストフレームワーク runn で書いた runbook の設計、なかでも「何を確かめるか」と「どう呼ぶか」を分ける部品化です。 まず土台となる、runn を go test に埋め込む実行基盤を紹介した上で、本題の runbook 設計に入ります。 runn を go test に組み込む ru
In my first job as a software engineer the project I was working on grew out of control. As often happens, use cases were added without proper refactoring and with more users we were drowning in support tickets and nothing seemed to work. It was clear we needed to push for quality so we started adding unit tests. The tech lead at the time mandated high test coverage. But here's the reality: writin
I was reading a blog post about the testing strategy for the Wild linker, when I came upon a link to cargo-mutants, a mutation testing tool for Rust. The tool promised to be easy to set up, so I gave it a try. I'm happy to find that it totally delivers! Briefly: mutation testing catches cases where bugs are deliberately inserted in the source code, but the test suite fails to catch them: after mak
Node.jsでSQLを高速に単体テストするライブラリ @rawsql-ts/pg-testkit を紹介します。 生SQLは当然として、PrismaやDrizzleなど既存ORMとも併用可能で、既存アーキテクチャを壊さず導入できます。 従来の問題点 SQLの単体テストを行う場合、一般的には以下の手順で行います。 マイグレーション（テーブル環境構築） シーディング（テストデータ投入） テスト クリーンアップ（ロールバック、テーブル環境破棄） 通常の単体テストと異なり、マイグレーション、シーディング、クリーンアップという工程が必要です。 さらに、DBという共有ストレージを使用するため、テスト間の競合に注意が必要です。 上記の問題を回避して高速化するのは難しく、現状では DBインスタンスをたくさん立てる DBにスキーマをたくさん作る テストデータが競合しないように気を付ける といった力業に頼る
This article explains an approach to dotfiles management that emphasizes testability, using the author’s dotfiles repository shunk031/dotfiles as a case study. Table of Contents Introduction Dotfiles and Dotfiles Repositories The dotfiles refer to configuration files that start with a “.” (dot) such as .bashrc, .vimrc, and .gitconfig. In recent years, dotfiles repositories that manage these files
この記事は、CYBOZU SUMMER BLOG FES '25の記事です。 クラウド基盤本部の新井です。 この記事では、DB へのアクセスを伴う Go の単体テストについての私たちの考え方、そしてそれを実践するために開発・公開したライブラリをご紹介します。 DB のモックとその問題点 DB へのアクセスを伴う Go のプログラムをどのように単体テストしたいとき、最初に思いつくのは go-sqlmock などのツールを使って DB をモックする方法です。 サンプルコードでは、次のようなテストを書いています。 package main import ( "fmt" "testing" "github.com/DATA-DOG/go-sqlmock" ) // a successful case func TestShouldUpdateStats(t *testing.T) { db, mo
はじめに 先日、Go Conference 2025に行ってきました。 様々なセッションを聞く中で、特に興味を持ったトピックがtesting/synctestパッケージです。 これを取り上げているセッションが2つもありました。 名前は聞いていたが、詳しくはよく知らなかったパッケージでした。 話を聞けば聞くほど、「なんかすごいけど、なんでこれ(synctest)ですごくなるん？」で頭がいっぱいになってしまいました。 セッションでも話されていたため、なんとなくはわかった（気分になっていた）が、もっとこの技術に納得感を持ちたかったために、個人的に腰を据えてコードリーディングをしてみることにしました。 その結果筆者が感じたのは、 testing/synctestパッケージが新しく生えただけですごくなったのではない、そもそもGoランタイムがこのパッケージに合わせて書き換えられているからすごくなってい
筒井（@ryu22e）です。今月の「Python Monthly Topics」は、Web APIのテストデータを自動生成してくれるツール「Schemathesis（スキーマセシス）」を紹介します。 Schemathesisとは何か Schemathesisは、OpenAPIまたはGraphQLで書かれたAPI仕様を元にテストデータを自動生成し、実際にそれらのテストデータを使ってAPIを呼び出すことで、仕様通りの挙動になっているか検証できるツールです。 Schemathesisを使う利点は以下のとおりです。 人間が書いたテストコードでは気付けないエッジケースを見つけられる 仕様書と実装の乖離に気づくことができる Schemathesisの使い方 では、実際にSchemathesisを使ってみましょう。Schemathesisの使い方には、主に以下の2つがあります。 pytestと組み合わせ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
