Testing

Execute unit test suites with the command npm run test

package.json:

"jest": {
"errorOnDeprecated": true,
"preset": "ts-jest",
"testEnvironment": "node",
"verbose": true
},
"scripts": {
// ...
"test": "jest",
// ...
}

Implementation

HaTs projects come pre-configured with a ts-jest integration as well as tsconfig-build.json settings that instruct the compiler to ignore test files when emitting your final JavaScript build.

Out of the box, HaTs supports two types of test suites for your project:

Isolated Tests

Isolated tests belong inside the "rootDir" of your module, e.g. src/**, directly next the source file you're testing.

System Tests

System tests belong inside the top-level ./tests directory at the root of your project. These tests for instance can help you model some process that invokes multiple parts of your codebase.

Example

The source code for the HaTs CLI itself contains several examples of writing test suites.

src/fs/reads.test.ts:

import getFileStr from './reads';
import { getCwd } from './path';
import { logger } from '../console/logger';
describe('reads', function () {
test('getFileStr', function () {
return (async function () {
const path = `${getCwd()}/tests/reads.test.txt`;
const read_test_file_str = `Hello world
`;
const str = await getFileStr({ path });
type T = typeof str;
expect<T>(str).toBe<T>(read_test_file_str);
})();
});
});

Pro Tip: Adding explicit type annotations to the expect statements as shown above combines safety checks from jest with safety checks from your linter.

Further Reading

Edit this page on GitHub

Happy TypeScript
©2022 👨🏾‍💻 Kamar Mack