temp-context
temp-context
is a Zoroaster test context to initialise a temporary directory for each test, and remove it at the end. It also contains methods to read, write, clone, assert existence and remove files inside and outside of the temp dir.
yarn add -E temp-context
Table Of Contents
API
The package is available by importing its default function:
TempContext
class Instances of this test context class will create a temp
directory in the test
folder on initialisation, and remove it at the end of each test. To change the location of the test directory, extend the class.
The test context is used with the Zoroaster testing framework, which will initialise and destroy it for every test. Check the example section to see how tests are implemented.
TempContext
: A test context that creates and destroys a temp directory. By default, the temp directory will be test/temp
relative to the current working directory, but it can be changed by extending the class and setting its TEMP
property in the constructor.
Name | Type & Description |
---|---|
constructor | new () => TempContext |
The constructor method will be called by a context-testing framework automatically. | |
TEMP | string |
The path to the temp directory. | |
_useOSTemp | (name: string) => void |
This method should be called in the constructor by classes that extend the TempContext to use the temp directory of the os system.name* string : The name of the directory inside of the temp dir.
|
|
readGlobal | (path: string) => !Promise<string> |
Read a file from the filesystem. path* string : Path of the file to read.
|
|
existsGlobal | (path: string) => !Promise<boolean> |
Check if the path exists on the filesystem. path* string : The path to check.
|
|
exists | (path: string) => !Promise<boolean> |
Check if the path exists in the temp directory. path* string : The relative path inside of the temp dir to check.
|
|
read | (path: string) => !Promise<string> |
Read a file inside of the temp directory. path* string : The path to the file in the temp directory.
|
|
write | (path: string, data: (string | !Buffer)) => !Promise<string> |
Write a file in the temp directory. path* string : The path to the file within the temp directory.data* (string \| !Buffer) : The data to write.
|
|
resolve | (path: string) => string |
Get a path to a file inside of the temp directory. path* string : The relative path to the file inside of the temp dir.
|
|
rm | (path: string) => !Promise<void> |
Remove a file or folder inside of the temp directory. path* string : The path of the file or folder to remove.
|
|
clone | (path: string, to: string) => !Promise<void> |
Clone a file or directory. This works like cloneGlobal , such that the path won't be resolved automatically.path* string : The path to the file or directory to clone.to* string : The path to the directory to contain the file or directory being cloned (not the path to the cloned entity).
|
|
add | (target: string) => !Promise<string> |
Adds a file or directory to the temp directory and returns its new path. target* string : The path to the file or directory to add to the temp directory.
|
|
snapshot | (options?: (string | !SnapshotOptions)) => !Promise<string> |
Capture the contents of the temp directory as a string (or partial contents if the inner path is given). options (string \| !SnapshotOptions) (optional): When a string is passed, indicates the inner path (left for compatibility with previous API). Otherwise, these are additional options for the snapshot, where inner path can also be specified.
|
|
_destroy | () => !Promise<void> |
Called automatically by a context-testing framework to remove the temp path. | |
_init | () => !Promise<void> |
Called automatically by a context-testing framework to create an empty temp dir. |
For snapshots, the following options can be specified:
Name | Type & Description | Default |
---|---|---|
posix | boolean | false |
Standardise the path into POSIX (dir/file.txt ) — this is useful when tests are run on Windows too.
|
||
innerPath | string | . |
The path inside of the temp dir to snapshot. |
Example
Zoroaster tests can be written either as masks, or more traditionally as specs. For example, a program might want to write given data to a file in a specified directory, as so:
/** * Writes given data to a hidden file. * @param * @param */const program = async { const j = const rs = await { rs rs }}
When writing tests with Zoroaster, the project directory will have the src
and test
directories:
example├── src│ └── index.js└── test ├── context │ ├── index.js │ └── temp.js ├── mask │ └── default.js ├── result │ └── default.md └── spec ├── default.js └── extended.js
Masks
To implement tests with masks, a mask implementation should be set up in the mask
directory:
/** * This test suite will clone an input and take a snapshot of the temp directory. */'example/test/result' /** * @param */ async { await const s = await return s } context: TempContext
The results file which contains data about how input should be mapped to the output is saved in the results
directory:
## creates a file in the temp directoryinput data /* expected */# .test hello world: input data/**/
Now when run, zoroaster
will use the mask test suite (generated with the makeTestSuite
function) to check that inputs match expected outputs.
Specs
Occasionally, there are times when masks are not flexible enough to run tests. Specs are individual test cases, and can access test contexts assigned to the context
property of a test suite.
/** @type {Object.<string, (c:Context, tc: TempContext)>} */const T = context: Context TempContext async 'writes data to a file' DATA TEMP resolve exists read await const j = console const e = await const res = await
Output
The outcome of all the above tests can be achieved with zoroaster -a example/test/spec example/test/mask
command, where -a
is used to require alamode
-- a fast RegExp-based transpiler of import
and export
statements.
example/test/spec/default.jsTemp file location: test/temp/.test ✓ writes data to a file example/test/mask ✓ creates a file in the temp directory 🦅 Executed 2 tests.
Autocompletion
One of the advantages of using test context is that they are well documented and it's possible to get auto-completes for available methods when using destructuring on the context argument to a test case, both in masks as well as in specs.
Extending
Extending the TempContext
allows to set the specific temp directory location, and/or add additional methods without having to have 2 contexts for testing.
{ super this } { return 'test-data' }
/** @type {Object.<string, (tc: MyTempContext)>} */const T = context: MyTempContext async 'writes data to a file' TEMP resolve exists read DATA await const j = console const e = await const res = await
example/test/spec/extended.jsTemp file location: /private/var/folders/wj/mc61bmvn3k5_n7q4pfh8rx3w0000gp/T/package-test/.test ✓ writes data to a file 🦅 Executed 1 test.
Copyright
© Art Deco™ for Wrote 2020 |
---|