erezrokah / aws-testing-library Goto Github PK

View Code? Open in Web Editor NEW

126.0 6.0 11.0 4.45 MB

Chai (https://chaijs.com) and Jest (https://jestjs.io/) assertions for testing services built with aws

License: MIT License

JavaScript 0.45% TypeScript 99.50% Shell 0.05%

serverless assertions typescript equality javascript testing expectation e2e-tests e2e-testing aws

aws-testing-library's Introduction

AWS Testing Library

Note: If you're missing any capability please open an issue/feature request :)

Prerequisites

You should have your aws credentials under ~/.aws/credentials (if you have aws cli installed and configured).

Note: aws credentials are loaded automatically as described here

If you plan to use the deploy utility function please install and configure serverless.

node >= 16.10.0.

Installation

Install with npm

npm install aws-testing-library --save-dev

or yarn

yarn add aws-testing-library --dev

Usage

aws-testing-library's People

Contributors

Stargazers

Watchers

Forkers

rquast forrestbrazeal tbradyrobustwealth shubham-kaushal danemauland ankcorn calebwilson706 renanbym varqasim gerwant

aws-testing-library's Issues

Explicit LogGroupName in toHaveLog() function

Is your feature request related to a problem? Please describe.
It's not a problem but a feature request.

I'd like to test code that sends events to EventBus. I have a rule that logs all events sent to my Event Bus to Cloud Watch Logs. Since recent API Destinations announcement, not every event on the EventBus will trigger Lambda function. Therefore there no function to create logs in Cloud Watch.

Describe the solution you'd like
I want to provide CloudWatch Log Group name instead Lambda function name in the config object:

expect.assertions(1); // makes sure the assertion was called
await expect({
  region: 'us-east-1',
  logGroupName: 'logGroupName',
  startTime: 0 /* optional (millis since epoch in UTC, defaults to now-1 hour) */,
  timeout: 0 /* optional (defaults to 2500) */,
  pollEvery: 0 /* optional (defaults to 500) */,
}).toHaveLog(
  'some message written to log by the lambda' /* a pattern to match against log messages */,
);

the rest of behavior stays the same.

Additional context
This request i mo

Paging from CloudWatch Stymies Library

v4.0.6

I'm seeing paging results from the CloudWatch toHaveLog() matcher. Using default time of one hour. Here's an example of a cloudWatchLogs.filterLogEvents() return with a nextToken:

{
  events: [
    {
      logStreamName: '2023/10/31/[$LATEST]3998d19732dc45e4a031419cc461562d',
      timestamp: 1698716448251,
      message: '[this is not the message you are looking for]\n',
      ingestionTime: 1698716449742,
      eventId: '37882642676998482009100965194064775797471706186071408642'
    }
  ],
  searchedLogStreams: [
    
  ],
  nextToken: 'Bxkq6kVGFtq2y_MoigeqscPOdhXVbhiVtLoAmXb5jCrGNG3oJwptg8VF1zEUyfwpBFOEV9qaY_2ur816UYZk3Iv-_OKdTpV0sOjuuuo6lhHo6MAkaWO_XYl_s_a8JomVJlQ5mnH80rmZdtJHEP5zFJLyv-cyetGGKGsMHIpqCaNSJ94TSv_-4ALOA_AxbxH5uBu73PEjdGmaFPD6HKVXYA_u7kNYArLsZglRQIPdnBZD_4npKJ5sPWHQlKud3w4BDbTfNfLmTSOh_0apMGhYRA'
}

This happens on a log group with a 24-hour retention. I just need to run my test a couple of times to put a few logs in there and I can generate a nextToken almost at will.

FWIW, I can drop the version back to v1.1.6 and I get no error. Same log group. I have no idea what's changed, but will update here if I find anything suspicious.

-Seth

Documentation question: is expect.assertions call needed for Jest extension?

The README for the Jest extension includes this line for each example:

expect.assertions(1); // makes sure the assertion was called

Under what scenario would the assertion not be called (and thus result in an incorrectly passing test)? What is the risk of not including it in my test case?
If the async call to the AWS SDK fails, I imagine an exception is thrown which would be bubbled up and cause the test to fail anyway.

v1.1.0 release missing lib directory contents

Describe the bug
v1.1.0 release only contains the LICENSE, package.json, and README.md file.

To Reproduce
Steps to reproduce the behavior:

Run npm i aws-testing-library
Inspect node_modules directory for contents

Expected behavior
lib directory is present with build artifact from TypeScript build.

Screenshots

P.S.
Thank you for all of your hard work on this library. It is awesome! 🎉

Set aws keys explicitly

Dynamodb clearAllItems fails if table contains more than 25 items

Describe the bug
A clear and concise description of what the bug is.
If I try to clear a table with more than 25 items in it the test fails

To Reproduce
Steps to reproduce the behavior:

Create 26 items in a dynamodb table
run the clearAllItems util
See large error message

Expected behavior
A clear and concise description of what you expected to happen.
Remove all items from the dynamodb table
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Jest encountered an unexpected token after update

After updating from v 1.1.1 to most recent 2.1.4 I got this error:

Test suite failed to run

    Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.

    Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

    By default "node_modules" folder is ignored by transformers.

    Here's what you can do:
     • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
     • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
     • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
     • If you need a custom transformation specify a "transform" option in your config.
     • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

    You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
    For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

Details:

    /Users/pawel/moje/serverless-hexagonal-template/node_modules/filter-obj/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export default function filterObject(object, predicate) {
                                                                                      ^^^^^^

    SyntaxError: Unexpected token 'export'

      at Runtime.createScriptFromCode (../node_modules/jest-runtime/build/index.js:1796:14)
      at Object.<anonymous> (../node_modules/aws-testing-library/src/common/dynamoDb.ts:1:1)

I've tried many different solutions fount on the internet but nothing seems to work.

My jest version is 28.1.1 and node is 14.

Handling large amounts of CloudWatch Logs in toHaveLog()

Is your feature request related to a problem? Please describe.
We've been noticing our tests fail as the CloudWatch log streams grow and it is largely due to the AWS SDK returning multiple pages of CloudWatch Logs.

Describe the solution you'd like
At RobustWealth, we've added a wrapper around the SDK to page the logs along with giving a start and end date to retrieve a smaller subset of logs. Instead of rolling our own solution we would like to add this feature into this library and we'd be willing to contribute back our solution.

Describe alternatives you've considered
We've considered deleting our logs, this fixed our issues but then we lose the information we need to properly monitor our applications.

Expect lambda to return a response

Coming from jest-e2e-serverless and using the invoke function, I cannot find the equivalent, maybe you can just point out to me how to do? otherwise I think it would be useful to be able to assert the result response of a lambda.

Also the assertion shouldn't hardcode a JSON object, it would be more useful to be able to assert the response in a custom fashion. E.g. assert that status is 200 and it contains an array of 2...but I don't want to hard code the actual values since most often those values come from real data (e.g. contains hash, dates, increments...therefore you cannot assert a fix value)

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

chore(deps): update dependency @types/node to v18.19.31
chore(deps): update dependency typescript to v5.4.5
fix(deps): update dependency axios to v0.28.1
fix(deps): update dependency aws-sdk to v2.1610.0
chore(deps): update dependency @types/mockdate to v3
chore(deps): update googlecloudplatform/release-please-action action to v4
fix(deps): update dependency axios to v1
fix(deps): update dependency filter-obj to v6
🔐 Create all rate-limited PRs at once 🔐

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

chore(deps): update dependency chai to v4.4.1 (chai, @types/chai)

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions

.github/workflows/release-please.yml

GoogleCloudPlatform/release-please-action v3

actions/checkout v3

actions/setup-node v3

.github/workflows/test.yml

actions/checkout v3

actions/setup-node v3

npm

package.json

aws-sdk ^2.678.0

axios ^0.28.0

filter-obj ^3.0.0

jest-diff ^29.0.0

uuid ^9.0.0

@commitlint/cli ^17.0.0

@commitlint/config-conventional ^17.0.0

@tsconfig/node16 ^1.0.3

@types/chai ^4.2.12

@types/jest ^29.0.0

@types/mockdate ^2.0.0

@types/node ^18.0.0

@types/uuid ^9.0.0

@typescript-eslint/eslint-plugin ^5.0.0

@typescript-eslint/parser ^5.0.0

chai ^4.2.0

eslint ^8.0.0

eslint-config-prettier ^8.0.0

husky ^8.0.0

jest ^29.0.0

mockdate ^3.0.0

prettier ^3.0.0

ts-jest ^29.0.0

ts-node ^10.0.0

typescript ^5.0.0

node >=16.10.0

Check this box to trigger a request for Renovate to run again on this repository

A simple assertion works e.g. expect(true).to.Be(false) will pass

but using awsTesting type assertion never fails

import { invoke } from 'aws-testing-library/lib/utils/lambda'
 import awsTesting from 'aws-testing-library/lib/chai'
import chai = require('chai')
chai.use(awsTesting);

const { expect } = chai;


      const result = await invoke(
        region,
        'functionName',
        event,
      );

      await expect({
        region: region,
        function: 'functionName',
      }).to.have.log(
        'zzzzzzzzzzz'
      );