テスト用の設定値を注入してあげましょうサンプルコードはこちらgithub.comもうちょっと詳しく背景PythonでDynamoDBを使った開発していればPynamoDBはとても便利なライブラリです。非常に書きやすいAPIでDynamoDBを読み書きできますし、手軽にテーブル自体もPynamoDBで作成することも可能です。みたいな条件を書いて毎回判断させたり、キャパシティの調整のたびにアプリケーションを動かす必要が出てきてしまいます。中で定義するあたりがよく採用される方法かと思います。Codeな方法で管理することでしょう。すると当然、PynamoDBを使ったアプリケーションコードの中にはキャパシティに関する記述は残したくありません。アプリケーションを動かす際はそれでOKですが、テストを書くときに少し面倒なことになります。ような処理を書きたくなると思います。endpoint_urlを指定したのと同じ効果が得られます。書けば、テスト時と本番とで設定を打ち分けることは出来そうです。アプリケーションのコードに「これはテスト実行かどうか」を判定する条件文が入るのは好ましくありません。ように作成したオブジェクトに切り替えることで、比較的簡単にアプリケーションからテストのためのロジックを追い出すことが可能でしょう。PynamoDBを使っている場合は、APIを実際に叩く部分はライブラリの中に隠蔽されてしまい、オブジェクトの切り替えによるテストが難しくなってしまいます。テスト用のテーブルをどう作成するかという問題もあります。PynamoDBモデルを書いたのだから、できればうまく再利用したいものです。キャパシティに関する指定がないとエラーになります。するとまたアプリケーションに「テストのためのロジック」が混入してしまいます。そこで、今回はアプリケーションのコードにテストのためのロジックを入れないPynamoDBのモデル定義をテスト用のテーブル作成に活用するを同時に達成できるテストの書き方を考えてみました。やってみるサンプルのテーブルの定義はこんな感じです。UnicodeAttribute()それっぽいテストコードを書きたいので、Repositoryパターンっぽく包んでみます。write_capacity_unitsの設定がないのでAttributeErrorになります。そこで、pytestのfixtureをこんな感じで書いてみます。テスト用のテーブル名に名前を上書きといった操作をしています。+FastAPI」の開発環境を作った際に「せっかくserverless.ymlのなかでスキーマ定義してるのに、結局PynamoDBでテーブル作るためにモデル定義に余計なコードが混ざってしまうなあ...」という問題が残っていました。tech.jxpress.netこの問題も、本記事と同じ方法でローカル開発用(≠テスト用)のテーブル作成スクリプトをアプリケーションコードとは別に切り出すことで解決できそうですね。以下のコードだけ載せておけば良いので、「アプリケーションに余計なコードが混ざらない」を達成できます。スクリプトの中身はほとんどpytestの中身と同じです。」「PynamoDBのモデル定義をテスト用のテーブル作成に活用する」を達成することができました。参考になれば幸いです。11:00Tweet関連記事2020-09-02IstioとAuth0でJWT認証付きAPIを5分でデプロイするSREのたっち(@TatchNicolas)です。パターン...取締役の小笠原(@yamitzky)です。Corp.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。