documentation fixes throughout for affect vs effect

karenetheridge · karenetheridge · commit 773ab789c1dd · 2025-01-28T09:53:03.000-08:00
and a few other typo fixes
diff --git a/Changes b/Changes
@@ -1038,7 +1038,7 @@ Test-Simple 1.302013_013 2016-03-08 09:19:39-08:00 America/Los_Angeles (TRIAL RE
 
 Test-Simple 1.302013_012 2016-01-28 20:38:16-08:00 America/Los_Angeles (TRIAL RELEASE)
 
-    - $Level effects all contexts once Test::Builder is loaded
+    - $Level affects all contexts once Test::Builder is loaded
     - Requires Test2 0.000023
 
 Test-Simple 1.302013_011 2016-01-14 21:55:28-08:00 America/Los_Angeles (TRIAL RELEASE)
@@ -1395,7 +1395,7 @@ Test-Simple 0.89_01 2009-Jun-23 15:13-08:00 EDT
     Test Fixes
     * Small fixes for integration with the Perl core
       [bleadperl eaa0815147e13cd4ab5b3d6ca8f26544a9f0c3b4]
-    * exit code tests could be effected by errno when PERLIO=stdio
+    * exit code tests could be affected by errno when PERLIO=stdio
       [bleadperl c76230386fc5e6fba9fdbeab473abbf4f4adcbe3]
 
 
diff --git a/lib/Test/Builder.pm b/lib/Test/Builder.pm
@@ -2568,7 +2568,7 @@ If you fail more than 254 tests, it will be reported as 254.
 
 In perl 5.8.1 and later, Test::Builder is thread-safe.  The test number is
 shared by all threads.  This means if one thread sets the test number using
-C<current_test()> they will all be effected.
+C<current_test()> they will all be affected.
 
 While versions earlier than 5.8.1 had threads they contain too many
 bugs to support.
diff --git a/lib/Test/Builder/Tester.pm b/lib/Test/Builder/Tester.pm
@@ -280,7 +280,7 @@ Actually performs the output check testing the tests, comparing the
 data (with C<eq>) that we have captured from L<Test::Builder> against
 what was declared with C<test_out> and C<test_err>.
 
-This takes name/value pairs that effect how the test is run.
+This takes name/value pairs that affect how the test is run.
 
 =over
 
@@ -438,8 +438,8 @@ sub color {
 
 Test::Builder::Tester does not handle plans well. It has never done anything
 special with plans. This means that plans from outside Test::Builder::Tester
-will effect Test::Builder::Tester, worse plans when using Test::Builder::Tester
-will effect overall testing. At this point there are no plans to fix this bug
+will affect Test::Builder::Tester, worse plans when using Test::Builder::Tester
+will affect overall testing. At this point there are no plans to fix this bug
 as people have come to depend on it, and Test::Builder::Tester is now
 discouraged in favor of C<Test2::API::intercept()>. See
 L<https://github.com/Test-More/test-more/issues/667>
diff --git a/lib/Test2/API.pm b/lib/Test2/API.pm
@@ -1300,7 +1300,7 @@ formatter being used.
 In both cases events are generated and stored in an array. This array is
 eventually used to populate the C<subevents> attribute on the
 L<Test2::Event::Subtest> event that is generated at the end of the subtest.
-This flag has no effect on this part, it always happens.
+This flag has no effect on this part; it always happens.
 
 At the end of the subtest, the final L<Test2::Event::Subtest> event is sent to
 the formatter.
diff --git a/lib/Test2/API/InterceptResult/Event.pm b/lib/Test2/API/InterceptResult/Event.pm
@@ -591,7 +591,7 @@ that subtest results can be turned into instances of it on demand.
 
 =item $copy = $event->clone
 
-Create a deep copy of the event. Modifying either event will not effect the
+Create a deep copy of the event. Modifying either event will not affect the
 other.
 
 =back
diff --git a/lib/Test2/AsyncSubtest.pm b/lib/Test2/AsyncSubtest.pm
@@ -713,7 +713,7 @@ L<Test2::Event::Ok> event.
 =item silent => 1
 
 This will prevent finish from generating a final L<Test2::Event::Subtest>
-event. This effectively ends the subtest without it effecting the parent
+event. This effectively ends the subtest without it affecting the parent
 subtest (or top level test).
 
 =item no_plan => 1
diff --git a/lib/Test2/Compare.pm b/lib/Test2/Compare.pm
@@ -277,7 +277,7 @@ listed first:
 =item implicit_end => 1
 
 This option toggles array/hash boundaries. If this is true then no extra hash
-keys or array indexes will be allowed. This setting effects generated compare
+keys or array indexes will be allowed. This setting affects generated compare
 objects as well as any passed in.
 
 =item use_regex => 1
diff --git a/lib/Test2/Event.pm b/lib/Test2/Event.pm
@@ -414,7 +414,7 @@ match.
 
 =item $e->add_amnesty({tag => $TAG, details => $DETAILS});
 
-This can be used to add amnesty to this event. Amnesty only effects failing
+This can be used to add amnesty to this event. Amnesty only affects failing
 assertions in most cases, but some formatters may display them for passing
 assertions, or even non-assertions as well.
 
diff --git a/lib/Test2/Manual/Anatomy/EndToEnd.pm b/lib/Test2/Manual/Anatomy/EndToEnd.pm
@@ -155,12 +155,12 @@ If a new context was created, context-creation hooks will fire.
 =item $!, $@, $?, and $^E are restored.
 
 We make sure $!, $@, $?, and $^E are unchanged at this point so that changes we
-made will not effect anything else. This is done in case something inside the
+made will not affect anything else. This is done in case something inside the
 context construction accidentally changed these vars.
 
 =item The context is returned.
 
-You have a shiney new context object, or a clone of the existing context.
+You have a shiny new context object, or a clone of the existing context.
 
 =back
 
@@ -196,9 +196,9 @@ event can modify global test state.
 
 =item The global test state is updated to reflect the event.
 
-If the event effects test count then the count will be incremented. If the
+If the event affects test count then the count will be incremented. If the
 event causes failure then the failure count will be incremented. There are a
-couple other ways the global state can be effected as well.
+few other ways the global state can be affected as well.
 
 =item The event is sent to the formatter
 
diff --git a/lib/Test2/Manual/Anatomy/Event.pm b/lib/Test2/Manual/Anatomy/Event.pm
@@ -14,7 +14,7 @@ Test2::Manual::Anatomy::Event - The internals of events
 
 =head1 DESCRIPTION
 
-Events are how tools effect global state, and pass information along to the
+Events are how tools affect global state, and pass information along to the
 harness, or the human running the tests.
 
 =head1 HISTORY
diff --git a/lib/Test2/Manual/Anatomy/Hubs.pm b/lib/Test2/Manual/Anatomy/Hubs.pm
@@ -56,10 +56,10 @@ connection to the parent hub, and usually does not have a formatter.
 
 =head1 WHEN SHOULD I ADD A HUB TO THE STACK?
 
-Any time you want to intercept or block events from effecting the test state.
+Any time you want to intercept or block events from affecting the test state.
 Adding a new hub is essentially a way to create a sandbox where you have
 absolute control over what events do. Adding a new hub insures that the main
-test state will not be effected.
+test state will not be affected.
 
 =head1 WHERE IS THE STACK?
 
diff --git a/lib/Test2/Manual/Anatomy/IPC.pm b/lib/Test2/Manual/Anatomy/IPC.pm
@@ -22,7 +22,7 @@ The IPC system is activated by loading L<Test2::IPC>. This makes hubs
 process/thread aware, and makes them forward events along to the parent
 process/thread as necessary.
 
-=head1 HOW DOES THE IPC SYSTEM EFFECT EVERYTHING?
+=head1 HOW DOES THE IPC SYSTEM AFFECT EVERYTHING?
 
 L<Test2::API> and L<Test2::API::Instance> have some behaviors that trigger if
 L<Test2::IPC> is loaded before the global state is initialized. Mainly an IPC
diff --git a/lib/Test2/Manual/Testing/Todo.pm b/lib/Test2/Manual/Testing/Todo.pm
@@ -71,7 +71,7 @@ todo).
 =head1 HOW THE TODO TOOLS WORK UNDER THE HOOD
 
 The L<Test2::Todo> library gets the current L<Test2::Hub> instance and adds a
-filter. The filter that is added will set the todo and effective pass fields on
+filter. The filter that is added will set the C<todo> and C<effective_pass> fields on
 any L<Test2::Event::Ok> events that pass through the hub. The filter also
 converts L<Test2::Event::Diag> events into L<Test2::Event::Note> events.
 
diff --git a/lib/Test2/Manual/Tooling/Nesting.pm b/lib/Test2/Manual/Tooling/Nesting.pm
@@ -80,7 +80,7 @@ the start of your function, and release it at the end... yes it is that simple.
 
 See, that was easy. With these 2 additional lines we know have proper file+line
 reporting. The nested tools will find the context we acquired here, and know to
-use it's file and line numbers.
+use its file and line numbers.
 
 =head3 THE OLD WAY (DO NOT DO THIS ANYMORE)
 
diff --git a/lib/Test2/Manual/Tooling/Testing.pm b/lib/Test2/Manual/Tooling/Testing.pm
@@ -38,7 +38,7 @@ No events or contexts generated within the intercept codeblock will have any
 effect on the outside testing state. The C<intercept> function completely
 isolates the tools called within.
 
-B<Note:> Plugins and things that effect global API state may not be fully
+B<Note:> Plugins and things that affect global API state may not be fully
 isolated. C<intercept> is intended specifically for event isolation.
 
 The C<intercept> function will return an arrayref containing all the events
diff --git a/lib/Test2/Plugin.pm b/lib/Test2/Plugin.pm
@@ -18,7 +18,7 @@ Test2::Plugin - Documentation for plugins
 
 =head1 DESCRIPTION
 
-Plugins are packages that cause behavior changes, or other side effects for the
+Plugins are packages that cause behavior changes, or other side-effects for the
 test file that loads them. They should not export any functions, or provide any
 tools. Plugins should be distinct units of functionality.
 
diff --git a/lib/Test2/Suite.pm b/lib/Test2/Suite.pm
@@ -47,11 +47,11 @@ any number of plugins.
 
 =back
 
-If you want to write something that both exports new functions, and effects
+If you want to write something that both exports new functions, and affects
 behavior, you should write both a Tools distribution, and a Plugin distribution,
 then a Bundle that loads them both. This is important as it helps avoid the
 problem where a package exports much-desired tools, but
-also produces undesirable side effects.
+also produces undesirable side-effects.
 
 =head1 INCLUDED BUNDLES
 
diff --git a/lib/Test2/Tools.pm b/lib/Test2/Tools.pm
@@ -22,9 +22,9 @@ Tools are packages that export test functions, typically all related to a
 specific aspect of testing. If you have a couple different categories of
 exports then you may want to break them into separate modules.
 
-Tools should export testing functions. Loading tools B<should not> have side
+Tools should export testing functions. Loading tools B<should not> have side-
 effects, or alter the behavior of other tools. If you want to alter behaviors
-or create side effects then you probably want to write a L<Test2::Plugin>.
+or create side-effects then you probably want to write a L<Test2::Plugin>.
 
 =head1 FAQ
 
diff --git a/xt/author/pod-spell.t b/xt/author/pod-spell.t
@@ -234,7 +234,6 @@ reftype
 renderer
 renderers
 setpos
-shiney
 sref
 str
 subevent
