Adapter Test Files

These are the test files used for adapter testing.

test/unit/adapterTestUnit.js:
Contains the adapter unit tests. Unit tests are for the foundational components of the adapter – existing code and configurations contained within the adapter’s files. The unit tests also include testing for most error conditions (e.g., required fields) within the adapter.js.

test/integration/adapterTestIntegration.js:
Contains the adapter integration tests. Integration tests are for testing integration with the other system. These tests can be run in standalone ”stub” mode or be integrated with the other system. The only error conditions tested in the integration tests are no mock data or errors returned from the other system and how they are handled.

utils/testRunner.js:
This is a utility that can be used for easier testing. It allows you to provide credentials for integration testing without saving them in the test scripts. Of note, this test file is flawed and not as good for debugging issues.

package.json:
Contains several testing scripts: test:unit, test:integration, test:cover, and test. You can change the log level on the test:unit and test:integration scripts in the package.json to get better logs from the adapter during testing.

Adapter Linting

• Where is the linting script?
  • The package.json contains the linting scripts. You can lint the adapter by simply running npm run lint in the adapter directory.
  • Linting can show a large number of warnings in the code. You can also run lint to just see the errors by running npm run lint:errors
• What is the purpose of linting?
  • Linting provides the ability to find and fix potential runtime errors. It also improves code quality.
• What linting tool is used?
  • ESLint
• What are the linting rules?
  • The adapters are linted using AirBnB standards with some slight modifications:
  • Change the max length to a warning.
  • Remove the comma-dangle so that JSON is formatted as JSON.

Basic Linting Rules

1. Indentation should be 2 spaces.
2. No double quotes. Use single quotes instead. Ex: ‘I am a string’
3. When using variables in a string use slant quotes.
   Ex: this adds a ${variable} into a string
4. Do not use quotes around keys in objects.
   Ex: { key: ‘value’ }
5. Use dot notation for object references unless there is a – in the key.
   Ex: object.key
6. If there is a – in the key, use [] to reference it.
   Ex: object[my-key]
7. Never use ++ or – use var += or – = instead.
   Ex: x+= 1
8. Space after commas.
9. Space before curly braces on functions and objects.
10. Else should be on the same line as the end of if.
11. Catch should be on the same line as the end of try.
12. No spaces at the end of code lines.