統合テストを爆速に！ローカル環境で動くAWSエミュレーター「Fakecloud」

「Fakecloud」は、統合テストのために開発されたローカル環境用AWSエミュレーターです。外部サービスへの依存を排除し、手元のマシンで高速かつ安定したテスト環境を構築したいエンジニアにとって、非常に強力なツールとなります。

でも、LocalStackが残したものを引き継いだflociと比べてどうなの？

どれも良いものだけど、大規模なシステムだと準備作業（スキャフォールディング）が結構大変なんだよね。例えばインフラのTerraformを渡せば、こういうツール側で勝手に構築してくれる機能があれば便利そう。まだ見たことがない機能だし、追加されたら面白そう。

こういうエミュレータは結構好きなんだけど、なんでGCPやAzureをターゲットにしたものがないんだろ。

LocalStackが開発者のワークフローを壊し始めた後にフォークしたMiniStackもあるよ：https://ministack.org/ (https://ministack.org/)

それにfakecloudとそのサイトは作りが適当そうだし、「著者」も匿名。信頼を得るには時間がかかるだろうね。疑ってかかったほうがいいと思う。（インストールにcurlパイプって、うわぁ……）

こういうツールは山ほどあるけど、驚きの請求額までシミュレートしてくれるものはないね。

localemuもあるよ。これもLocalStackのフォークだったはず：https://localemu.cloud/ (https://localemu.cloud/)

「完全な100%適合で46個」とか言ってるけど、事実と違うよ。DynamoDBのサービスを調べてみたけど、フルAPIを実装しているなんて到底言えないレベル。

面白いね。Smithyで生成したPythonのAWS SDKで試すのが楽しみ：https://github.com/kap-sh/capo (https://github.com/kap-sh/capo)

いっそのことAWS互換のクラウドサービスとして提供すればいいのに……APIって著作権で守れるものなの？

別プロセスで動くシミュレータを使うより、テスト内にインラインでモックを作ることをおすすめするよ。そうすればテストが完全に「自己完結」するからね。

そうしないと、テストが暗黙のうちに「ユーザーAは常にオフライン」とか「バケットAは常に空」といった前提を持ってしまう。テストを読む人は、その前提がシミュレータのどこにハードコードされているのかを探しに行って、テスト本体とは別に確認しなきゃいけなくなる。

テストを読む人にとって、ユーザーAが常にオフラインとかバケットAが空なんて直感的に分からないよね。

インラインでモックすれば、ユーザーAやバケットAをモックして、どんな状態でもシミュレートできる。一つのテスト内で複数の状態を表現することだって可能だ。

バケットに最初はデータが入っていて、次のリクエストでは空になっている、みたいなシナリオも考えられるしね。

シミュレータを使うやり方だと、無限にシナリオの組み合わせを追加することになるし、それぞれのシナリオが特定のテストと密結合してしまう。なら、テストの中に直接書いちゃえばいいんじゃない？

インラインモックを使ったテストなら、わざわざ別のシミュレータの中に潜り込んで「ユーザーAに対してどんな特別な処理がハードコードされているのか」を確認しなくても、何のシナリオをテストしているのか一目瞭然だよ。「2回目のリクエストで空になる」とか「遅延してタイムアウトするけどリトライで成功するバケット」みたいな名前のついた何百、何千ものシミュレート用バケットを管理する必要もなくなるしね。