2

gruntjsをタスク ランナーとして、mochajsをテスト フレームワークとして使用してテストしている、expressjsに基づくnodejsアプリがあります。したがって、CI プロセスの一部としてデプロイ中にテスト VM を開発し、テスト VM でローカル経由またはローカル経由で直接実行されるコンポーネント、統合、単体テストを作成しました。grunt testmocha test/component/v1/apiX

このアプリを AWS Lambda に移行すること、つまりサーバーレスaws-serverless-expressにすることを考えると、テストと CI プロセスに関して次のような疑問が頭に浮かびます (ラムダ関数を使用するので、ラムダ関数を明示的に記述する必要はないことに注意してください)。

1) HTTP API リクエストを介して行われるコンポーネント / e2e テストを実装する方法は?

2) アプリの一部のみを読み込んでテストする統合および単体テストを実装する方法は?

3) いずれかのテストが失敗した場合にデプロイを拒否する新しい CI フローと両方を統合する方法は?

質問 1) はほとんど解決されたと思います。AWS Lambda を外部からテストする方法はたくさんあります。lambda-to-test を test-lambda から直接呼び出して lambda-to-lambda テストを実行するか、ここで説明されているように test-lambda から HTTP を使用して AWS API Gateway 経由で lambda-to-test を呼び出すことができます。ローカル ラムダ テストにserverless-mocha-pluginを使用することもできます ( serverlessを使用している場合)。

興味深いのは 2) です。ラムダが展開されると、それはブラック ボックスになります。明示的にラムダ インターフェイスとして宣言されていないものは実行できません。既存の mocha ユニットと統合テストを保存または再実装するにはどうすればよいですか?

3) も同様: CI が展開時にすべてのテストを実行し、失敗した場合は展開を拒否するにはどうすればよいですか?

ここで私自身のアプローチ：テスト環境の場合にのみ、ノードアプリをサーバーレスにします。環境に応じてすべてのサーバーレス変更を条件付きにすることで、単純に従来のノード HTTP サービスとして機能させます。必要な変更はほとんどないため、これは可能で保守可能です。これで、grunt と mocha を使用して、ローカルおよび展開時に通常どおりテストを実行できます。その後、サーバーレス バージョンも同様に機能することを確認したい場合は、ラムダからラムダへの最終的なテストを行うことができます。

4

1 に答える 1

1

あなたのアプローチは良さそうですね。そして3に関しては、CIにローカルテストを実行させ、「dev」または「test」環境にデプロイしてlambdaTestsを実行するだけです

grunt # run grunt commands including local mocha tests
serverless deploy --stage test # deploy to test environment (serverless#1.0 syntax)
grunt lambdaTest

lambdaTestラムダ リクエストが失敗した場合や予期しない値が返された場合に、コマンドが失敗を処理してエラーをスローすることを確認する必要があります。

于 2016-10-10T18:20:24.037 に答える