DBを使ったインテグレーションテストを10分から3分に短縮 —— TRUNCATE廃止とDBプール導入
こんにちは！ソフトウェアエンジニアの inari111 です。 前回の記事 ではDBを使ったインテグレーションテストの導入についてご紹介しました。 その記事の最後で「速度の改善については別の記事で書きたい」とお伝えしていましたが、今回はその続編です。 インテグレーションテスト導入後に見えてきた課題を原因ごとに分解し、それぞれどのように改善したかについてご紹介します。 前提: インテグレーションテストの実行方式 DBにはMySQLを使っていて、バックエンドはGoで実装しています。 詳しくは 前回の記事 をご覧いただければと思いますが、改善前のインテグレーションテストの実行方式を簡単に振り返ります。 テスト関数単位で並列実行 テスト関数ごとに専用のDBを作成し、t.Parallel() で並列実行 テストケースごとにTRUNCATE 同一テスト関数内のテストケース間では全テーブルを TRUNC
PlaywrightではじめるE2Eテスト入門（前編） - ICS MEDIA
フロントエンド開発では、UIの動作を含めてアプリ全体を検証するE2E（End-to-End）テストの重要性が高まっています。一方で、E2Eテストは導入や運用のハードルが高いと感じられがちです。本記事では、Playwrightを使って無理なくE2Eテストを始める方法を解説します。 PlaywrightプレイライトはMicrosoftが開発するE2Eテストツールです。テストはTypeScript（およびJavaScript）で記述できるため、ウェブ開発で馴染みのある言語の知識をそのまま活かせます。 主要なブラウザを単一のAPIでテストできる点や、テストを高速に実行できる点が評価されています。私たちICSでも、Playwrightの導入経験があります。既存機能に改訂の影響が出ていないことを確認する、いわゆるリグレッションテストの目的で活用しています。 本記事では、前後編に分けて、シンプルなウェブ
GitHub - goccy/tobari: Tobari is a scoped coverage measurement tool for Go
Tobari is a scoped coverage measurement tool for Go. "Tobari" (帷) is a Japanese word meaning "curtain" or "veil," similar to the English word "cover". Tobari provides coverage measurement capabilities that introduce a new concept called Scoped Coverage in addition to the coverage features provided by runtime/coverage. This feature enables clear mapping between test code and its impact area, allowi
E2EテストをSaaSからPlaywrightへ移行する - KAKEHASHI Tech Blog
はじめに こんにちは。Musubi Insightチームでエンジニアをしている中村です。 Musubi Insightでは、SaaS型のE2Eテストツール mabl で14のテストを運用していましたが、認証の安定性やコード管理の面でいくつか課題がありました。 昨今のフロントエンド開発では Claude Code などのAIエージェントと Playwright MCP を組み合わせ、コード修正から動作確認までをPlaywrightベースで回すワークフローが選択肢として広がりつつあります。こうした背景もあり、チームでPlaywrightへの移行を進めることになりました。 本記事では、移行にあたってのテストアーキテクチャの設計と実装パターン、移行の進め方について紹介します。 Musubi Insightについて Musubi Insightは薬局向けのBIツールで、処方データや薬歴データを集計・
go-txdbを使ったDB接続を伴うテスト
はじめに 本日は我々のチームで行なっている、go-txdbを使用したリポジトリ層のテストについて紹介します。 go-txdbとは go-txdbは、データベースのテストを効率的に行うためのGoライブラリです。 go-txdbの特徴は、各テストケースが自動的にトランザクション内で実行され、テスト終了時に自動的にロールバックされる点です。これにより、テスト間でのデータの干渉を防ぎ、クリーンな状態でテストを実行できます。 メリット 実際のSQLの妥当性を確認できる モックを使用したテストでは、SQLの妥当性を厳密にテストする事が困難です。go-txdbを使用したテストでは、実際のデータベースに対してクエリを実行するため、SQLの妥当性にまで検証観点を及ばせることが可能です。 デメリット テストが実DBに依存する テスト用にDBが必要となり、純粋な単体テストとは言えなくなります。我々のチームではD
Go’s synctest is amazing | Oblique
We threw Go’s new “testing/synctest” package at a particularly gnarly part of our codebase and were pleasantly surprised by how effective it was. This post covers the synctest package, its nuances, and how it does much more than speed up your tests. The main headline for Go 1.25’s synctest is its ability to magically advance time. Tests run in a “bubble” with a fake clock and calls to time.Sleep a
GitHub - google/go-cmp: Package for comparing Go values in tests
This package is intended to be a more powerful and safer alternative to reflect.DeepEqual for comparing whether two values are semantically equal. The primary features of cmp are: When the default behavior of equality does not suit the needs of the test, custom equality functions can override the equality operation. For example, an equality function may report floats as equal so long as they are w
DBを使ったインテグレーションテストを導入し、モック中心のテストから脱却した
こんにちは！ソフトウェアエンジニアの inari111 です。 この記事では、RemitAidでDBを使ったインテグレーションテストを導入した背景、方針、得られた効果について紹介します。 はじめに DBにはMySQL, Redisを使っていて、バックエンドはGoで実装しています。 この記事で登場する各テストに関しても説明しておきます。 ユニットテスト 関数やメソッドなど最小単位のコードが正しく動作するかを検証するテスト 外部依存(DB、APIなど)はモックに置き換え インテグレーションテスト 複数のモジュールを組み合わせた状態で正しく連携するかを検証するテスト DBアクセスや外部API呼び出しを含む場合もある インテグレーションテスト導入前 もともとRemitAidではユニットテストのみを書いていました。 外部依存(DB、APIなど)はモックに置き換えているため高速に実行できていました。
AI時代を見据えたGoのコードカバレッジ計測ツールを作った - Route54
Motivation AIにより開発速度が上がっている一方で、その品質保証を人間が担う部分で律速になる課題がある。 大量に作成されたPRのレビュー、人手で行うQAなどに代表される品質保証をどのように省力化するかが問題となる中、 品質を保証し得る必要十分なテストケースを作成し、それを通過していることをもって保証する方法があると考えている。 ここで、必要十分なテストケースの定義を「テストカバレッジが100%に限りなく近いこと」と定義し、 そのテストケースを効率的に自動生成することはできないかと考えた。 Go のコードカバレッジ計測ツールが抱える課題 「Go の」とは書いているが、他言語も含め一般的なコードカバレッジツール全般に言える話だと思う。 計測粒度の課題 Go が提供するコードカバレッジの計測手段は、Go 1.25 現在で大きく2通りある。 ひとつは go test を使って計測する方法
Go 1.25 testing/synctestの使い所とは? もう非同期処理を含むテストで悩まない
こんにちは @glassmonekey です。 先日のGo Conference 2025ではencoding/json/v2についてトークをしました。 旬な機能繋がりではないですが、今回はGo 1.25で正式に導入されたtesting/synctestについて紹介します。 並行処理のテストは、タイミング依存で不安定になったり、time.Sleep()で適当に待ったりしがちです。testing/synctestはそんな悩みを解決してくれますが、すべてのケースで使えるわけではありません。便利そうな反面、使い所がわからず迷っていたので、この記事では向き不向きを整理してみました。 TL;DR testing/synctestは並行処理を決定論的にテストできるパッケージです。 できること： 時間制御（30分のタイムアウトのテスト一瞬で終わる） 決定論的なテスト実行（タイミング依存を排除） チャネル
Goのテスト結果をtparseで整形する・GitHub ActionsのJob Summaryと組み合わせる - 私が歌川です
あらすじ go test が出力するログはシンプルです。シンプルなのはいいんですがテストサマリ的な情報が乏しくて、ログを全部見返さないとどのテストが落ちたのか分からなくなりがちという問題があります。 tparseというツールを使うと、go test を使いつつテストサマリが見れるようになるので紹介します。 tparseについて tparseは、go test の出力をパースして人間に分かりやすいサマリを生成してくれるツールです。 github.com 最も簡単な使い方としては、READMEにあるように go test の出力をそのままパイプする (あるいは一時ファイルを経由する) ことで動作します。 % set -o pipefail && go test ./... -json | tparse -all # あるいは % go test ./... -json > fmt.out %
tparseでgo testの出力を見やすくする
明日から使えるgo test実践テクニック集 https://findy.connpass.com/event/375530/
DB へのアクセスを伴う単体テストの考え方と Go による実践 - Cybozu Inside Out | サイボウズエンジニアのブログ
この記事は、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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - DATA-DOG/go-txdb: Immutable transaction isolated sql driver for golang
GitHub - k1LoW/runn: runn is a package/tool for running operations following a scenario.
GitHub - mfridman/tparse: CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.
testdata ディレクトリを活用しよう！
The Power of Go: Tests — Bitfield Consulting
Don't mock the database: Data fixtures are parallel safe, and plenty fast | Crunchy Data Blog
Flaky tests, be gone: long-lasting relief for chronic CI retry irritation!—Martian Chronicles, Evil Martians’ team blog