使用Docker进行端到端API测试

最新推荐文章于 2022-10-07 21:33:25 发布

dfsgwe1231

最新推荐文章于 2022-10-07 21:33:25 发布

阅读量365

点赞数

文章标签：运维数据库网络

通常，测试是一种痛苦。有些人看不到重点。有些人看到了它，但认为这是使他们减速的额外步骤。有时会有测试，但运行时间很长或不稳定。在本文中，您将看到如何使用Docker自己进行测试。

我们希望以最小的努力编写和维护快速，有意义且可靠的测试。这意味着对于您作为开发人员而言日常有用的测试。他们应该提高您的生产率并提高软件质量。进行测试（因为每个人都说“您应该进行测试”）会使您的速度减慢，这是不好的。

让我们看看如何不费吹灰之力实现这一目标。

我们要测试的示例

在本文中，我们将测试使用Node / express构建的API，并使用chai / mocha进行测试。我选择了一个JS'y堆栈，因为该代码非常短且易于阅读。所应用的原理对任何技术堆栈均有效。即使Javascript让您感到不适，也要继续阅读。

该示例将为用户介绍一组简单的CRUD端点。掌握概念并将其应用于API的更复杂的业务逻辑已绰绰有余。

我们将为API使用标准的环境：

-Postgres数据库

-Redis集群

-我们的API将使用其他外部API来完成其工作

您的API可能需要不同的环境。本文中应用的原理将保持不变。您将使用不同的Docker基本映像来运行您可能需要的任何组件。

为什么选择Docker？实际上，Docker Compose

本节有很多赞成或使用Docker进行测试的论点。如果您想立即进入技术部分，可以跳过它。

痛苦的选择

要在接近生产环境的环境中测试API，您有两种选择。您可以在代码级别上模拟环境，或者在安装了数据库等的真实服务器上运行测试。

在代码级别模拟一切都会使我们的API的代码和配置混乱。它通常也不十分代表API在生产中的行为。在真实的服务器上运行事物非常耗费基础架构。它涉及很多设置和维护，并且无法扩展。具有共享数据库，您一次只能运行1个测试，以确保测试运行不会相互干扰。

Docker Compose使我们能够充分利用两者。它为我们使用的所有外部零件创建“容器化”版本。它是在嘲笑，但在我们代码的外部。我们的API认为它是在真实的物理环境中。 Docker compose还将针对给定的测试运行为所有容器创建一个隔离的网络。这使您可以在本地计算机或CI主机上并行运行其中的几个。

过度杀伤力？

您可能想知道，使用Docker compose进行端到端测试是否不是过分杀伤力。只运行单元测试呢？

在过去的10年中，大型的整体应用程序被划分为较小的服务（趋向热闹的“微服务”）。给定的API组件依赖于更多的外部部件（基础结构或其他API）。随着服务规模的缩小，与基础架构的集成成为工作的重中之重。您应该在生产和开发环境之间保持很小的差距。否则，在进行生产部署时会出现问题。根据定义，这些问题出现在最坏的时刻。它们会导致紧急修复，质量下降和团队沮丧。没有人想要。

您可能想知道，使用Docker compose进行的端到端测试是否比传统的单元测试运行更长的时间。并不是的。您将在下面的示例中看到，我们可以轻松地将测试保持在1分钟以内。好处是：测试反映了现实世界中的应用程序行为。这比知道您的班级是否在应用程序中正常工作更有价值。另外，如果您现在没有任何测试，那么从头到尾的尝试将为您带来巨大的收益。您将了解应用程序的所有堆栈在最常见的情况下都可以协同工作。那已经是东西了！从那里，您始终可以完善策略以对应用程序的关键部分进行单元测试。

我们的第一个测试

让我们从最简单的部分开始。我们的API和Postgres数据库。让我们运行一个简单的CRUD测试。一旦有了该框架，就可以向我们的组件和测试添加更多功能。

这是我们使用GET / POST来创建和列出用户的最小API：

const express = require ( 'express' );
const bodyParser = require ( 'body-parser' );
const cors = require ( 'cors' );

const config = require ( './config' );

const db = require ( 'knex' )({
  client : 'pg' ,
  connection : {
    host : config.db.host,
    user : config.db.user,
    password : config.db.password,
  },
});

const app = express();

app.use(bodyParser.urlencoded({ extended : false }));
app.use(bodyParser.json());
app.use(cors());

app.route( '/api/users' ).post( async (req, res, next) => {
  try {
    const { email, firstname } = req.body;
    // ... validate inputs here ...
    const userData = { email, firstname };

    const result = await db( 'users' ).returning( 'id' ).insert(userData);
    const id = result[ 0 ];
    res.status( 201 ).send({ id, ...userData });
  } catch (err) {
    console .log( `Error: Unable to create user: ${err.message} . ${err.stack} ` );
    return next(err);
  }
});

app.route( '/api/users' ).get( ( req, res, next ) => {
  db( 'users' )
  .select( 'id' , 'email' , 'firstname' )
  .then( users => res.status( 200 ).send(users))
  .catch( err => {
      console .log( `Unable to fetch users: ${err.message} . ${err.stack} ` );
      return next(err);
  });
});

try {
  console .log( "Starting web server..." );

  const port = process.env.PORT || 8000 ;
  app.listen(port, () => console .log( `Server started on: ${port} ` ));
} catch (error) {
  console .error(error.stack);
}
`` `

Here are our tests written with chai. The tests create a new user and fetch it back.
You can see that the tests are not coupled in any way with the code of our API.
The ` SERVER_URL ` variable specifies the endpoint to test. It can be a local or a remote environment.

` `` javascript
const chai = require ( "chai" );
const chaiHttp = require ( "chai-http" );
const should = chai.should();

const SERVER_URL = process.env.APP_URL || "http://localhost:8000" ;

chai.use(chaiHttp);

const TEST_USER = {
  email : "john@doe.com" ,
  firstname : "John"
};

let createdUserId;

describe( "Users" , () => {
  it( "should create a new user" , done => {
    chai
      .request(SERVER_URL)
      .post( "/api/users" )
      .send(TEST_USER)
      .end( ( err, res ) => {
        if (err) done(err)
        res.should.have.status( 201 );
        res.should.be.json;
        res.body.should.be.a( "object" );
        res.body.should.have.property( "id" );
        done();
      });
  });

  it( "should get the created user" , done => {
    chai
      .request(SERVER_URL)
      .get( "/api/users" )
      .end( ( err, res ) => {
        if (err) done(err)
        res.should.have.status( 200 );
        res.body.should.be.a( "array" );

        const user = res.body.pop();
        user.id.should.equal(createdUserId);
        user.email.should.equal(TEST_USER.email);
        user.firstname.should.equal(TEST_USER.firstname);
        done();
      });
  });
});

好。现在要测试我们的API，让我们定义一个Docker compose环境。名为docker-compose.yml文件将描述Docker需要运行的容器。

version: '3.1'

services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: john
      POSTGRES_PASSWORD: mysecretpassword
    expose:
      - 5432

  myapp:
    build: .
    image: myapp
    command: yarn start
    environment:
      APP_DB_HOST: db
      APP_DB_USER: john
      APP_DB_PASSWORD: mysecretpassword
    expose:
      - 8000
    depends_on:
      - db

  myapp-tests:
    image: myapp
    command: dockerize
        - wait tcp://db:5432 -wait tcp://myapp:8000 -timeout 10 s
        bash -c "node db/init.js && yarn test"
    environment:
      APP_URL: http://myapp:8000
      APP_DB_HOST: db
      APP_DB_USER: john
      APP_DB_PASSWORD: mysecretpassword
    depends_on:
      - db
      - myapp

那我们这里有什么。有3个容器：

-db启动了PostgreSQL的新实例。我们使用来自Docker Hub的公共Postgres映像。我们设置数据库的用户名和密码。我们告诉Docker公开数据库将监听的端口5432，以便其他容器可以连接

-myapp是将运行我们的API的容器。 build命令告诉Docker从我们的源代码实际构建容器映像。其余的就像db容器：环境变量和端口

-myapp-tests是将执行我们的测试的容器。它将使用与myapp相同的图像，因为代码已经存在，因此不需要再次构建它。在容器上运行的命令node db/init.js && yarn test将初始化数据库（创建表等）并运行测试。我们使用dockerize等待所有必需的服务器启动并运行。 depends_on选项将确保容器以特定顺序启动。它不能确保db容器内的数据库实际上已准备好接受连接。我们的API服务器也没有启动。

环境的定义就像20行非常容易理解的代码。唯一聪明的部分是环境定义。用户名，密码和URL必须一致，以便容器可以实际协同工作。

需要注意的一件事是，Docker compose会将其创建的容器的主机设置为容器的名称。因此该数据库在localhost:5432下将不可用，但在db:5432下将不可用。我们的API将以相同的方式在myapp:8000 。这里没有任何类型的本地主机。这意味着在定义环境时，您的API必须支持环境变量。没有硬编码的东西。但这与Docker或本文无关。可配置的应用程序是12要素应用程序清单中的第3点，因此您应该已经在这样做了。

我们需要告诉Docker的最后一件事是如何实际构建容器myapp 。我们使用如下所示的Dockerfile。内容特定于您的技术堆栈，但其想法是将您的API捆绑到可运行的服务器中。

下面针对我们的Node API的示例安装了Dockerize，安装了API依赖关系，并在容器内部复制了API代码（服务器使用原始JS编写，因此无需对其进行编译）。

FROM node AS base

# Dockerize is needed to sync containers startup
ENV DOCKERIZE_VERSION v0. 6.0
RUN  wget https://github.com/jwilder/dockerize/releases/download/ $DOCKERIZE_VERSION /dockerize-alpine-linux-amd64- $DOCKERIZE_VERSION .tar.gz \
    && tar -C /usr/ local /bin -xzvf dockerize-alpine-linux-amd64- $DOCKERIZE_VERSION .tar.gz \
    && rm dockerize-alpine-linux-amd64- $DOCKERIZE_VERSION .tar.gz

RUN  mkdir -p ~/app

WORKDIR  ~/app

COPY  package.json .
 COPY  yarn.lock .

FROM base AS dependencies

RUN  yarn

FROM dependencies AS runtime

COPY  . .

通常，在WORKDIR ~/app及以下行中，您将运行用于构建应用程序的命令。

这是我们用来运行测试的命令：

docker-compose up --build --abort-on-container-exit

该命令将告诉Docker compose提升在docker-compose.yml文件中定义的组件。 --build标志将通过执行上述Dockerfile的内容来触发myapp容器的构建。 --abort-on-container-exit将告诉Docker compose在一个容器退出后立即关闭环境。这很有效，因为要退出的唯一组件是执行测试后的测试容器myapp-tests 。樱桃蛋糕上的docker-compose命令将以与触发退出的容器相同的退出代码退出。这意味着我们可以从命令行检查测试是否成功。这对于CI环境中的自动构建非常有用。

这不是完美的测试设置吗？

完整的示例在GitHub上。

您可以克隆存储库并运行docker compose命令：

docker-compose up --build --abort-on-container-exit

当然，您需要安装Docker。 Docker有一种麻烦的趋势，迫使您仅注册一个帐户来下载东西。但是您实际上不必这样做。转到发行说明（适用于Windows的链接和适用于Mac的链接），而不是下载最新版本，而是下载之前的版本。这是直接下载链接。

测试的第一轮运行将比平时更长。这是因为Docker必须下载容器的基础映像并缓存一些内容。下次运行将更快。

运行日志将如下所示。您可以看到Docker非常酷，可以将所有组件的日志放在同一时间轴上。查找错误时，这非常方便。

Creating tuto-api-e2e-testing_db_1    ... done
Creating tuto-api-e2e-testing_redis_1 ... done
Creating tuto-api-e2e-testing_myapp_1 ... done
Creating tuto-api-e2e-testing_myapp-tests_1 ... done
Attaching to tuto-api-e2e-testing_redis_1, tuto-api-e2e-testing_db_1, tuto-api-e2e-testing_myapp_1, tuto-api-e2e-testing_myapp-tests_1
db_1           | The files belonging to this database system will be owned by user "postgres" .
redis_1        | 1 :M 09 Nov 2019 21 : 57 : 22.161 * Running mode=standalone, port= 6379.
myapp_1        | yarn run v1 .19 .0
redis_1        | 1 :M 09 Nov 2019 21 : 57 : 22.162 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_1        | 1 :M 09 Nov 2019 21 : 57 : 22.162 # Server initialized
db_1           | This user must also own the server process.
db_1           | 
db_1           | The database cluster will be initialized with locale "en_US.utf8" .
db_1           | The default database encoding has accordingly been set to "UTF8" .
db_1           | The default text search configuration will be set to "english" .
db_1           | 
db_1           | Data page checksums are disabled.
db_1           | 
db_1           | fixing permissions on existing directory / var /lib/postgresql/data ... ok
db_1           | creating subdirectories ... ok
db_1           | selecting dynamic shared memory implementation ... posix
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Waiting for : tcp: //db:5432
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Waiting for : tcp: //redis:6379
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Waiting for : tcp: //myapp:8000
myapp_1        | $ node server.js
redis_1        | 1 :M 09 Nov 2019 21 : 57 : 22.163 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
db_1           | selecting default max_connections ... 100
myapp_1        | Starting web server...
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Connected to tcp: //myapp:8000
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Connected to tcp: //db:5432
redis_1        | 1 :M 09 Nov 2019 21 : 57 : 22.164 * Ready to accept connections
myapp-tests_1  | 2019 / 11 / 09 21 : 57 : 25 Connected to tcp: //redis:6379
myapp_1        | Server started on: 8000
db_1           | selecting default shared_buffers ... 128 MB
db_1           | selecting default time zone ... Etc/UTC
db_1           | creating configuration files ... ok
db_1           | running bootstrap script ... ok
db_1           | performing post-bootstrap initialization ... ok
db_1           | syncing data to disk ... ok
db_1           | 
db_1           | 
db_1           | Success. You can now start the database server using:
db_1           | 
db_1           |     pg_ctl -D / var /lib/postgresql/data -l logfile start
db_1           | 
db_1           | initdb: warning: enabling "trust" authentication for local connections
db_1           | You can change this by editing pg_hba.conf or using the option -A, or
db_1           | --auth-local and --auth-host, the next time you run initdb.
db_1           | waiting for server to start... .2019 -11 -09 21 : 57 : 24.328 UTC [ 41 ] LOG:  starting PostgreSQL 12.0 (Debian 12.0 -2. pgdg100+ 1 ) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3 .0 -6 ) 8.3 .0 , 64 -bit
db_1           | 2019 -11 -09 21 : 57 : 24.346 UTC [ 41 ] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1           | 2019 -11 -09 21 : 57 : 24.373 UTC [ 42 ] LOG:  database system was shut down at 2019 -11 -09 21 : 57 : 23 UTC
db_1           | 2019 -11 -09 21 : 57 : 24.383 UTC [ 41 ] LOG:  database system is ready to accept connections
db_1           |  done
db_1           | server started
db_1           | CREATE DATABASE
db_1           | 
db_1           | 
db_1           | /usr/ local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d /*
db_1           | 
db_1           | waiting for server to shut down....2019-11-09 21:57:24.907 UTC [41] LOG:  received fast shutdown request
db_1           | 2019-11-09 21:57:24.909 UTC [41] LOG:  aborting any active transactions
db_1           | 2019-11-09 21:57:24.914 UTC [41] LOG:  background worker "logical replication launcher" (PID 48) exited with exit code 1
db_1           | 2019-11-09 21:57:24.914 UTC [43] LOG:  shutting down
db_1           | 2019-11-09 21:57:24.930 UTC [41] LOG:  database system is shut down
db_1           |  done
db_1           | server stopped
db_1           | 
db_1           | PostgreSQL init process complete; ready for start up.
db_1           | 
db_1           | 2019-11-09 21:57:25.038 UTC [1] LOG:  starting PostgreSQL 12.0 (Debian 12.0-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
db_1           | 2019-11-09 21:57:25.039 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
db_1           | 2019-11-09 21:57:25.039 UTC [1] LOG:  listening on IPv6 address "::", port 5432
db_1           | 2019-11-09 21:57:25.052 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1           | 2019-11-09 21:57:25.071 UTC [59] LOG:  database system was shut down at 2019-11-09 21:57:24 UTC
db_1           | 2019-11-09 21:57:25.077 UTC [1] LOG:  database system is ready to accept connections
myapp-tests_1  | Creating tables ...
myapp-tests_1  | Creating table 'users'
myapp-tests_1  | Tables created succesfully
myapp-tests_1  | yarn run v1.19.0
myapp-tests_1  | $ mocha --timeout 10000 --bail
myapp-tests_1  | 
myapp-tests_1  | 
myapp-tests_1  |   Users
myapp-tests_1  | Mock server started on port: 8002
myapp-tests_1  |     ✓ should create a new user (151ms)
myapp-tests_1  |     ✓ should get the created user
myapp-tests_1  |     ✓ should not create user if mail is spammy
myapp-tests_1  |     ✓ should not create user if spammy mail API is down
myapp-tests_1  | 
myapp-tests_1  | 
myapp-tests_1  |   4 passing (234ms)
myapp-tests_1  | 
myapp-tests_1  | Done in 0.88s.
myapp-tests_1  | 2019/11/09 21:57:26 Command finished successfully.
tuto-api-e2e-testing_myapp-tests_1 exited with code 0

我们可以看到db是初始化最长的容器。说得通。一旦完成，测试就开始了。

我的笔记本电脑上的总运行时间为16秒。与实际执行测试的880ms相比，它要多得多。在实践中，运行时间不到1分钟的测试是黄金，因为它几乎是即时反馈。 15秒钟的时间开销是购买时间，随着您添加更多测试，时间将保持不变。您可以添加数百个测试，并且仍将执行时间保持在1分钟以内。

瞧！我们已经建立并运行了测试框架。在现实世界的项目中，下一步将是通过更多测试来增强API的功能覆盖范围。让我们考虑一下涵盖的CRUD操作。现在是时候在我们的测试环境中添加更多内容了。

添加Redis集群

让我们向我们的API环境中添加另一个元素，以了解它需要什么。剧透警告：数量不多。

让我们想象一下，我们的API将用户会话保留在Redis集群中。如果您想知道为什么要这样做，请想象一下您的API在生产中有100个实例。用户根据循环负载平衡命中一台或另一台服务器。每个请求都需要认证。它需要用户配置文件数据来检查特权和其他特定于应用程序的业务逻辑。一种方法是往返于数据库以在每次需要时获取数据，但这并不是很有效。使用内存数据库集群可以使数据在所有服务器上都可用，但需要读取局部变量。

这是通过附加服务增强Docker撰写测试环境的方式。

让我们从官方Docker镜像添加Redis集群（我只保留了文件的新部分）：

services:
  db:
    ...

  redis:
    image: "redis:alpine"
    expose:
      - 6379

  myapp:
    environment:
      APP_REDIS_HOST: redis
      APP_REDIS_PORT: 6379
    ...
  myapp-tests:
    command: dockerize ... -wait tcp://redis:6379 ...
    environment:
      APP_REDIS_HOST: redis
      APP_REDIS_PORT: 6379
      ...
    ...

您可以看到数量不多。我们添加了一个名为redis的新容器。它使用称为redis:alpine的官方最小redis映像。我们将Redis主机和端口配置添加到我们的API容器中。并且我们已经使测试以及其他容器在执行测试之前等待它。

让我们修改应用程序以实际使用Redis集群：

const redis = require ( 'redis' ).createClient({
  host : config.redis.host,
  port : config.redis.port,
})

...

app.route( '/api/users' ).post( async (req, res, next) => {
  try {
    const { email, firstname } = req.body;
    // ... validate inputs here ...
    const userData = { email, firstname };
    const result = await db( 'users' ).returning( 'id' ).insert(userData);
    const id = result[ 0 ];
    
    // Once the user is created store the data in the Redis cluster
    await redis.set(id, JSON .stringify(userData));
    
    res.status( 201 ).send({ id, ...userData });
  } catch (err) {
    console .log( `Error: Unable to create user: ${err.message} . ${err.stack} ` );
    return next(err);
  }
});

现在让我们更改测试，以检查Redis集群是否填充了正确的数据。这就是为什么myapp-tests容器还会在docker-compose.yml获得Redis主机和端口配置docker-compose.yml 。

it( "should create a new user" , done => {
  chai
    .request(SERVER_URL)
    .post( "/api/users" )
    .send(TEST_USER)
    .end( ( err, res ) => {
      if (err) throw err;
      res.should.have.status( 201 );
      res.should.be.json;
      res.body.should.be.a( "object" );
      res.body.should.have.property( "id" );
      res.body.should.have.property( "email" );
      res.body.should.have.property( "firstname" );
      res.body.id.should.not.be.null;
      res.body.email.should.equal(TEST_USER.email);
      res.body.firstname.should.equal(TEST_USER.firstname);
      createdUserId = res.body.id;

      redis.get(createdUserId, (err, cacheData) => {
        if (err) throw err;
        cacheData = JSON .parse(cacheData);
        cacheData.should.have.property( "email" );
        cacheData.should.have.property( "firstname" );
        cacheData.email.should.equal(TEST_USER.email);
        cacheData.firstname.should.equal(TEST_USER.firstname);
        done();
      });
    });
});

看看这有多容易。您可以像组装乐高积木一样为测试构建复杂的环境。

我们可以看到这种容器化的完整环境测试的另一个好处。这些测试实际上可以调查环境组件。我们的测试不仅可以检查我们的API是否返回正确的响应代码和数据。我们可以检查Redis集群中的数据是否具有正确的值。我们还可以检查数据库内容。

添加API模拟

API组件的常见元素是调用其他API组件。

假设我们的API在创建用户时需要检查垃圾邮件。使用第三方服务进行检查：

const validateUserEmail = async (email) => {
  const res = await fetch( ` ${config.app.externalUrl} /validate?email= ${email} ` );
  if (res.status !== 200 ) return false ;
  const json = await res.json();
  return json.result === 'valid' ;
}

app.route( '/api/users' ).post( async (req, res, next) => {
  try {
    const { email, firstname } = req.body;
    // ... validate inputs here ...
    const userData = { email, firstname };

    // We don't just create any user. Spammy emails should be rejected
    const isValidUser = await validateUserEmail(email);
    if (!isValidUser) {
      return res.sendStatus( 403 );
    }

    const result = await db( 'users' ).returning( 'id' ).insert(userData);
    const id = result[ 0 ];
    await redis.set(id, JSON .stringify(userData));
    res.status( 201 ).send({ id, ...userData });
  } catch (err) {
    console .log( `Error: Unable to create user: ${err.message} . ${err.stack} ` );
    return next(err);
  }
});

现在，我们在测试任何东西时都遇到了问题。如果无法使用检测垃圾邮件的API，我们将无法创建任何用户。修改我们的API以在测试模式下绕过此步骤是危险的代码混乱。

即使我们可以使用真正的第三方服务，我们也不想这样做。通常，我们的测试不应依赖于外部基础架构。首先，因为您可能会在CI流程中大量运行测试。为此目的而使用另一个生产API并不是很酷。第二，API可能暂时关闭，由于错误的原因导致测试失败。

正确的解决方案是在我们的测试中模拟外部API。

不需要任何花哨的框架。我们将在约20行代码中在Vanilla JS中构建一个通用模拟。这将使我们有机会控制API返回到组件的内容。它允许测试错误方案。

现在让我们增强测试。

const express = require ( "express" );

...

const MOCK_SERVER_PORT = process.env.MOCK_SERVER_PORT || 8002 ;

// Some object to encapsulate attributes of our mock server
// The mock stores all requests it receives in the `requests` property.
const mock = {
  app : express(),
  server : null ,
  requests : [],
  status : 404 ,
  responseBody : {}
};

// Define which response code and content the mock will be sending
const setupMock = ( status, body ) => {
  mock.status = status;
  mock.responseBody = body;
};

// Start the mock server
const initMock = async () => {
  mock.app.use(bodyParser.urlencoded({ extended : false }));
  mock.app.use(bodyParser.json());
  mock.app.use(cors());
  mock.app.get( "*" , (req, res) => {
    mock.requests.push(req);
    res.status(mock.status).send(mock.responseBody);
  });

  mock.server = await mock.app.listen(MOCK_SERVER_PORT);
  console .log( `Mock server started on port: ${MOCK_SERVER_PORT} ` );
};

// Destroy the mock server
const teardownMock = () => {
  if (mock.server) {
    mock.server.close();
    delete mock.server;
  }
};

describe( "Users" , () => {
  // Our mock is started before any test starts ...
  before( async () => await initMock());

  // ... killed after all the tests are executed ...
  after( () => {
    redis.quit();
    teardownMock();
  });

  // ... and we reset the recorded requests between each test
  beforeEach( () => (mock.requests = []));

  it( "should create a new user" , done => {
    // The mock will tell us the email is valid in this test
    setupMock( 200 , { result : "valid" });

    chai
      .request(SERVER_URL)
      .post( "/api/users" )
      .send(TEST_USER)
      .end( ( err, res ) => {
        // ... check response and redis as before
        createdUserId = res.body.id;

        // Verify that the API called the mocked service with the right parameters
        mock.requests.length.should.equal( 1 );
        mock.requests[ 0 ].path.should.equal( "/api/validate" );
        mock.requests[ 0 ].query.should.have.property( "email" );
        mock.requests[ 0 ].query.email.should.equal(TEST_USER.email);
        done();
      });
  });
});

现在，测试会在调用我们的API时检查外部API是否已被正确的数据击中。

我们还可以添加其他测试，以根据外部API响应代码检查API的行为：

describe( "Users" , () => {
  it( "should not create user if mail is spammy" , done => {
    // The mock will tell us the email is NOT valid in this test ...
    setupMock( 200 , { result : "invalid" });

    chai
      .request(SERVER_URL)
      .post( "/api/users" )
      .send(TEST_USER)
      .end( ( err, res ) => {
        // ... so the API should fail to create the user
        // We could test that the DB and Redis are empty here
        res.should.have.status( 403 );
        done();
      });
  });

  it( "should not create user if spammy mail API is down" , done => {
    // The mock will tell us the email checking service
    //  is down for this test ...
    setupMock( 500 , {});

    chai
      .request(SERVER_URL)
      .post( "/api/users" )
      .send(TEST_USER)
      .end( ( err, res ) => {
        // ... in that case also a user should not be created
        res.should.have.status( 403 );
        done();
      });
  });
});

当然，您如何处理应用程序中第三方API的错误。但是你明白了。

要运行这些测试，我们需要告诉容器myapp第三方服务的基本URL是什么：

  myapp:
    environment:
      APP_EXTERNAL_URL: http: //myapp-tests:8002/api
    ...

  myapp-tests:
    environment:
      MOCK_SERVER_PORT: 8002
    ...

结论和其他一些想法

希望本文能带您了解Docker compose在进行API测试时可以为您做些什么。完整的示例在GitHub上。

使用Docker compose可使测试在接近生产环境中快速运行。它不需要修改您的组件代码。唯一的要求是支持环境变量驱动的配置。

此示例中的组件逻辑非常简单，但是原理适用于任何API。您的测试将更长或更复杂。它们还适用于可以放在容器内的所有技术堆栈（仅此而已）。到那里后，如果需要的话，离将容器部署到生产阶段仅一步之遥。

如果您现在没有测试，这就是我建议您开始的方式。使用Docker compose进行端到端测试。如此简单，您可以在几个小时内进行首次测试。如果您有任何疑问或需要建议，请随时与我联系。我很乐意提供帮助。

我希望您喜欢这篇文章，并会开始使用Docker Compose测试您的API。一旦准备好测试，就可以在我们的持续集成平台Fire CI上开箱即用地运行它们。

自动测试成功的最后一个想法。

在维护大型测试套件时，最重要的功能是易于阅读和理解。这是激励您的团队保持测试最新状态的关键。从长远来看，复杂的测试框架不太可能正确使用。无论您的API使用哪种堆栈，您都可能要考虑使用chai / mocha为其编写测试。在运行时代码和测试代码中使用不同的堆栈似乎很不寻常，但是如果它能完成工作的话……从本文的示例中可以看出，使用chai / mocha测试REST API就像获得它一样简单。学习曲线接近于零。因此，如果您根本没有测试，并且有REST API可以用Java，Python，RoR，.NET或任何其他堆栈编写测试，则可以考虑尝试chai / mocha。

如果您根本不知道如何开始进行持续集成，那么我已经写了一个更广泛的指南。 它是： 如何开始进行持续集成

最初发布在 Fire CI博客上 。

From: https://hackernoon.com/api-end-to-end-testing-with-docker-f6t3691

dfsgwe1231

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
使用Docker进行端到端API测试

通常，测试是一种痛苦。有些人看不到重点。有些人看到了它，但认为这是使他们减速的额外步骤。有时会有测试，但运行时间很长或不稳定。在本文中，您将看到如何使用Docker自己进行测试。我们希望以最小的努力编写和维护快速，有意义且可靠的测试。这意味着对于您作为开发人员而言日常有用的测试。他们应该提高您的生产率并提高软件质量。进行测试（因为每个人都说“您应该进行测试”）会使您的速度减慢，...
复制链接

扫一扫