これらの統合ポイントはすべて、異なるテスト層を必要とします。 単体テストでは、すべての依存関係をモックし、関数の期待値を設定し、目的の変換が得られるまで反復できるため、コードの記述速度が向上します。 しかし、もっと必要です。 Redis、MongoDB、またはマイクロサービスとの統合が、モックが記述どおりに機能するだけでなく、期待どおりに機能することを確認する必要があります。 どちらも重要ですが、その違いは非常に大きいです。
この記事では、testcontainer を使用して、非常に低いオーバーヘッドで Go で統合テストを記述する方法を紹介します。 ですから、明確にするために、単体テストの作成をやめるように言っているのではありません。
当時、Java開発者になることに興味があったとき、人気のあるオープンソーストレーサーであるZipkinとInfluxDBの統合を書こうとしました。 私はJava開発者ではないため、最終的には失敗しましたが、彼らが統合テストをどのように書いたかを理解し、魅了されました。
はじめに:テストコンテナ-java
Zipkinは、トレースを保存および操作するためのUIとAPIを提供し、Cassandra、インメモリ、ElasticSearch、MySQL、その他多くのプラットフォームをストレージとしてサポートします。 すべてのストレージシステムが機能することを検証するために、「テストフレンドリー」に設計されたdocker-apiのラッパーである testcontainers-java というライブラリを使用します。ここは は クイックスタート の例です。public class RedisBackedCacheIntTestStep0 {
private RedisBackedCache underTest;
@Before
public void setUp() {
// Assume that we have Redis running locally?
underTest = new RedisBackedCache("localhost", 6379);
}
@Test
public void testSimplePutAndGet() {
underTest.put("test", "example");
String retrieved = underTest.get("test");
assertEquals("example", retrieved);
}
}
setUpで、コンテナー (この場合は redis) を作成し、ポートを公開できます。ここから、ライブ Redis インスタンスを操作できます。 新しいコンテナを起動するたびに、 ryuk と呼ばれる「サイドカー」があり、一定時間後にコンテナ、ボリューム、ネットワークを削除することで、Docker環境をクリーンに保ちます。 また、テスト内から削除することもできます。以下の例は Zipkinからのものです。 彼らはElasticSearch統合をテストしており、例が示すように、テストケース内からプログラムで依存関係を設定できます。
public class ElasticsearchStorageRule extends ExternalResource {
static final Logger LOGGER = LoggerFactory.getLogger(ElasticsearchStorageRule.class);
static final int ELASTICSEARCH_PORT = 9200; final String image; final String index;
GenericContainer container;
Closer closer = Closer.create();
public ElasticsearchStorageRule(String image, String index) {
this.image = image;
this.index = index;
}
@Override
protected void before() {
try {
LOGGER.info("Starting docker image " + image);
container =
new GenericContainer(image)
.withExposedPorts(ELASTICSEARCH_PORT)
.waitingFor(new HttpWaitStrategy().forPath("/"));
container.start();
if (Boolean.valueOf(System.getenv("ES_DEBUG"))) {
container.followOutput(new Slf4jLogConsumer(LoggerFactory.getLogger(image)));
}
System.out.println("Starting docker image " + image);
} catch (RuntimeException e) {
LOGGER.warn("Couldn't start docker image " + image + ": " + e.getMessage(), e);
}
docker-compose 、外部のものに依存する必要がないため、重要です。 テスト自体の内部からスピンアップすることで、オーケストレーションとプロビジョニングをより詳細に制御でき、テストの安定性が向上します。 テストを開始する前に、コンテナーの準備が整ったことを確認することもできます。 私はJava開発者ではないので、ライブラリをGolangに移植し(まだすべての機能に取り組んでいます)、現在は メインのtestcontainers/testcontainers-go 組織にあります。
func TestNginxLatestReturn(t *testing.T) {
ctx := context.Background()
req := testcontainers.ContainerRequest{
Image: "nginx",
ExposedPorts: []string{"80/tcp"},
}
nginxC, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
ContainerRequest: req,
Started: true,
})
if err != nil {
t.Error(err)
}
defer nginxC.Terminate(ctx)
ip, err := nginxC.Host(ctx)
if err != nil {
t.Error(err)
}
port, err := nginxC.MappedPort(ctx, "80")
if err != nil {
t.Error(err)
}
resp, err := http.Get(fmt.Sprintf("http://%s:%s", ip, port.Port()))
if resp.StatusCode != http.StatusOK {
t.Errorf("Expected status code %d. Got %d.", http.StatusOK, resp.StatusCode)
}
}
テストの作成
これはそれがどのように見えるかです:ctx := context.Background()
req := testcontainers.ContainerRequest{
Image: "nginx",
ExposedPorts: []string{"80/tcp"},
}
nginxC, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
ContainerRequest: req,
Started: true,
})
if err != nil {
t.Error(err)
}
defer nginxC.Terminate(ctx)defer nginxC.Terminate(ctx) をクリーンアップします。 リュークを覚えていますか?これは必須のコマンドではありませんが、testcontainers-goはこれを使用して、ある時点でコンテナを削除します。 モジュール
Javaライブラリには モジュール と呼ばれる機能があり、データベース(mysql、postgress、cassandraなど)やnginxなどのアプリケーションなどのあらかじめ用意されたコンテナを入手できます。goバージョンも同様の作業を行っていますが、まだ オープンなPRです。アプリケーションが依存するマイクロサービスをアップストリーム ビデオから構築する場合、これは優れた機能です。 または、アプリケーションがコンテナ内からどのように動作するかをテストしたい場合(おそらく、本番環境で実行される場所とより似ています)。 これは Javaでどのように機能するか です:
@Rule
public GenericContainer dslContainer = new GenericContainer(
new ImageFromDockerfile()
.withFileFromString("folder/someFile.txt", "hello")
.withFileFromClasspath("test.txt", "mappable-resource/test-resource.txt")
.withFileFromClasspath("Dockerfile", "mappable-dockerfile/Dockerfile"))私が今取り組んでいること
私が現在取り組んでいるのは、 種類 を使用してコンテナ内のKubernetesクラスタをスピンアップする新しい canned コンテナです。アプリケーションでKubernetes APIを使用している場合は、統合でテストできます。 ctx := context.Background()
k := &KubeKindContainer{}
err := k.Start(ctx)
if err != nil {
t.Fatal(err.Error())
}
defer k.Terminate(ctx)
clientset, err := k.GetClientset()
if err != nil {
t.Fatal(err.Error())
}
ns, err := clientset.CoreV1().Namespaces().Get("default", metav1.GetOptions{})
if err != nil {
t.Fatal(err.Error())
}
if ns.GetName() != "default" {
t.Fatalf("Expected default namespace got %s", ns.GetName())すべてのコーダーを呼び出す
テストコンテナ用のJavaバージョンは最初に開発されたものであり、GoバージョンやJavaScript、Rust、.Netなどの他のライブラリに移植されていない多くの機能を備えています。 私の提案は、あなたの言語で書かれたものを試して、それに貢献することです。
Goでは、プログラムでイメージをビルドする方法はありません。 Dockerに依存しないデーモンレスビルダーを取得するために、埋め込み
buildkit または img することを考えています。 Goバージョンで作業することの大きな部分は、すべてのコンテナ関連ライブラリがすでにGoにあるため、それらとの統合の非常に優れた作業を行うことです。 これはこのコミュニティの一員になる絶好のチャンスです! フレームワークのテストに情熱を注いでいる場合は、私たちに参加してプルリクエストを送信するか、 Slackにたむろしてください。
フィードバック
「Dockerを使用した保守可能な統合テストの作成」に関する0の考え