-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transition audio test to mocha testing framework #2264
base: main
Are you sure you want to change the base?
Conversation
8eb9faf
to
7847b51
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice detailed doc about mocha tests! I added comments mostly about syntaxes and layout.
67c2df8
to
cfe6aca
Compare
cfe6aca
to
87caf78
Compare
@@ -0,0 +1,111 @@ | |||
# Mocha Tests | |||
|
|||
The Amazon Chime SDK team is transitioning integration tests from KITE to Mocha. Starting with audio tests, we will transition all the integration tests. The `integration/mocha-tests` directory contains the mocha version of integration tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like internal stuff. Not sure if we need to put it here.
The Amazon Chime SDK team is transitioning integration tests from KITE to Mocha. Starting with audio tests, we will transition all the integration tests. The `integration/mocha-tests` directory contains the mocha version of integration tests. | ||
|
||
## Test Types | ||
There are two types of Mocha tests: integration and browser compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not correct. browser compatibility is integration tests.
The Amazon Chime SDK team is transitioning integration tests from KITE to Mocha. Starting with audio tests, we will transition all the integration tests. The `integration/mocha-tests` directory contains the mocha version of integration tests. | ||
|
||
## Test Types | ||
There are two types of Mocha tests: integration and browser compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not correct. browser compatibility is integration tests.
@@ -0,0 +1,22 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we reuse the same ts config from the main library https://github.com/aws/amazon-chime-sdk-js/tree/main/config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually there is no ts file then why do we need it ?
"lint": "eslint --config eslintrc.json ./ --ext .ts,.tsx,.js --fix" | ||
}, | ||
"author": "", | ||
"license": "ISC", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably want to be Apache.
"lint": "eslint --config eslintrc.json ./ --ext .ts,.tsx,.js --fix" | ||
}, | ||
"author": "", | ||
"license": "ISC", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably want to be Apache.
"version": "1.0.0", | ||
"description": "", | ||
"scripts": { | ||
"clean": "rm -rf temp && rm -rf ../kite-allure-reports && rm -rf logs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we have kite-allure-reports here?
"version": "1.0.0", | ||
"description": "", | ||
"scripts": { | ||
"clean": "rm -rf temp && rm -rf ../kite-allure-reports && rm -rf logs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we have kite-allure-reports here?
- `logger.log` outputs messages to the console in different colors based on the log level. | ||
|
||
Integration tests use `mocha` as their test framework. Mocha prints the test results and some limited logs to the console automatically. Any console logs inside `it` will print before the mocha logs. | ||
This makes debugging hard as the logs seem out of sync and random. To get around this issue, buffered logging was added. Inside of `it` blocks, `logger.pushLogs` can be used to add logs to the buffer and a call to `logger.printLogs` inside of the `afterEach` hook will print the logs in the desired order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then should this be the default then? Why do we want dev to make decision if one is clearly better to avoid issue?
- `logger.log` outputs messages to the console in different colors based on the log level. | ||
|
||
Integration tests use `mocha` as their test framework. Mocha prints the test results and some limited logs to the console automatically. Any console logs inside `it` will print before the mocha logs. | ||
This makes debugging hard as the logs seem out of sync and random. To get around this issue, buffered logging was added. Inside of `it` blocks, `logger.pushLogs` can be used to add logs to the buffer and a call to `logger.printLogs` inside of the `afterEach` hook will print the logs in the desired order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then should this be the default then? Why do we want dev to make decision if one is clearly better to avoid issue?
const { spawnSync, spawn } = require('child_process'); | ||
|
||
// Run the command asynchronously without blocking the Node.js event loop. | ||
function runAsync(command, args, options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel like this should not be in this test framework as it is just a script helper.
* 6. Same attendee mutes the audio | ||
* 7. Checks if the other participant is not able to hear the audio | ||
* */ | ||
describe('AudioTest', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean we run all tests here single vs multiple sessions every time?
* 6. Same attendee mutes the audio | ||
* 7. Checks if the other participant is not able to hear the audio | ||
* */ | ||
describe('AudioTest', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean we run all tests here single vs multiple sessions every time?
}); | ||
|
||
describe('setup', async function () { | ||
it('should open the meeting demo in two tabs', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not have to do this and just have one single code flow for single vs multiple sessions. Maybe we can create a helper fucntion to map the window and page etc.
}); | ||
|
||
describe('setup', async function () { | ||
it('should open the meeting demo in two tabs', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not have to do this and just have one single code flow for single vs multiple sessions. Maybe we can create a helper fucntion to map the window and page etc.
There are two types of Mocha tests: integration and browser compatibility. | ||
|
||
### Integration Tests | ||
Integration tests are minimal tests that run on the latest Chrome on macOS. These tests are used to test the basic functionality across the more popular browsers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need more details on the test infra and how to write a test.
There are two types of Mocha tests: integration and browser compatibility. | ||
|
||
### Integration Tests | ||
Integration tests are minimal tests that run on the latest Chrome on macOS. These tests are used to test the basic functionality across the more popular browsers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need more details on the test infra and how to write a test.
Issue #:
Description of changes:
JS SDK currently uses KITE as its test engine for integration / end to end tests. KITE includes a lot of overhead to tests and a lot of KITE features are not currently used. Unit tests use mocha as their testing framework and it is much easier to use.
JS SDK uses a very old version of KITE and finding documentation on KITE issues has been a pain. This PR will start the transition of integration tests from KITE to mocha. A new folder named
mochaTests
will house these tests. This PR willTesting:
Can these tested using a demo application? Please provide reproducible step-by-step instructions.
No, these are integration test changes
Checklist:
Have you successfully run
npm run build:release
locally?Yes
Do you add, modify, or delete public API definitions? If yes, has that been reviewed and approved?
NA
Do you change the wire protocol, e.g. the request method? If yes, has that been reviewed and approved?
NA
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.