私は現在、Pythonでライブラリとこのライブラリを使用する一連のプログラムを開発しています。単体テストでは、ライブラリから各モジュールをインポートし、その中のクラスとルーチンをテストする必要があります。それで問題ありません。すべてのテストを含み、開発中に実行するライブラリ モジュールをインポートする別のテスト ディレクトリがあります。
ただし、プログラムのテストに関しては、状況が変わります。テストするには、プログラム全体を実行する必要があります。プログラムは、ライブラリがインストールされていることを前提としています (以前のバージョンのライブラリを自分のマシンにインストールした場合、実際にはそうなる可能性がありますが、これはさらに問題を引き起こします)。現時点では、私のプログラムは、展開前に手動で実行する PYTHONPATH 定義を含むテストスイートによって実行されます (IOW、インストールは実行しません) が、正しく実行しているとは思いません。一般に、プログラムは完全に展開されたときに機能をテストする必要があると思いますが、これは、機能テストを実行するたびにプログラムをインストールする必要があることを意味します.
プログラム全体の機能テストに関するあなたの経験と提案は何ですか? 導入前または導入後にどのように行いますか?
ありがとう
意図的に python タグを含めていないことに注意してください。私の問題は python 固有のものであり、python 関連の回答を希望しますが、他の言語の専門家からも貢献できると思います。
編集：コメントで報告されているように、実際には、私のプログラムは、インストール時に、展開時にのみパスが見つかるモジュールをインポートする必要があります（依存関係をその場でダウンロードしてインストールしますが、マシンにはインストールされません）。テストから sys.path を操作することはできません。これは、プログラム (実行可能ファイル) の sys.path を別のプログラム (system() 呼び出しを実行して生成するテストスイート) から変更することを意味するためです。
言い換えれば、デプロイせずにプログラムをテストする唯一の方法は、PYTHONPATH を、make スクリプトによってインストールされた deps とプログラムが使用するライブラリを含むディレクトリに設定して実行することです (前述のように、ダウンロード、コンパイルします)。一時ディレクトリにすべてを「インストール」します)。
展開時に、dep と実行可能ファイルは、完全に実行可能で再配置可能な「OSX バンドル」のような構造にパッケージ化されます。
編集：
もう少しフィードバックが得られるかどうかを確認するために、150 のバウンティを追加しました。
編集：
私はすべての回答に感謝し、それらすべてに投票しました。この選択は私にとって難しい選択でしたが、LudoMC によって、私がずっと前に研究したテストへの V モデル アプローチが思い起こされました。非常に良い答えをありがとう。