harmonyc 0.23.0 → 0.23.2

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.
package/AGENTS.md CHANGED
@@ -1,105 +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**
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**
@@ -22,7 +22,7 @@ export class VitestGenerator {
22
22
  this.extraArgs = [];
23
23
  }
24
24
  feature(feature) {
25
- const phrasesModule = './' + basename(this.sourceFileName.replace(/\.harmony$/, '.phrases'));
25
+ const phrasesModule = './' + basename(this.sourceFileName.replace(/\.harmony$/, '.phrases.ts'));
26
26
  const fn = (this.featureClassName =
27
27
  this.currentFeatureName =
28
28
  pascalCase(feature.name) + 'Phrases');
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "harmonyc",
3
3
  "description": "Harmony Code - model-driven BDD for Vitest",
4
- "version": "0.23.0",
4
+ "version": "0.23.2",
5
5
  "author": "Bernát Kalló",
6
6
  "homepage": "https://github.com/harmony-ac/code#readme",
7
7
  "repository": {