Skip to content

Latest commit

 

History

History
161 lines (97 loc) · 6.52 KB

debug-and-test.md

File metadata and controls

161 lines (97 loc) · 6.52 KB

Debuging and testing

Debuging

The easiest way to debug the whole set of microservices in VS Code is to use the Run and Debug tab in the side-menu to launch the apps. You can run each Microservice and API separately, or run them all together by choosing any of the configurations "Microservices", "APIs" or "All configurations". Alternatively, you can enable Debug: Auto Attach to smart or to manually attach debugger on running services, although this may not always work as expected and you may need to restart your terminal or VS Code instance for it to work properly.

Launch configurations

Important: For this to work you need to have nodemon and ts-node packages installed globally. Each API and Microservice has its own corresponding launch.json file which contains the debug launch configuration for that program. After launching it through the Run and Debug menu, a debugger gets auto attached and you can add breakpoints anywhere the code should pause during the execution.

Alternative: Set up debugger auto attach

Press F1 and find in menu Debugger: toggle auto attach and set it to smart. You may need to restart integrated terminal for changes to take effect.

Run services with debugger

In root folder of the project, type

npm run dev

or for a more minimal subset of the services use which only includes the dev console API use

npm run dev-min

This will run NPM dev script in all workspaces.

If you run this command in integrated terminal of VS Code and you have Debugger auto attach enabled, breakpoints in editor should be bind to the processes and you can debug all services at the same time.

If auto attach does not work or it's not enabled, you can attach debugger with command F1 -> Debug: Attach to node process. Search for the process PID through a terminal command (OS-specific) and then paste that PID in the search bar after clicking "Attach to node process". You can facilitate the search of the PID by making use of the --inspect-brk flag for each program. For example, the Access microservice contains the following flag: --inspect-brk=60001, therefore in the terminal you can look for processes that contain that flag at the end, or you can look for the process that contains that flag in the lookup menu in VS Code after opening the "Attach to node process" menu.

Writing automated tests

For current needs we will limit our automated tests to end-to-end tests. Default testing framework for this project is Jest. Test are written in tests directory of each module. (e.g. ./src/modules/user/tests). File name should end with .e2e.test.ts (e.g. user.e2e.test.ts).

In module test all possible flows of the module functionality should be tested against all types of users/permissions.

Running automated tests locally

For running tests, check if all environment variables with suffix _TEST are correctly set. If running locally, variables should be set in your .env file in root folder.

# TEST config

ACCESS_FUNCTION_NAME_TEST: apillon-access-service-test
MONITORING_FUNCTION_NAME_TEST: apillon-monitoring-service-test

MONITORING_MONGO_SRV_TEST:

ACCESS_MYSQL_HOST_TEST:
ACCESS_MYSQL_PORT_TEST: 3306
ACCESS_MYSQL_DATABASE_TEST:
ACCESS_MYSQL_USER_TEST:
ACCESS_MYSQL_PASSWORD_TEST:

DEV_CONSOLE_API_MYSQL_HOST_TEST:
DEV_CONSOLE_API_MYSQL_PORT_TEST: 3306
DEV_CONSOLE_API_MYSQL_DATABASE_TEST:
DEV_CONSOLE_API_MYSQL_USER_TEST:
DEV_CONSOLE_API_MYSQL_PASSWORD_TEST:

Running test servers

For testing APIs, all the microservices should run their test socket servers (or test lambdas on cloud). To start test servers locally, first run

npm run test-server

You can (auto) attach debugger to services to debug the code.

Running API tests in console

Make sure, that microservices test servers are running.

Run in root or API folder.

npm run test

To run single test, go to API folder and run

npm run test -- <search pattern>

note the blank space after --

Search pattern is used to find file with test. You may use filename or part of filename, for example user.e2e

You can (auto) attach debugger to running test to debug the API.

Running tests inside VS Code

Make sure, that microservices test servers are running.

Go to debugger tab and find appropriate options from the configuration dropdown menu. Currently available:

  • Jest Test API - run all e2e tests
  • Jest Test Current File - will run test only for currently open test file.

Debugger will be automatically attached.

Running automatic tests on AWS cloud

Running in pipeline (recommended)

On AWS CodePipeline there is apillon-services-run-test pipeline that includes three stages:

  1. Source: Downloads source from git (test branch).
  2. Build: Runs Codebuild project for each microservice(lambda) on test environment - Deploys test lambdas
  3. RunTests: Runs codebuild project apillon-run-tests - runs predefined command (most of the time to run all tests)

To run tests on AWS use Release change in the pipeline.

Later it could be set, that test runs automatically on push to test branch.

Running in codebuild (faster in some cases)

You can also run test by only running the apillon-run-test codebuild project. In that case, you should make sure that test lambdas are deployed with correct code. If not sure, you should run test in pipeline, or you can run CodeBuild project for specific test lambda. Benefits of running tests in codebuild is that you don't have to wait for lambda deployment and you can easily override build parameters, for exmaple RUN_COMMAND or source branch.

Setup codebuild projects

For every microservice used in tests, there should be build project with test env variables. Any new build projects should be added to pipeline.

apillon-run-tests project can be modified with ENV variable RUN_COMMAND. (see source @ /bin/deploy/test-aws.sh)

Default command should be

npm run test

but can be changed to run specific tests or scripts, for example

npx turbo run test:logging --filter=@apillon/dev-console-api

Note that when running tests on multiple workspaces with turborepo CLI, you must ensure that tests do not run parallel!

To run tests one by one use --concurrency=1.

To continue on failed test use --continue.

Example:

npx turbo run test:logging --concurrency=1 --continue

Test databases

Ensure that test databases are empty before running tests, otherwise tests could fail. Only empty tables for migrations and seeds can be present.