harmonyc 0.20.0 → 0.22.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/AGENTS.md +105 -0
  2. package/README.md +142 -0
  3. package/package.json +33 -5
package/AGENTS.md ADDED
@@ -0,0 +1,105 @@
1
+ # Writing unit tests in .harmony files
2
+
3
+ When writing unit tests, write them in `.harmony` files using a special structured format. This specification will be compiled to JS on-the-fly and imports the corresponding `.phrases.ts` files for step implementations.
4
+
5
+ ## File Structure
6
+
7
+ For tests belonging to a feature, you need:
8
+
9
+ - `example.harmony` - Test specifications (this file)
10
+ - `example.phrases.ts` - Step implementations (you create this)
11
+
12
+ ## .harmony File Format
13
+
14
+ ### Syntax Rules
15
+
16
+ #### Line start
17
+
18
+ 1. **Lines starting with `+ `** on the same level become forks, each creating a separate test case.
19
+ 2. **Lines starting with `- `** become consecutive test steps in the same test case
20
+ 3. Every other line is ignored
21
+
22
+ #### Line content
23
+
24
+ 1. **Sections** are any line ending in `:`. It is ignored but is used for naming test cases and groups.
25
+ 2. **Steps** consist of an _action_ and an _expected outcome_ separated by `=>`.
26
+ 3. **Error steps** consist of an _action_ followed by `=> !!` and an _expected error message_ in double quotes.
27
+
28
+ #### Action and Expected Outcome syntax
29
+
30
+ Use human-readable phrases for both actions and expected outcomes.
31
+ Both actions and expected outcomes can contain:
32
+
33
+ - **words**
34
+ - **punctuation** is ignored
35
+ - **string arguments** enclosed in double quotes`"like this"`
36
+ - **code arguments** enclosed in backticks `` `like this` ``
37
+
38
+ Use string arguments for string parameters and code arguments for numbers, booleans, objects, arrays etc.
39
+
40
+ If there is one obvious default action in the test case with one parameter, use an action that contains just that parameter.
41
+ If there is one obvious default expected outcome with one parameter, use an expected outcome that contains just that parameter.
42
+
43
+ ### Example
44
+
45
+ ```harmony
46
+ # Calculator Functions
47
+
48
+ This library provides basic calculator functions.
49
+
50
+ + multiply():
51
+ - multiply `2` and `3` => `6`
52
+ - multiply `-2` and `3` => `-6`
53
+
54
+ + divide():
55
+ - divide `6` by `2` => `3`
56
+
57
+ Division by zero is an error.
58
+
59
+ + by zero:
60
+ We need to test both non-zero and zero dividends.
61
+ + divide `5` by `0` => !! "Division by zero"
62
+ + divide `0` by `0` => !! "Division by zero"
63
+ ```
64
+
65
+ ## .phrases.ts File Implementation
66
+
67
+ Create a class that implements step methods corresponding to your test specifications. Use imports as needed, e.g. import the functions you are testing.
68
+
69
+ `When_*` methods implement actions, and `Then_*` methods implement expected outcomes. `Then_*` methods receive
70
+ an extra parameter, the return value of the preceding `When_*` method. Add the words and parameters from the action / expected outcome, separated by underscores, with parameters denoted by `X`,`Y`,`Z`,`A`,`B`,...
71
+
72
+ Use vitest.expect in assertions.
73
+
74
+ Error responses need no implementation.
75
+
76
+ ```typescript
77
+ import { expect } from 'vitest'
78
+ import { multiply, divide } from './calculator'
79
+
80
+ export default class CalculatorPhrases {
81
+ result: number | undefined
82
+
83
+ async When_multiply_X_and_Y(a: number, b: number) {
84
+ return multiply(a, b)
85
+ }
86
+
87
+ async When_divide_X_by_Y(a: number, b: number) {
88
+ return divide(a, b)
89
+ }
90
+
91
+ async Then_X(expected: number, actual: number) {
92
+ expect(actual).toBe(expected)
93
+ }
94
+ }
95
+ ```
96
+
97
+ ## Best Practices
98
+
99
+ 1. **Keep test descriptions clear and concise**
100
+ 2. **Group related tests using sections**
101
+ 3. **Use meaningful parameter names in method signatures, and add TypeScript types**
102
+ 4. **Store state in class properties for complex scenarios**
103
+ 5. **Handle edge cases explicitly (errors, null values, etc.)**
104
+ 6. **Use descriptive comments in-line to explain test groups**
105
+ 7. **Test both happy path and error conditions**
package/README.md ADDED
@@ -0,0 +1,142 @@
1
+ # Harmony Code
2
+
3
+ A test design & BDD tool that helps you separate _what_ you test and _how_ you automate it. You write test cases in a simple easy-to-read format, and then automate them with Vitest.
4
+
5
+ ## Setup
6
+
7
+ You need to have Node.js installed. Then you can install Harmony Code in your project folder by:
8
+
9
+ ```bash
10
+ npm install harmonyc
11
+ ```
12
+
13
+ Then add it as a plugin to your `vitest.config.js` or `vite.config.js` file, and make sure to include your `.harmony` files:
14
+
15
+ ```js
16
+ import harmony from 'harmonyc/vitest'
17
+
18
+ export default {
19
+ plugins: [harmony()],
20
+ include: ['src/**/*.harmony'],
21
+ }
22
+ ```
23
+
24
+ This will run .harmony files in vitest.
25
+
26
+ ## VSCode plugin
27
+
28
+ Harmony Code has a [VSCode plugin](https://marketplace.visualstudio.com/items?itemName=harmony-ac.harmony-code) that supports syntax highlighting.
29
+
30
+ Harmony Code is compatible with Vitest's VSCode plugin, so you can run and debug tests from the editor.
31
+
32
+ ## Syntax
33
+
34
+ A `.harmony` file is a text file with a syntax that looks like this:
35
+
36
+ ```
37
+ + Products API:
38
+ + Create:
39
+ + Anonymous:
40
+ - create product => !! "unauthorized"
41
+ + Admin:
42
+ - authenticate with "admin" => product count `0`
43
+ - create product
44
+ => product created
45
+ => product count `1`
46
+ - Delete:
47
+ - delete product => product deleted => product count `0`
48
+ ```
49
+
50
+ ### Indentation
51
+
52
+ The lines of a file are nodes of a tree. The tree is specified with the indentation of the lines, which is n times 2 spaces and a `+` or `-` with one more space. The `+` or `-` sign is considered to be part of the indentation.
53
+
54
+ ### Sequences and forks
55
+
56
+ `-` means a sequence: the node follows the previous sibling node and its descendants.
57
+
58
+ `+` means a fork: the node directly follows its parent node. All siblings with `+` are separate branches, they will generate separate scenarios.
59
+
60
+ ### Phrases (actions and responses)
61
+
62
+ After the mark, every node can contain an **action** and zero or more **responses**, together called **phrases**. The action is the text before the `=>`, and the responses are the text after the `=>`.
63
+
64
+ Both actions and responses get compiled to simple function calls - in JavaScript, awaited function calls. Actions will become `When_*` functions, and responses will become `Then_*` functions. The return value of the action is passed to the responses of the same step as the last argument.
65
+
66
+ ### Arguments
67
+
68
+ Phrases (actions and responses) can have arguments which are passed to the implementation function. There are two types of arguments: strings and code fragments:
69
+
70
+ ```harmony
71
+ + strings:
72
+ + hello "John"
73
+ + code fragment:
74
+ + greet `3` times
75
+ ```
76
+
77
+ becomes
78
+
79
+ ```javascript
80
+ test('T1 - strings', async () => {
81
+ const P = new Phrases()
82
+ await P.When_hello_('John')
83
+ })
84
+ test('T2 - code fragment', async () => {
85
+ const P = new Phrases()
86
+ await P.When_greet__times(3)
87
+ })
88
+ ```
89
+
90
+ ### Labels
91
+
92
+ Labels are lines that start with `-` or `+` and end with `:`. You can use them to structure your test design.
93
+ They are not included in the test case, but the test case name is generated from the labels.
94
+
95
+ ### Comments
96
+
97
+ Lines starting with `#` or `//` are comments and are ignored.
98
+
99
+ ### Switches
100
+
101
+ You can generate multiple test cases by adding a `{ A / B / C }` syntax into action(s) and possibly response(s).
102
+
103
+ ```harmony
104
+ + password is { "A" / "asdf" / "password123" } => !! "password is too weak"
105
+ ```
106
+
107
+ ### Error matching
108
+
109
+ You can use `!!` to denote an error response. This will verify that the action throws an error. You can specify the error message after the `!!`.
110
+
111
+ ### Variables
112
+
113
+ You can set variables in the tests and use them in strings and code fragments:
114
+
115
+ ```
116
+ + set variable:
117
+ + ${name} "John"
118
+ + greet "${name}" => "hello John"
119
+ + store result into variable:
120
+ + run process => ${result}
121
+ + "${result}" is "success"
122
+ ```
123
+
124
+ becomes
125
+
126
+ ```javascript
127
+ test('T1 - set variable', (context) => {
128
+ const P = new Phrases();
129
+ (context.task.meta.variables ??= {})['name'] = "John";
130
+ await P.When_greet_(context.task.meta.variables?.['name']);
131
+ })
132
+ test('T2 - store result in variable', (context) => {
133
+ const P = new Phrases();
134
+ const r = await P.When_run_process();
135
+ (context.task.meta.variables ??= {})['result'] = r;
136
+ await P.Then__is_(`${context.task.meta.variables?.['result']});
137
+ })
138
+ ```
139
+
140
+ ## License
141
+
142
+ MIT
package/package.json CHANGED
@@ -1,6 +1,16 @@
1
1
  {
2
2
  "name": "harmonyc",
3
- "version": "0.20.0",
3
+ "description": "Harmony Code - model-driven BDD for Vitest",
4
+ "version": "0.22.0",
5
+ "author": "Bernát Kalló",
6
+ "homepage": "https://github.com/harmony-ac/code#readme",
7
+ "repository": {
8
+ "type": "git",
9
+ "url": "git+https://github.com/harmony-ac/code.git"
10
+ },
11
+ "bugs": {
12
+ "url": "https://github.com/harmony-ac/code/issues"
13
+ },
4
14
  "type": "module",
5
15
  "scripts": {
6
16
  "build": "tsc",
@@ -9,11 +19,12 @@
9
19
  "test": "vitest --run",
10
20
  "test:compile": "tsx ./src/cli/cli 'src/**/*.harmony'",
11
21
  "dev": "vitest --watch",
12
- "publish": "npm publish",
13
- "release": "npm run build && release publish"
22
+ "release": "npm run test && npm run build && cp ../../README.md . && release publish"
14
23
  },
15
24
  "files": [
16
- "dist"
25
+ "dist",
26
+ "AGENTS.md",
27
+ "README.md"
17
28
  ],
18
29
  "exports": {
19
30
  "./vitest": {
@@ -42,5 +53,22 @@
42
53
  "typescript": "^5.3.3",
43
54
  "vite": "^7.1.10",
44
55
  "vitest": "^3.2.4"
45
- }
56
+ },
57
+ "license": "MIT",
58
+ "keywords": [
59
+ "unit test",
60
+ "unit testing",
61
+ "bdd",
62
+ "behavior-driven",
63
+ "test design",
64
+ "test design automation",
65
+ "harmony.ac",
66
+ "test framework",
67
+ "model-based test",
68
+ "model-based testing",
69
+ "test model",
70
+ "test modeling",
71
+ "test modelling",
72
+ "vitest"
73
+ ]
46
74
  }