8

FTP サーバー API のラッパーをテストするいくつかの単体テストを作成しました。

単体テストと FTP サーバーの両方が同じマシン上にあります。

ラッパー API はプラットフォームにデプロイされ、リモート処理と Web サービスの両方のシナリオで使用されます。ラッパー API は基本的に XML メッセージを使用して、ユーザーの追加/削除/更新、パスワードの変更、アクセス許可の変更などのタスクを実行します。

単体テストでは、ユーザーを仮想ドメインに追加するなど、API に送信する XML メッセージを作成します。API が機能し、操作が成功したか失敗したかに関するステータス情報 (エラー コード、検証の失敗など) を含む応答を返します。

API ラッパー コードが本当に正しいことをしたかどうか (応答が成功を示した場合) を検証するために、FTP サーバーの COM API を呼び出し、そのストアを直接クエリして、たとえばユーザー アカウントを作成するときに、ユーザー アカウントが本当に正しいことをしたかどうかを確認します。作成されます。

これって臭いですか？

更新 1: @Jeremy/Nick: ラッパーがテストの焦点であり、FTP サーバーとその COM API はサード パーティ製品であり、おそらく十分にテストされ、安定しています。ラッパー API は、XML メッセージを解析してから、FTP サーバーの API を呼び出す必要があります。ユーザー アカウントの特定のプロパティがラッパーによって正しく設定されていることを確認するにはどうすればよいでしょうか。これはばかげたケースかもしれません。たとえば、ラッパー コードのタイプミスが原因で、FTP アカウントのプロパティまたは属性が正しく設定されていません。アップロードとダウンロードの速度制限の設定が良い例です。これらはラッパー コードで置き換えられる場合があります。

更新 2:回答ありがとうございます。モックの使用を提案した人たちには、それは私の頭をよぎりましたが、ライトはまだそこにスイッチを入れておらず、FTPサーバーのモックでラッパーを動作させる方法を理解するのにまだ苦労しています. . モックはどこに存在し、そのモックのインスタンスをラッパー API に渡して、COM API を呼び出す代わりに使用しますか? 私はあざけることは知っていますが、ほとんどの例とチュートリアルが非常に抽象的で (恥ずかしいことに) 理解できないことに気づいているため、頭を悩ませています。

4

8 に答える 8

7

ユニットとコンポーネントのテストに関する懸念が混在しているようです。

  • ラッパーの単体テストを行う場合は、モック FTP サーバーを使用し、実際のサーバーは使用しないでください。プラス面は、通常、このように 100% 自動化できることです。
  • 全体 (ラッパー + FTP サーバーの連携) をコンポーネント テストしている場合は、テストと同じレベルで、つまりラッパー API を使用して、結果を検証してみてください。たとえば、ファイルをアップロードするコマンドを発行した場合、次にそのファイルを削除/ダウンロードするコマンドを発行して、ファイルが正しくアップロードされたことを確認します。結果をテストするのが簡単ではないより複雑な操作の場合は、あなたが言及した COM API の「バックドア」に頼るか、手動で検証することを検討してください (すべてのテストを自動化する必要がありますか?)。
于 2008-10-17T20:23:18.510 に答える
3

API ラッパー コードが本当に正しいことを行ったかどうか (応答が成功を示した場合) を検証するために、FTP サーバーの COM API を呼び出します。

すぐそこでやめなさい。FTP サーバーをモックする必要があり、ラッパーはモックに対して動作する必要があります。

テストがラッパーと FTP サーバーの両方を実行する場合、単体テストではありません。

于 2008-10-17T20:27:51.823 に答える
3

モック オブジェクトでラッパーをテストするには、次のようにします。

  • FTP サーバーの COM API と同じインターフェイスを持つ COM オブジェクトを記述します。これがモック オブジェクトになります。依存性注入を使用して、どちらかのインターフェイス ポインターをラッパーに渡すことで、実際の FTP サーバーとモック オブジェクトを交換できるはずです。
  • モック オブジェクトは、そのインターフェイス (FTP サーバー API を模倣する) で呼び出されるメソッドと、使用される引数値に基づいて、ハードコードされた動作を実装する必要があります。
  • たとえば、UploadFileメソッドがある場合、やみくもに成功の結果を返し、渡されたファイル名を文字列の配列に保存することができます。
  • ファイル名に「エラー」が含まれている場合は、アップロード エラーをシミュレートできます。
  • ファイル名に「slow」が含まれている場合は、レイテンシー/タイムアウトをシミュレートできます。
  • 後で、DownloadFileメソッドは内部文字列配列をチェックして、その名前のファイルがすでに「アップロード」されているかどうかを確認できます。

一部のテスト ケースの擬似コードは次のようになります。

//RealServer theRealServer;
//FtpServerIntf ftpServerIntf = theRealServer.getInterface();

// Let's test with our mock instead
MockServer myMockServer;
FtpServerIntf ftpServerIntf = myMockServer.getInterface();

FtpWrapper myWrapper(ftpServerIntf);

FtpResponse resp = myWrapper.uploadFile("Testing123");
assertEquals(FtpResponse::OK, resp);

resp = myWrapper.downloadFile("Testing123");
assertEquals(FtpResponse::OK, resp);

resp = myWrapper.downloadFile("Testing456");
assertEquals(FtpResponse::NOT_FOUND, resp);

resp = myWrapper.downloadFile("SimulateError");
assertEquals(FtpResponse::ERROR, resp);

これが役立つことを願っています...

于 2008-10-19T03:35:29.070 に答える
2

API に触れないことについては、Nick と Jeremy に同意します。APIのモックを検討します。

http://en.wikipedia.org/wiki/Mock_object

.NET の場合は、以下を使用できます:
Moq: http://code.google.com/p/moq/

およびその他の多数のモック ライブラリ。

于 2008-10-17T20:13:33.773 に答える
0

上位レベルの API が書き込み専用である場合に、下位レベルの API を使用して結果を検証することが理にかなっている場合を考えてみます。たとえば、高レベル API を使用してユーザーを作成できる場合は、ユーザー アカウントを取得するための高レベル API も必要です。それを使用します。

他の人々は、下位レベルの API をモックすることを提案しています。いいですよね、できれば。下位レベルのコンポーネントがモックされている場合、モックをチェックして正しい状態が設定されていることを確認しても問題ありません。

于 2008-10-17T21:07:23.757 に答える
0

「APIをテストする必要がありますか?」と尋ねているようには聞こえません。— 「API を使用して、ラッパーが正しいことを行っているかどうかを確認する必要がありますか?」

はいと言います。単体テストでは、ラッパーが API によって報告された情報を渡すことをアサートする必要があります。たとえば、あなたが与えた例では、APIに触れないようにする方法がわかりません。なので、臭くないと思います。

于 2008-10-17T20:20:13.383 に答える
0

ラッパーまたは API の何をテストしていますか。API はそのまま動作するはずなので、テストする必要はないと思います。ファイル アクセスを行うクラスを作成するときは、ストリームリーダーでビルドの単体テストを行いません...コードに集中します。

于 2008-10-17T20:05:53.007 に答える
0

テスト時には、API をデータベースやネットワーク接続と同じように扱う必要があります。テストしないでください。あなたの管理下にはありません。

于 2008-10-17T20:08:50.880 に答える