TypeScript icon, indicating that this package has built-in type declarations

    0.5.6 • Public • Published

    AWS SDK v3 Client mock

    Easy and powerful mocking of AWS SDK v3 Clients.

    npm build coverage

    Library recommended by the AWS SDK for JavaScript team - see the introductory post on the AWS blog.


    • 🌊  fluent interface - declaring behavior is short and readable
    • 🔍  matching options - defining mock behavior by Command type and/or its input payload
    • 🕵️  spying - checking if Commands were actually send
    • 🖋️  fully typed - same type control for declaring mock's behavior as when writing regular code
    •   fully tested - reliable mocks help instead of impeding

    In action:


    Table of Contents

    About AWS SDK v3

    The AWS SDK for JavaScript version 3, is the new version of SDK to use in Node.js and browser. It comes with modular architecture and improved typing, thanks to being written in TypeScript.

    The recommended way of using it is to create a Client and use it to send Commands.

    For example, using SNS Client to publish a message to a topic looks like that:

    import {PublishCommand, SNSClient} from '@aws-sdk/client-sns';
    const sns = new SNSClient({});
    const result = await sns.send(new PublishCommand({
      TopicArn: 'arn:aws:sns:us-east-1:111111111111:MyTopic',
      Message: 'My message',
    console.log(`Message published, id: ${result.MessageId}`);

    This library provides an easy way to mock sending Commands and define returned results depending on the Command type and payload.



    npm install -D aws-sdk-client-mock


    yarn add -D aws-sdk-client-mock



    const {mockClient} = require('aws-sdk-client-mock');

    TypeScript / ES6:

    import {mockClient} from 'aws-sdk-client-mock';


    Create mock for all instances or for given instance of the AWS SDK Client:

    const snsMock = mockClient(SNSClient);
    const dynamoDB = new DynamoDBClient({});
    const dynamoDBMock = mockClient(dynamoDB);

    By default, mocked Client#send() method returns undefined.

    Using the obtained mock instance, you can specify the mock behavior on receiving various commands to send.

    Specify default mock behavior:

    // same as:

    Specify mock behavior on receiving given command only:

            MessageId: '12345678-1111-2222-3333-111122223333',

    Specify mock behavior on receiving given command with given payload only:

        .on(PublishCommand, {
            TopicArn: 'arn:aws:sns:us-east-1:111111111111:MyTopic',
            Message: 'My message',
            MessageId: '12345678-4444-5555-6666-111122223333',

    Not all payload parameters must be defined to match (you can force strict matching by passing third param strict: true):

        .on(PublishCommand, {
            Message: 'My message',
            MessageId: '12345678-4444-5555-6666-111122223333',

    Specify mock behavior on receiving given payload only:

            TopicArn: 'arn:aws:sns:us-east-1:111111111111:MyTopic',
            Message: 'My message',
            MessageId: '12345678-4444-5555-6666-111122223333',

    Multiple behaviors (for different commands and payloads) may be specified for a single mock:

        .resolves({ // default for any command
            MessageId: '12345678-1111-2222-3333-111122223333'
        .resolves({ // default for PublishCommand
            MessageId: '12345678-4444-5555-6666-111122223333'
        .on(PublishCommand, {
            TopicArn: 'arn:aws:sns:us-east-1:111111111111:MyTopic',
            Message: 'My message',
        .resolves({ // for PublishCommand with given input
            MessageId: '12345678-7777-8888-9999-111122223333',

    Specify mock throwing an error:

        .rejects('mocked rejection');

    Specify custom mock function:

        .callsFake(input => {
            if (input.Message === 'My message') {
                return {MessageId: '12345678-1111-2222-3333-111122223333'};
            } else {
                return {MessageId: '12345678-4444-5555-6666-111122223333'};

    DynamoDB DocumentClient

    You can mock the DynamoDBDocumentClient just like any other Client:

    import {DynamoDBDocumentClient, QueryCommand} from '@aws-sdk/lib-dynamodb';
    const ddbMock = mockClient(DynamoDBDocumentClient);
        Items: [{pk: 'a', sk: 'b'}],

    Lib Storage Upload

    To mock @aws-sdk/lib-storage Upload you need to call a helper function mockLibStorageUpload() that will configure required S3Client command mocks:

    import {mockLibStorageUpload} from 'aws-sdk-client-mock';
    import {Upload} from '@aws-sdk/lib-storage';
    import {S3Client} from '@aws-sdk/client-s3';
    const s3Mock = mockClient(S3Client);
    const s3Upload = new Upload({
        client: new S3Client({}),
        params: {
            Bucket: 'mock',
            Key: 'test',
            Body: 'x'.repeat(6 * 1024 * 1024), // 6 MB
    s3Upload.on('httpUploadProgress', (progress) => {
    await s3Upload.done();

    You can call mockLibStorageUpload() without providing an S3Client mock. In that case, the client mock will be created and returned from the function. However, you still need to have @aws-sdk/client-s3 installed as a dependency.

    Paginated operations

    To mock a paginated operation results, simply mock the corresponding Command:

    import {DynamoDBClient, paginateQuery, QueryCommand} from '@aws-sdk/client-dynamodb';
    import {marshall} from '@aws-sdk/util-dynamodb';
    const dynamodbMock = mockClient(DynamoDBClient);
        Items: [
            marshall({pk: 'a', sk: 'b'}),
            marshall({pk: 'c', sk: 'd'}),
    const dynamodb = new DynamoDBClient({});
    const paginator = paginateQuery({client: dynamodb}, {TableName: 'mock'});
    const items = [];
    for await (const page of paginator) {
        items.push( || []);


    Inspect received calls:

    snsMock.calls(); // all received calls; // first received call

    Get calls of a specified command:


    Get calls of a specified command with given payload (you can force strict matching by passing third param strict: true):

    snsMock.commandCalls(PublishCommand, {Message: 'My message'})

    Under the hood, the library uses Sinon.js stub. You can get the stub instance to configure and use it directly:

    const snsSendStub = snsMock.send;

    API Reference

    See the full API Reference.

    AWS Lambda example

    Example below uses Jest as a test framework, but mocks will work with any testing library.

    Let's take a simple Lambda function that takes a list of messages, sends them to SNS topic and returns message IDs:

    import {PublishCommand, SNSClient} from '@aws-sdk/client-sns';
    const snsTopicArn = process.env.SNS_TOPIC_ARN || '';
    const sns = new SNSClient({});
    export const handler = async (event: Event): Promise<string[]> => {
      const promises = (msg, idx) => {
        const publish = await sns.send(new PublishCommand({
          TopicArn: snsTopicArn,
          Message: msg,
        return publish.MessageId!;
      return await Promise.all(promises);
    interface Event {
      messages: string[];

    Then the tests could look like this:

    import {mockClient} from 'aws-sdk-client-mock';
    import {PublishCommand, SNSClient} from '@aws-sdk/client-sns';
    import {handler} from '../src';
    const snsMock = mockClient(SNSClient);
     * To be sure that unit tests are independent from each other,
     * reset mock behavior between the tests.
    beforeEach(() => {
    it('message IDs are returned', async () => {
        MessageId: '12345678-1111-2222-3333-111122223333',
      const result = await handler({
        messages: ['one', 'two', 'three']
    it('SNS Client is called', async () => {
        MessageId: '111-222-333',
      await handler({
        messages: ['qq', 'xx']

    For more examples, see the unit tests.


    Mixed @aws-sdk/types versions

    If you have multiple @aws-sdk packages in dependencies in different versions, or one of your dependencies depends on the @aws-sdk package(s) in a different version than the one you use, you may end up with different @aws-sdk/types dependency versions required.

    If the one installed on the top level in node_modules is in a different version than required by the Client you try to mock, the types will be incompatible. This is because the mocking library will use the @aws-sdk/types version from the top level of node_modules, while your Client may be using a different one.

    This often results in a long error stack trace looking similar to this:

    Argument of type 'typeof SomeCommand' is not assignable to parameter of type 'new (input: SomeCommandInput) => AwsCommand<SomeCommandInput, MetadataBearer, any, any>'
      Types of construct signatures are incompatible.
        Type 'new (input: SomeCommandInput) => SomeCommand' is not assignable to type 'new (input: SomeCommandInput) => AwsCommand<SomeCommandInput, MetadataBearer, any, any>'.
          Construct signature return types 'SomeCommand' and 'AwsCommand<SomeCommandInput, MetadataBearer, any, any>' are incompatible.
            The types of 'middlewareStack.concat' are incompatible between these types.
              Type '<InputType extends SomeCommandInput, OutputType extends SomeCommandOutput>(from: MiddlewareStack<InputType, OutputType>) => MiddlewareStack<...>' is not assignable to type '<InputType extends SomeCommandInput, OutputType extends MetadataBearer>(from: MiddlewareStack<InputType, OutputType>) => MiddlewareStack<...>'.
                Types of parameters 'from' and 'from' are incompatible.
                  Type 'MiddlewareStack<InputType, OutputType>' is not assignable to type 'MiddlewareStack<InputType, SomeCommandOutput>'.
                    Types of property 'addRelativeTo' are incompatible.
                      Type '(middleware: MiddlewareType<InputType, OutputType>, options: RelativeMiddlewareOptions) => void' is not assignable to type '(middleware: MiddlewareType<InputType, SomeCommandOutput>, options: RelativeMiddlewareOptions) => void'.
                        Types of parameters 'middleware' and 'middleware' are incompatible.
                          Type 'MiddlewareType<InputType, SomeCommandOutput>' is not assignable to type 'MiddlewareType<InputType, OutputType>'.
                            Type 'InitializeMiddleware<InputType, SomeCommandOutput>' is not assignable to type 'MiddlewareType<InputType, OutputType>'.
                              Type 'InitializeMiddleware<InputType, SomeCommandOutput>' is not assignable to type 'InitializeMiddleware<InputType, OutputType>'.
                                Call signature return types 'InitializeHandler<InputType, SomeCommandOutput>' and 'InitializeHandler<InputType, OutputType>' are incompatible.
                                  Type 'Promise<InitializeHandlerOutput<SomeCommandOutput>>' is not assignable to type 'Promise<InitializeHandlerOutput<OutputType>>'.
                                    Type 'InitializeHandlerOutput<SomeCommandOutput>' is not assignable to type 'InitializeHandlerOutput<OutputType>'.
                                      Types of property 'output' are incompatible.
                                        Type 'SomeCommandOutput' is not assignable to type 'OutputType'.
                                          'SomeCommandOutput' is assignable to the constraint of type 'OutputType', but 'OutputType' could be instantiated with a different subtype of constraint 'MetadataBearer'.

    This is a common problem when using the Amplify library.

    The solution for this is to force the version of the @aws-sdk/types matching your Clients to be installed on the top-level of node_modules.

    The easiest way to do this is to add the @aws-sdk/types in the selected version to package.json explicitly.

    However, depending on your project structure, you may need to force it differently. For example, when using yarn, you can add the @aws-sdk/types in selected version to the resolutions section in package.json.

    Order of mock behaviors

    Wider Command matchers must be declared first, otherwise, they will take precedence over previous ones.

    In this case, all PublishCommand sends will return message ID 222:

      .on(PublishCommand, myInput).resolves({MessageId: '111'})
      .on(PublishCommand).resolves({MessageId: '222'});

    If the order of the declarations is switched, sends with input matching myInput will return ID 111 and all others 222.

    It works similarly with onAnyCommand().

    Order of type and instance mocks

    When you create both a Client type mock and a specific Client instance mock(s), you need to declare type mock last. Otherwise, the other instances will not be mocked.

    Right now if you create a mock for the Client type, and then mock a specific instance of this Client, with the order of mocking as here:

    const sns1 = new SNSClient({}); // not mocked
    mockClient(SNSClient).resolves({MessageId: '123'});
    const sns2 = new SNSClient({}); // mocked
    mockClient(sns2).resolves({MessageId: '456'});
    const sns3 = new SNSClient({}); // not mocked

    Declaring mocks in this order will fix it:

    const sns1 = new SNSClient({}); // mocked - default
    const sns2 = new SNSClient({}); // mocked
    mockClient(sns2).resolves({MessageId: '456'});
    mockClient(SNSClient).resolves({MessageId: '123'});
    const sns3 = new SNSClient({}); // mocked - default

    PRs to fix this are welcome.


    npm i aws-sdk-client-mock

    DownloadsWeekly Downloads






    Unpacked Size

    72.2 kB

    Total Files


    Last publish


    • m-radzikowski