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: CONTRIBUTING.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -10,4 +10,4 @@ Your contributions to Ginkgo are essential for its long-term maintenance and imp
10
10
- Vet your changes via `go vet ./...`
11
11
- Update the documentation. Ginkgo uses `godoc` comments and documentation in `docs/index.md`. You can run `bundle exec jekyll serve` in the `docs` directory to preview your changes.
Copy file name to clipboardExpand all lines: docs/index.md
+12-6
Original file line number
Diff line number
Diff line change
@@ -2697,6 +2697,12 @@ These mechanisms can all be used in concert. They combine with the following ru
2697
2697
- Programmatic filters always apply and result in a non-zero exit code. Any additional CLI filters only apply to the subset of specs selected by the programmatic filters.
2698
2698
- When multiple CLI filters (`--label-filter`, `--focus-file/--skip-file`, `--focus/--skip`) are provided they are all ANDed together. The spec must satisfy the label filter query **and** any location-based filters **and** any description based filters.
2699
2699
2700
+
#### Avoiding filtering out all tests
2701
+
2702
+
Especially for CI it is useful to fail when all tests were filtered out by accident (either via skip or typo in label filter).
2703
+
2704
+
`ginkgo --fail-on-empty --label-filter mytypo ./...` will fail since no test was run.
2705
+
2700
2706
### Repeating Spec Runs and Managing Flaky Specs
2701
2707
2702
2708
Ginkgo wants to help you write reliable, deterministic, tests. Flaky specs - i.e. specs that fail _sometimes_ in non-deterministic or difficult to reason about ways - can be incredibly frustrating to debug and can erode faith in the value of a spec suite.
are all valid interruptible signatures. Of course you can specify `context.Context` instead and can mix-and-match interruptibility between the two functions.
3100
3106
3101
-
**Reporting** nodes `ReportAfterEach`, `ReportBeforeEach`, `ReportBeforeSuite``ReportAfterSuite` can be made interruptible,
3102
-
to do this you need to provide it a node function which accepts both `SpecContext` and `SpecReport` for `*Each` nodes and `Report` for `*Suite` nodes.
3107
+
**Reporting** nodes `ReportAfterEach`, `ReportBeforeEach`, `ReportBeforeSuite``ReportAfterSuite` can be made interruptible,
3108
+
to do this you need to provide it a node function which accepts both `SpecContext` and `SpecReport` for `*Each` nodes and `Report` for `*Suite` nodes.
3103
3109
3104
3110
As for **Container** nodes, since these run during the Tree Construction Phase they cannot be made interruptible and so do not accept functions that expect a context. And since the `By` annotation is simply syntactic sugar enabling more detailed spec documentation, any callbacks passed to `By` cannot be independently marked as interruptible (you should, instead, use the `context` passed into the node that you're calling `By` from).
3105
3111
@@ -3502,7 +3508,7 @@ Ginkgo's reporting infrastructure provides an alternative solution for this use
3502
3508
3503
3509
Ginkgo provides four reporting-focused nodes `ReportAfterEach`, `ReportBeforeEach``ReportBeforeSuite`, and `ReportAfterSuite`.
3504
3510
3505
-
`ReportAfterEach` behaves similarly to a standard `AfterEach` node and can be declared anywhere an `AfterEach` node can be declared.
3511
+
`ReportAfterEach` behaves similarly to a standard `AfterEach` node and can be declared anywhere an `AfterEach` node can be declared.
3506
3512
`ReportAfterEach` can take either a closure that accepts a single [`SpecReport`](https://pkg.go.dev/github.com/onsi/ginkgo/v2/types#SpecReport) argument or both `SpecContext` and `SpecReport`
3507
3513
For example, we could implement a top-level ReportAfterEach that emits information about every spec to a remote server:
In addition, `ReportAfterEach` closures are called after a spec completes. i.e. _after_ all `AfterEach` closures have run. This gives them access to the complete final state of the spec. Note that if a failure occurs in a `ReportAfterEach` your the spec will be marked as failed. Subsequent `ReportAfterEach` closures will see the failed state, but not the closure in which the failure occurred.
3524
3530
3525
-
`ReportAfterEach` is useful if you need to stream or emit up-to-date information about the suite as it runs. Ginkgo also provides `ReportBeforeEach` which is called before the test runs and
3531
+
`ReportAfterEach` is useful if you need to stream or emit up-to-date information about the suite as it runs. Ginkgo also provides `ReportBeforeEach` which is called before the test runs and
3526
3532
receives a preliminary `types.SpecReport` ( or both `SpecContext` and `types.SpecReport` for interruptible behaviour) - the state of this report will indicate whether the test will be skipped or is marked pending.
3527
3533
3528
3534
You should be aware that when running in parallel, each parallel process will be running specs and their `ReportAfterEach`es. This means that multiple `ReportAfterEach` blocks can be running concurrently on independent processes. Given that, code like this won't work:
you'll end up with multiple processes writing to the same file and the output will be a mess. There is a better approach for this usecase...
3543
3549
3544
3550
#### Reporting Nodes - ReportBeforeSuite and ReportAfterSuite
3545
-
`ReportBeforeSuite` and `ReportAfterSuite` nodes behave similarly to `BeforeSuite` and `AfterSuite` and can be placed at the top-level of your suite (typically in the suite bootstrap file).
3551
+
`ReportBeforeSuite` and `ReportAfterSuite` nodes behave similarly to `BeforeSuite` and `AfterSuite` and can be placed at the top-level of your suite (typically in the suite bootstrap file).
3546
3552
`ReportBeforeSuite` node take a closure that accepts either [`Report`]((https://pkg.go.dev/github.com/onsi/ginkgo/v2/types#Report)) or, both `SpecContext` and `Report` converting the node to an interruptible node.
0 commit comments