概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
SREの菅原です。 この記事はカンム Advent Calendar 2022の4日目の記事になります。 少し前にサービスで使っているPostgreSQLをRDSからAuroraに移行しました。 Auroraに移行するため色々と作業を行ったのですが、その中でAuroraの性能を測るために行った負荷テストについて書きます。 pgbench まず最初にpgbenchを使って、単純なワークロードでのRDSをAuroraの性能差を測ってみました。*1 以下がその結果です。 MySQLで同様のテストをmysqlslapを使って行ったことがあって、そのときは概ねAuroraのほうが性能が高かったので、同様の結果になると考えていたのですが、RDSのほうが性能が高い結果になったのは予想外でした。 ただAuroraのアーキテクチャを考えると、pgbenchのような細かすぎるトランザクションの場合はRDSのほ
あなたが知らない既存機能があるかもしれません! マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く