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
Copy file name to clipboardExpand all lines: docs/CONTRIBUTING.md
+39-6Lines changed: 39 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -15,10 +15,27 @@ Just run `make build`
15
15
In order to contribute code changes, fork this repository into your own organization, commit the code changes to a new git branch, then push the changes and create a PR.
16
16
17
17
### Code Structure
18
+
The code is using the `go/ast` package and the `golang.org/x/tools/go/analysis` module to implement the logic.
19
+
18
20
The main logic of the linter is placed in the `ginkgoLinter::run method`, in the [ginkgo_linter.go](../ginkgo_linter.go) file.
19
21
20
-
The code is using the `go/ast` package and the `golang.org/x/tools/go/analysis` module to implement the logic.
22
+
The ginkgo related code is under internal/ginkgohandler.
21
23
24
+
The gomega related code is larger and spread over several packages:
25
+
```
26
+
...
27
+
internal/
28
+
...
29
+
+ gomegahandler - holds logic to get expression information, regardless if the gomega import is done with or without dot.
30
+
+ gomegainfo - general utilities for the gomega handling code
31
+
+ expression - gomega expression types and code. Each gomega expression is modeled into these types, to later be processed by the rules
32
+
+ actual - types to model the actual part of the gomega assertion expression
33
+
+ matcher - types to model the matcher part of the gomega assertion expression
34
+
+ value - models a value in several actual and matcher types
35
+
+ rules - the gomega linter rules. A rule recieves a gomega expression and trigger a linter error if needed.
36
+
...
37
+
...
38
+
```
22
39
### Testing
23
40
Any functional code change must be tested. Please make sure to add relevant tests that demonstrate that the code changes are working. Run the full test suite to make sure that the code changes didn't break the linter functionality.
24
41
@@ -55,12 +72,28 @@ If you added a new flag, or need to test your changes with an existing flag, add
55
72
56
73
To run the unit tests, do:
57
74
```shell
58
-
go test ./...
75
+
make unit-test
59
76
```
60
77
61
-
#### Functional tests
62
-
There is a limited functional test, in [.github/workflows/sanity.yml](../.github/workflows/sanity.yml) running as a github action. The test builds the ginkgolinter executable and runs it against the test data (**Note**: the `want` comments are ignored by the actual linter. They are only working with the `analysistest.Run` function).
78
+
#### CLI test
79
+
The CLI test is done using [testscript](https://github.com/rogpeppe/go-internal). Meaning, we build a text base isolated
80
+
environment for each test, with all the required files.
81
+
82
+
These test files are located under tests/testdata, and contains a test script and the required files within the same
83
+
txtar file.
63
84
64
-
The test counts the number of linter warnings with different combinations of the commandline flags.
85
+
The purpose of these tests is to check the CLI itself. We don't want to test everything there, but only the CLI and its
86
+
command line parameters.
65
87
66
-
Make sure to update the expected numbers to match your changes.
88
+
If you made a change with the flags, make sure to check this change in the CLI test. For regular change, use the
0 commit comments