You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -34,41 +34,42 @@ Currently, ValidGen has 21 possible validations with support for some types:
34
34
| ltefield | INT ||||
35
35
| ltfield | INT ||||
36
36
37
-
In this table, STRING represents the string Go type, and BOOL represents the bool Go type.
38
-
But INT represents the ten integer Go types: int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64.
39
-
In the same way, FLOAT represents the 2 float go types: float32, float64.
40
-
In the same way, slice STRING is just []string, but slice INT is split between all integer Go types.
41
-
For array and map, the rule is the same.
42
-
And, an important modifier is "*" (pointer) because the code generated is different with or without a pointer.
43
-
44
-
For each possible combination (validation x type) is necessary to have the following tests:
45
-
- Unit test in the analyzer phase
46
-
- Unit test in the code generator phase
47
-
- Benchmark test between ValidGen and GoValidator
48
-
- End-to-end test
37
+
In this table:
38
+
-**STRING** represents the `string` Go type
39
+
-**BOOL** represents the `bool` Go type
40
+
-**INT** represents all ten integer Go types: `int`, `int8`, `int16`, `int32`, `int64`, `uint`, `uint8`, `uint16`, `uint32`, `uint64`
41
+
-**FLOAT** represents both float Go types: `float32`, `float64`
42
+
43
+
For slices, arrays, and maps, the same type expansion applies. For example, slice STRING is `[]string`, while slice INT expands to all integer Go types.
49
44
50
-
As it is necessary to test all valid and invalid scenarios, it is necessary to test all validations against all types.
51
-
At this time, it means:
52
-
- Go types (14)
53
-
-Validations (21)
54
-
-Test types (4)
55
-
-Types with and without a pointer (2)
56
-
-Tests with valid and invalid inputs (2)
45
+
Additionally, the pointer modifier (`*`) is significant because ValidGen generates different code for pointer and non-pointer types.
46
+
47
+
For each possible combination (validation × type), the following tests are required:
48
+
-Unit test for the analyzer phase
49
+
-Unit test for the code generator phase
50
+
-Benchmark test comparing ValidGen and GoValidator
51
+
-End-to-end test
57
52
58
-
14 x 21 x 4 x 2 x 2 = 4.704 distinct test cases :-)
53
+
Since we need to test both valid and invalid scenarios, all validations must be tested against all types.
54
+
Currently, this means:
55
+
- Go types: 14
56
+
- Validations: 21
57
+
- Test types: 4
58
+
- Pointer variants: 2 (with/without pointer)
59
+
- Input scenarios: 2 (valid/invalid)
59
60
60
-
With all the tests that need to be created (valid inputs, invalid inputs) for unit tests, benchmark, and end-to-end tests, creating the tests "by hand" is a tedious and error-prone task.
Some of these necessary unit tests were created "by hand", but it is a pain to keep the code in sync when supporting new operations and types.
63
+
Creating and maintaining these thousands of tests manually is tedious, error-prone, and impractical. Early attempts to write these tests by hand proved difficult to maintain when adding new operations and types.
63
64
64
-
At this time, ValidGen already has two generators:
65
-
-To generate benchmark tests between ValidGen and GoValidator
66
-
-To generate end-to-end tests
67
-
-to validate ValidGen with integer types
68
-
-to validate ValidGen with float types
69
-
-to validate all possible use cases in ValidGen (all validations x all types)
65
+
Previously, ValidGen had two separate test generators:
66
+
-Benchmark tests comparing ValidGen and GoValidator
67
+
-End-to-end tests for:
68
+
-Integer type validations
69
+
-Float type validations
70
+
-All possible use cases (all validations × all types)
70
71
71
-
But these generators do not have a common configuration, do not implement all tests for all cases, and keeping the distinct configuration files in sync is painful.
72
+
However, these generators lacked a common configuration, didn't implement all tests for all cases, and keeping the separate configuration files in sync was difficult.
72
73
73
74
## What TestGen does
74
75
@@ -83,34 +84,23 @@ High priority generators:
83
84
-[ ] End-to-end tests with all possible use cases (all validations vs all types vs valid and invalid inputs) with field operations
84
85
-[ ] Unit tests to validate the "buildValidationCode" function with field operations
85
86
86
-
Low priority generators (already exist, but they could be generated):
87
+
Low priority generators (already exist, but could be automated):
87
88
-[ ] Unit tests to validate operations (func TestOperationsIsValid)
88
89
-[ ] Unit tests to validate operation vs type (func TestOperationsIsValidByType)
89
-
-[ ] Unit tests to validate if is field operation (func TestOperationsIsFieldOperation)
90
-
-[ ] Unit tests to validate arguments count by operation (func TestOperationsArgsCount)
90
+
-[ ] Unit tests to validate field operations (func TestOperationsIsFieldOperation)
91
+
-[ ] Unit tests to validate argument count by operation (func TestOperationsArgsCount)
91
92
-[ ] Examples (in _examples/) could be generated
92
93
93
-
In some cases, valid scenarios and invalid scenarios must be generated.
94
+
Where applicable, TestGen generates both valid and invalid test scenarios.
94
95
95
-
## How TestGen works
96
+
## Usage
96
97
97
-
To be possible to generate all these tests, TestGen must have a configuration with:
0 commit comments