Fix typos

CHANGELOG.md

@@ -44,7 +44,7 @@ You can silence the RC advertisement by setting an `ACK_GINKG_RC=true` environme
 ## 1.16.1
 
 ### Fixes
-- Supress --stream deprecation warning on windows (#793)
+- Suppress --stream deprecation warning on windows (#793)
 
 ## 1.16.0
 
@@ -222,7 +222,7 @@ You can silence the RC advertisement by setting an `ACK_GINKG_RC=true` environme
 - fix: for `go vet` to pass [69338ec]
 - docs: fix for contributing instructions [7004cb1]
 - consolidate and streamline contribution docs (#494) [d848015]
-- Make generated Junit file compatable with "Maven Surefire" (#488) [e51bee6]
+- Make generated Junit file compatible with "Maven Surefire" (#488) [e51bee6]
 - all: gofmt [000d317]
 - Increase eventually timeout to 30s [c73579c]
 - Clarify asynchronous test behaviour [294d8f4]
@@ -334,7 +334,7 @@ Bug Fixes:
 - Fix incorrect failure message when a panic occurs during a parallel test run
 - Fixed an issue where a pending test within a focused context (or a focused test within a pending context) would skip all other tests.
 - Be more consistent about handling SIGTERM as well as SIGINT
-- When interupted while concurrently compiling test suites in the background, Ginkgo now cleans up the compiled artifacts.
+- When interrupted while concurrently compiling test suites in the background, Ginkgo now cleans up the compiled artifacts.
 - Fixed a long standing bug where `ginkgo -p` would hang if a process spawned by one of the Ginkgo parallel nodes does not exit. (Hooray!)
 
 ## 1.1.0 (8/2/2014)

README.md

@@ -102,7 +102,7 @@ ginkgo -p
 
 By following [established patterns for writing parallel specs](https://onsi.github.io/ginkgo/#patterns-for-parallel-integration-specs) you can build even large, complex integration suites that parallelize cleanly and run performantly.
 
-As your suites grow Ginkgo helps you keep your specs organized with [labels](https://onsi.github.io/ginkgo/#spec-labels) and lets you easily run [subsets of specs](https://onsi.github.io/ginkgo/#filtering-specs), either [programatically](https://onsi.github.io/ginkgo/#focused-specs) or on the [command line](https://onsi.github.io/ginkgo/#combining-filters).  And Ginkgo's reporting infrastructure generates machine-readable output in a [variety of formats](https://onsi.github.io/ginkgo/#generating-machine-readable-reports) _and_ allows you to build your own [custom reporting infrastructure](https://onsi.github.io/ginkgo/#generating-reports-programmatically).
+As your suites grow Ginkgo helps you keep your specs organized with [labels](https://onsi.github.io/ginkgo/#spec-labels) and lets you easily run [subsets of specs](https://onsi.github.io/ginkgo/#filtering-specs), either [programmatically](https://onsi.github.io/ginkgo/#focused-specs) or on the [command line](https://onsi.github.io/ginkgo/#combining-filters).  And Ginkgo's reporting infrastructure generates machine-readable output in a [variety of formats](https://onsi.github.io/ginkgo/#generating-machine-readable-reports) _and_ allows you to build your own [custom reporting infrastructure](https://onsi.github.io/ginkgo/#generating-reports-programmatically).
 
 Ginkgo ships with `ginkgo`, a [command line tool](https://onsi.github.io/ginkgo/#ginkgo-cli-overview) with support for generating, running, filtering, and profiling Ginkgo suites.  You can even have Ginkgo automatically run your specs when it detects a change with `ginkgo watch`, enabling rapid feedback loops during test-driven development.
 

config/deprecated.go

@@ -49,21 +49,21 @@ type DeprecatedDefaultReporterConfigType struct {
 }
 
 // Sadly there is no way to gracefully deprecate access to these global config variables.
-// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguraiton() method
+// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguration() method
 // These new unwieldy type names exist to give users a hint when they try to compile and the compilation fails
 type GinkgoConfigIsNoLongerAccessibleFromTheConfigPackageUseTheDSLsGinkgoConfigurationFunctionInstead struct{}
 
 // Sadly there is no way to gracefully deprecate access to these global config variables.
-// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguraiton() method
+// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguration() method
 // These new unwieldy type names exist to give users a hint when they try to compile and the compilation fails
 var GinkgoConfig = GinkgoConfigIsNoLongerAccessibleFromTheConfigPackageUseTheDSLsGinkgoConfigurationFunctionInstead{}
 
 // Sadly there is no way to gracefully deprecate access to these global config variables.
-// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguraiton() method
+// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguration() method
 // These new unwieldy type names exist to give users a hint when they try to compile and the compilation fails
 type DefaultReporterConfigIsNoLongerAccessibleFromTheConfigPackageUseTheDSLsGinkgoConfigurationFunctionInstead struct{}
 
 // Sadly there is no way to gracefully deprecate access to these global config variables.
-// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguraiton() method
+// Users who need access to Ginkgo's configuration should use the DSL's GinkgoConfiguration() method
 // These new unwieldy type names exist to give users a hint when they try to compile and the compilation fails
 var DefaultReporterConfig = DefaultReporterConfigIsNoLongerAccessibleFromTheConfigPackageUseTheDSLsGinkgoConfigurationFunctionInstead{}

core_dsl.go

@@ -115,7 +115,7 @@ The first return value is the SuiteConfig which controls aspects of how the suit
 the second return value is the ReporterConfig which controls aspects of how Ginkgo's default
 reporter emits output.
 
-Mutating the returned configurations has no effect.  To reconfigure Ginkgo programatically you need
+Mutating the returned configurations has no effect.  To reconfigure Ginkgo programmatically you need
 to pass in your mutated copies into RunSpecs().
 
 You can learn more at https://onsi.github.io/ginkgo/#overriding-ginkgos-command-line-configuration-in-the-suite
@@ -184,7 +184,7 @@ If you bootstrapped your suite with "ginkgo bootstrap" this is already
 done for you.
 
 Ginkgo is typically configured via command-line flags.  This configuration
-can be overriden, however, and passed into RunSpecs as optional arguments:
+can be overridden, however, and passed into RunSpecs as optional arguments:
 
 	func TestMySuite(t *testing.T)  {
 		RegisterFailHandler(gomega.Fail)

docs/MIGRATING_TO_V2.md

@@ -40,7 +40,7 @@ The next sections describe the [new features in Ginkgo 2.0](#major-additions-and
 ### Interrupt Behavior
 Interrupt behavior is substantially improved, sending an interrupt signal will now:
 	- immediately cause the current test to unwind.  Ginkgo will run any `AfterEach` blocks, then immediately skip all remaining tests, then run the `AfterSuite` block.  
-	- emit information about which node Ginkgo was running when the interrupt signal was recevied.
+	- emit information about which node Ginkgo was running when the interrupt signal was received.
 	- emit as much information as possible about the interrupted test (e.g. `GinkgoWriter` contents, `stdout` and `stderr` context).
 	- emit a stack trace of every running goroutine at the moment of interruption.
 
@@ -245,7 +245,7 @@ Ginkgo V2 provides an improved reporting infrastructure that [replaces and impro
 #### Generating machine-readable reports
 Ginkgo now natively supports generating and aggregating reports in a number of machine-readable formats - and these reports can be generated and managed by simply passing `ginkgo` command line flags.
 
-Ginkgo V2 introduces a new JSON format that faithfully captures all avialable information about a Ginkgo test suite.  JSON reports can be generated via `ginkgo --json-report=out.json`.  The resulting JSON file encodes an array of `types.Report`.  Each entry in that array lists detailed information about the test suite and includes a list of `types.SpecReport` that captures detailed information about each spec.  These types are documented [here](https://github.com/onsi/ginkgo/blob/ver2/types/types.go).
+Ginkgo V2 introduces a new JSON format that faithfully captures all available information about a Ginkgo test suite.  JSON reports can be generated via `ginkgo --json-report=out.json`.  The resulting JSON file encodes an array of `types.Report`.  Each entry in that array lists detailed information about the test suite and includes a list of `types.SpecReport` that captures detailed information about each spec.  These types are documented [here](https://github.com/onsi/ginkgo/blob/ver2/types/types.go).
 
 Ginkgo also supports generating JUnit reports with `ginkgo --junit-report=out.xml` and Teamcity reports with `ginkgo --teamcity-report=out.teamcity`.  In addition, Ginkgo V2's JUnit reporter has been improved and is now more conformant with the JUnit specification.
 
@@ -377,7 +377,7 @@ When generating profiles for `-cpuprofile=FILE`, `-blockprofile=FILE`, `-memprof
 Coverage reporting is much improved in 2.0:
 
 - `ginkgo -cover -p` now emits code coverage after the test completes, just like `ginkgo -cover` does in series.
-- When running across mulitple packages (e.g. `ginkgo -r -cover`) ginkgo will now emit a composite coverage statistic that represents the total coverage across all test suites run.  (Note that this is disabled if you set `-keep-separate-coverprofiles`).
+- When running across multiple packages (e.g. `ginkgo -r -cover`) ginkgo will now emit a composite coverage statistic that represents the total coverage across all test suites run.  (Note that this is disabled if you set `-keep-separate-coverprofiles`).
 
 In addition, Ginkgo now follows the following rules when generating cover profiles using `-cover` and/or `-coverprofile=FILE`:
 
@@ -410,7 +410,7 @@ In V1 Ginkgo would run windows tests in parallel with the `--stream` option.  Th
 - Ginkgo's OutputInterceptor (the component that intercepts stdout/stderr when running in parallel) should now be more performant and better handle edge cases.  It can be paused and resumed with PauseOutputInterception() and ResumeOutputInterception() and disabled entirely with --output-interceptor-mode=none.
 
 ## Major Changes
-These are major changes that will need user intervention to migrate succesfully.
+These are major changes that will need user intervention to migrate successfully.
 
 ### Removed: Async Testing
 As described in the [Ginkgo 2.0 Proposal](https://docs.google.com/document/d/1h28ZknXRsTLPNNiOjdHIO-F2toCzq4xoZDXbfYaBdoQ/edit#heading=h.mzgqmkg24xoo) the Ginkgo 1.x implementation of asynchronous testing using a `Done` channel was a confusing source of test-pollution.  It is removed in Ginkgo 2.0.
@@ -474,7 +474,7 @@ Alternatively, you can use the new `--json-report` flag to produce a machine rea
 Finally, if you still need the real-time reporting capabilities that 1.X's custom reporters provided you can use [`ReportBeforeEach` and `ReportAfterEach`](#capturing-report-information-about-each-spec-as-the-test-suite-runs) to get information about each spec as it completes.
 
 ### Changed: First-class Support for Table Testing
-The table extension has been moved into the core Ginkgo DSL and the table functionality has been improved while maintaining backward compatibility.  Users no longer need to `import "github.com/onsi/ginkgo/v2/extenstions/table"`.  Instead the table DSL is automatically pulled in by importing `"github.com/onsi/ginkgo/v2"`.
+The table extension has been moved into the core Ginkgo DSL and the table functionality has been improved while maintaining backward compatibility.  Users no longer need to `import "github.com/onsi/ginkgo/v2/extensions/table"`.  Instead the table DSL is automatically pulled in by importing `"github.com/onsi/ginkgo/v2"`.
 
 #### Migration Strategy:
 Remove `"github.com/onsi/ginkgo/v2/extensions/table` imports.  Code that was dot-importing both Ginkgo and the table extension should automatically work.  If you were not dot-importing you will need to replace references to `table.DescribeTable` and `table.Entry` with `ginkgo.DescribeTable` and `ginkgo.Entry`.
@@ -496,7 +496,7 @@ V1 also allowed mutating the global config objects which could lead to strange b
 #### Migration Strategy:
 Instead, configuration can be accessed using the DSL's `GinkgoConfiguration()` function.  This will return a `types.SuiteConfig` and `types.ReporterConfig`.  Users generally don't need to access this configuration - the most commonly used fields by end users are already made available via `GinkgoRandomSeed()` and `GinkgoParallelProcess()`.
 
-It is generally recommended that users use the CLI to configure Ginkgo as some aspects of configuration must apply to the CLI as well as the suite under tests - nonetheless there are contexts where it is necessary to change Ginkgo's configuration programatically.  V2 supports this by allowing users to pass updated configuration into `RunSpecs`:
+It is generally recommended that users use the CLI to configure Ginkgo as some aspects of configuration must apply to the CLI as well as the suite under tests - nonetheless there are contexts where it is necessary to change Ginkgo's configuration programmatically.  V2 supports this by allowing users to pass updated configuration into `RunSpecs`:
 
 ```go
 func TestMySuite(t *testing.T)  {
@@ -579,7 +579,7 @@ These are minor changes that will be transparent for most users.
 
 - `"top level"` is no longer the first element in `types.SpecReport.NodeTexts`.  This will only affect users who write custom reporters.
 
-- The output format of Ginkgo's Default Reporter has changed in numerous subtle ways to improve readability and the user experience.  Users who were scraping Ginkgo output programatically may need to change their scripts or use the new JSON formatted report option.
+- The output format of Ginkgo's Default Reporter has changed in numerous subtle ways to improve readability and the user experience.  Users who were scraping Ginkgo output programmatically may need to change their scripts or use the new JSON formatted report option.
 
 - When running in series and verbose mode (i.e. `ginkgo -v`) GinkgoWriter output is emitted in real-time (existing behavior) but also emitted in the failure message for failed tests.  This allows for consistent failure messages regardless of verbosity settings and also makes it possible for the resulting JSON report to include captured GinkgoWriter information.
 
@@ -666,7 +666,7 @@ This _also_ means that you can, in principle, upgrade different test suites in y
 ### A symbol in V2 now clashes with a symbol in my codebase.  What do I do?
 If Ginkgo 2.0 introduces a new exported symbl that now clashes with your codebase (because you are dot-importing Ginkgo). Check out the [Alternatives to Dot-Importing Ginkgo](https://onsi.github.io/ginkgo/#alternatives-to-dot-importing-ginkgo) section of the documentation for some options.  You may be able to, instead, dot-import just a subset of the Ginkgo DSL using the new `github.com/onsi/ginkgo/v2/dsl` set of packages.
 
-Specificaly when upgrading from v1 to v2 if you see a dot-import clash due to a newly introduced symbol (e.g. the new `Label` decorator) you can instead choose to dot-import the core DSL and import the `decorator` dsl separately:
+Specifically when upgrading from v1 to v2 if you see a dot-import clash due to a newly introduced symbol (e.g. the new `Label` decorator) you can instead choose to dot-import the core DSL and import the `decorator` dsl separately:
 
 ```go
 import (

docs/index.md

@@ -1512,7 +1512,7 @@ Will generate entries named: `1 + 2 = 3`, `-1 + 2 = 1`, `zeros`, `110 = 10 + 100
 
 ### Alternatives to Dot-Importing Ginkgo
 
-As shown througout this documentation, Ginkgo users are encouraged to dot-import the Ginkgo DSL into their test suites to effectively extend the Go language with Ginkgo's expressive building blocks:
+As shown throughout this documentation, Ginkgo users are encouraged to dot-import the Ginkgo DSL into their test suites to effectively extend the Go language with Ginkgo's expressive building blocks:
 
 ```go
 import . "github.com/onsi/ginkgo/v2"
@@ -2154,7 +2154,7 @@ BeforeEach(func() {
 })
 ```
 
-now, every spec will be guaranteed to start with the same initial state and we are free to write our specs without worrying about spec polution.
+now, every spec will be guaranteed to start with the same initial state and we are free to write our specs without worrying about spec pollution.
 
 This behavior, however, will cause specs in Ordered containers to break.  Consider this set of specs:
 
@@ -2893,7 +2893,7 @@ When running in CI you'll want to make sure that the version of the `ginkgo` CLI
 
 `go run github.com/onsi/ginkgo/v2/ginkgo`
 
-This alone, however, is often not enought.  The Ginkgo CLi includes additional dependencies that aren't part of the Ginkgo library - since your code doesn't import the cli these dependencies probably aren't in your `go.sum` file.  To get around this it is idiomatic Go to introduce a `tools.go` file.  This can go anywhere in your module - for example, Gomega places its `tools.go` at the top-level.  Your `tools.go` file should look like:
+This alone, however, is often not enough.  The Ginkgo CLi includes additional dependencies that aren't part of the Ginkgo library - since your code doesn't import the cli these dependencies probably aren't in your `go.sum` file.  To get around this it is idiomatic Go to introduce a `tools.go` file.  This can go anywhere in your module - for example, Gomega places its `tools.go` at the top-level.  Your `tools.go` file should look like:
 
 ```go
 //go:build tools
@@ -3264,7 +3264,7 @@ var _ = BeforeSuite(func() {
 Describe("Storing and retrieving the book fixtures", func() {
   for _, book := range fixtureBooks {
     book := book
-    It(fmt.Sprintf("can store and retreive %s", book.Title), func() {
+    It(fmt.Sprintf("can store and retrieve %s", book.Title), func() {
       Expect(library.Store(book)).To(Succeed())
       DeferCleanup(library.Delete, book)
       Expect(library.FindByTitle(book.Title)).To(Equal(book))            
@@ -4500,7 +4500,7 @@ The columns are:
 - Focused (bool): True, if focused. (Conforms to the rules in [Focused Specs](#focused-specs).)
 - Pending (bool): True, if pending. (Conforms to the rules in [Pending Specs](#pending-specs).)
 
-You can set a different output format with the `-format` flag. Accepted formats are `csv`, `indent`, and `json`. The `ident` format is like `csv`, but uses identation to show the nesting of containers and specs. Both the `csv` and `json` formats can be read by another program, e.g., an editor plugin that displays a tree view of Ginkgo tests in a file, or presents a menu for the user to quickly navigate to a container or spec.
+You can set a different output format with the `-format` flag. Accepted formats are `csv`, `indent`, and `json`. The `ident` format is like `csv`, but uses indentation to show the nesting of containers and specs. Both the `csv` and `json` formats can be read by another program, e.g., an editor plugin that displays a tree view of Ginkgo tests in a file, or presents a menu for the user to quickly navigate to a container or spec.
 
 `ginkgo outline` is intended for integration with third-party libraries and applications.  If you simply want to know how a suite will run without running it try `ginkgo -v --dry-run` instead.
 
@@ -4584,7 +4584,7 @@ var _ = Describe("Consumer", func() {
 
 Since `GinkgoT()` implements `Cleanup()` (using `DeferCleanup()` under the hood) Gomock will automatically register a call to `mockCtrl.Finish()` when the controller is created.
 
-When using Gomock you may want to run `ginkgo` with the `-trace` flag to print out stack traces for failures which will help you trace down where, in your code, invalid calls occured.
+When using Gomock you may want to run `ginkgo` with the `-trace` flag to print out stack traces for failures which will help you trace down where, in your code, invalid calls occurred.
 
 ### 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.