私は、ActionScript 3.0 と呼ばれる一般的なコード ライブラリに取り組んでいますas3lib。これには、コア API に対するいくつかの拡張機能といくつかの便利な機能が含まれています。すべてが正しく機能していることを確認するために、(FlexUnit を使用して) いくつかの単体テストを作成しました。
ライブラリでこれらのテストを整理する最良の方法は何ですか? 現在、すべてのコードsrc/とテストが含まれていますが、単体テストtest/を実行するための 2 つ目の Flex プロジェクトをセットアップしました。また、テストを実行するときに、ライブラリからテスト ファイルを手動で追加および削除しています。
私がしていることは正しくないようです。より良い方法はありますか？コンパイルされたライブラリにテストファイルが含まれていないものが望ましいですが、それらをテストするために2つの別々のプロジェクトは必要ありません。
私の会社でこれらのことを行った方法は、実際にはソース ディレクトリの下に両方を含め、使用する 2 つのアプリケーション mxml ファイルを用意することです。1 つは単体テスト クラスへの適切なリンクをすべて含むテスト スイートで、もう 1 つはメイン アプリケーションです。また、src フォルダ内には 2 つのパッケージ構造があります。1 つのパッケージ構造は com.. で、もう 1 つの tests.com...ユニット テストのすべてのソース コードが常にtests パッケージにあることを確認してください。この方法で使用できます。 1 つの SVN のみが無視され、テストが他のプロジェクトとの依存関係やハードコーディングされた関係を作成しないようにすることもできます。
test.com ソース ファイルが含まれていないことを確認するために使用する 2 つの方法があります。自動ビルド システムはメイン アプリケーションのみを参照し、com. からのみインポートするため、mxmlc.exe にはメイン アプリケーションのファイルのみが含まれます。Eclipse 内でローカルにビルドする場合、[デバッグ] の横にある小さな矢印をクリックし、[お気に入りの整理] までスクロールして、ビルド方法を制御できます。[追加] をクリックすると、アプリケーション クラスを参照するすべてのルート レベルの .mxml ファイルを選択できるはずです。ベース アプリケーションと新しい単体テスト アプリケーション ファイルを必ず追加してください。次に [OK] をクリックすると、矢印を使用して、メイン アプリケーションとして、または単体テスト フレームワークとしてデバッグできます。
余談ですが、テスト フレームワークとして FlexUnit も使用しています。それはいいですね。
ここでは流れに逆らって、テスト用にまったく別のプロジェクトをセットアップすることを提案します。一貫性があり、ある程度扱いやすいものである限り、一般的に、テストをどこに置くかは問題ではないと思います。しかし、私には、テスト用に別のプロジェクトを用意する理由が 3 つあります。
関心事の分離。まず、ライブラリには 1 つの目的があり、テストには別の目的があります。テストが機能するにはライブラリが必要ですが、ライブラリはテストに実際には使用されません。テストが役に立たないと言っているわけではないことに注意してください。テストはライブラリの正常性を確認するためにありますが、実稼働環境ではテストは何の役にも立ちません。
肥大化が少なく、ファイルが小さくなります。テストは必ずしも簡単ではありません。しかし、それらがすべてあったとしても、まだディスク容量を使用しています。いずれにせよ、テストは本番環境では使用されないため、これは無意味です。また、テストを新しいプロジェクトに分割すると、ファイル構造がよりきれいになります。
一般に、CI 環境は、テストが行われていない場合にセットアップするのが簡単です。
少なくともコンパイラ ディレクティブで 2 番目の問題を解決できる可能性は確かにありますが、この 2 つを分離する方がはるかに簡単な場合は不要な作業です。テスト プロジェクトが名前空間をミラーリングする可能性があるため、同じ名前空間 (内部クラスの誰か?) を使用する必要がある可能性があるライブラリまたはアプリケーションをテストすることも問題ではありません。明らかに、これにより名前空間で名前の衝突が発生しないようにする必要がありますが、それは些細なことです。
Flash Builder のサポートに関しては、物事を 2 つのプロジェクトに分けることは素晴らしいことです。新しいテストを作成するために必要なのは、テストしたいクラスを右クリックし、新しいテストを作成するように依頼し、ポップアップするダイアログで現在のプロジェクトではなく、テスト プロジェクトを選択することです。これこそが、私とチーム メンバーが TDD を始めたときにテストを書くことを正当化するのに苦労した主な理由です。現在の IDE の状態では、非常にシンプルで便利です。
ただし、他の手法と同様に、注意事項があります。1 つには、ドキュメント化されていない限り、テストが別のプロジェクトにあることは明らかではありません。テストを同じプロジェクトに置くことで、その問題を効果的に分類できます。一方、これは、環境にある可能性のあるmavenまたはその他の依存関係管理ツールを構成することで簡単に解決できます. もう 1 つの問題は、ライブラリまたはアプリケーションのパッケージ構造をミラーリングするテスト プロジェクトにパッケージ構造がある場合、それらの構造を同期させるためにメンテナンス オーバーヘッドが発生することです。大きな問題ではなく、スクリプトを使用して簡単に解決できますが、言及する価値はあります。
とにかく、それは私がそれを行う方法です。
ライブラリの最上位には、src と tests のディレクトリが別々にあります。私たちのアプリケーションは、ライブラリ プロジェクトの非常に薄いラッパーであるため、テストは必要ありません。FlexBuilder からテストを実行するための FlexUnit アプリケーション プロジェクトもあります。
メインのビルド システムには maven を使用し、Sonatype Flex プラグインはビルド中にすべてのユニット テストを実行します。これは、Linux ベースの Continuum サーバーでも同様です。Maven はデフォルトで「tests」ディレクトリでテストを検索します。これは、その場所を選択する正当な理由でした。
私はあなたが過去に説明した方法と同様にそれを行いましたが、構成からそれらを動的に追加および削除するためにSpringASが非常に便利になるようなものです。それについて調べてみましたか？