Skip to content

Commit

Permalink
Document areas where GinkgoT() behaves differently from testing.T
Browse files Browse the repository at this point in the history
adresses #1331
  • Loading branch information
onsi committed Jan 17, 2024
1 parent 6f67a14 commit dbaf18f
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 0 deletions.
5 changes: 5 additions & 0 deletions docs/index.md
Expand Up @@ -5480,6 +5480,11 @@ When using Gomock you may want to run `ginkgo` with the `-trace` flag to print o
Similarly for third party libraries which accept a `testing.TB` interface, use the `GinkgoTB()` function. This function returns a struct wrapper around `GinkgoT()` which satisfies the `testing.TB`interface. If you need to use any Ginkgo-specific methods you can access the wrapped `GinkgoT()` instance using `GinkgoTBWrapper.GinkgoT`.
In general, `GinkgoT()` attempts to mimic the behavior of `testing.T` with the exception of the following:
- `Error`/`Errorf`: failures in Ginkgo always immediately stop execution and there is no mechanism to log a failure without aborting the test. As such `Error`/`Errorf` are equivalent to `Fatal`/`Fatalf`.
- `Parallel()` is a no-op as Ginkgo's multi-process parallelism model is substantially different from go test's in-process model.
### IDE Support
Ginkgo works best from the command-line, and [`ginkgo watch`](#watching-for-changes) makes it easy to rerun tests on the command line whenever changes are detected.
Expand Down
5 changes: 5 additions & 0 deletions ginkgo_t_dsl.go
Expand Up @@ -15,6 +15,11 @@ GinkgoT() is analogous to *testing.T and implements the majority of *testing.T's
GinkgoT() takes an optional offset argument that can be used to get the
correct line number associated with the failure - though you do not need to use this if you call GinkgoHelper() or GinkgoT().Helper() appropriately
GinkgoT() attempts to mimic the behavior of `testing.T` with the exception of the following:
- Error/Errorf: failures in Ginkgo always immediately stop execution and there is no mechanism to log a failure without aborting the test. As such Error/Errorf are equivalent to Fatal/Fatalf.
- Parallel() is a no-op as Ginkgo's multi-process parallelism model is substantially different from go test's in-process model.
You can learn more here: https://onsi.github.io/ginkgo/#using-third-party-libraries
*/
func GinkgoT(optionalOffset ...int) FullGinkgoTInterface {
Expand Down

0 comments on commit dbaf18f

Please sign in to comment.