web-dev-qa-db-ja.com

APIの自動テストにおける永続層

APIの自動テストは、安定していて簡単である必要があります。

APIの自動テストを作成するとき、このAPIを実装するプログラムで作成されたデータが永続的であることを確認する必要があることがよくあります。持続性レイヤーが直接チェックされる場合（例：データベース）、テストはこの持続性レイヤーの使用に関連付けられており、頻繁に中断する可能性があります。

テストを中断することなく実装を変更できるように、APIを使用してデータが永続化されていることを確認します。

例

ユーザーを追加するためのAPI「myfakeapi.com」をテストしているとしましょう。このJSONファイル "user.json"があるとします。

{
  "name": "Harry"
}

...そして、このテストスクリプト：

#!/bin/bash

# Deleting all the users
curl -X DELETE https://myfakeapi.com/users

# Adding the new user, returns {"id": 1, "name": "Harry"}
curl -X POST -H "Content-type: application/json" --data-binary "@user.json" https://myfakeapi.com/users

# Checking that the user was saved, returns {"id": 1, "name": "Harry"}
curl -X GET -H "Content-type: application/json" https://myfakeapi.com/users/1

テストは成功したと言えます。それに加えて、実装が変更されても壊れません。

問題は、myfakeapi.comがユーザーをデータベースに保存していることを証明するものがないことです。実際、ユーザーをメモリに保存することでテストに合格する可能性があります。最後に、永続層を直接チェックすることは適切なソリューションでしたか？

私はそうは思いません（編集：後で気が変わった）。

質問

APIのユーザーの観点から見ると、持続性とはプログラムの再起動があってもデータが失われないことを意味します。これはまさに私がテストしたいものです。

私の質問：永続性をチェックするために、テストセッション中にAPIを実装するプログラムを再起動しても大丈夫ですか？

testingapitdd
1
kerrerain

APIユーザーとして、書き込み（POST/PUT/DELETE）がアドバタイズされた効果を持ち、読み取り（GET）が期待されるデータを提供することのみを気にします（さまざまな要求間の時間は要因ではありません（タイムアウトとして明示的に文書化されていない限り） ）。

方法 APIのプロバイダーは、時間が無関係であることを確認します。私に関する限り、実行可能ファイルが停止しないことを確認できれば、すべてのデータをRAMに保持できます。

APIのimplementerなので、RAMだけでなく、より永続的な方法でデータを格納する必要があるかもしれません。

テストの観点から見ると、これはAPIテストがAPIが期待どおりに機能することを確認する必要があることを意味しますが、本番環境のAPIユーザーが実行できないアクション（プログラムの再起動など）を日常的に行うべきではありません。

永続化戦略が正しく機能するかどうかをテストします。ソフトウェアの単体テスト、コンポーネントテスト、統合テストで見つけることが期待されます。

2
Bart van Ingen Schenau