[Cgreen-commits] SF.net SVN: cgreen:[554] trunk/cgreen/doc/cgreen-guide-en.asciidoc

[<th...@us...>]

Revision: 554
          http://sourceforge.net/p/cgreen/code/554
Author:   thoni56
Date:     2014-07-19 09:20:26 +0000 (Sat, 19 Jul 2014)
Log Message:
-----------
Changed erroneous "it's" to "its"

Modified Paths:
--------------
    trunk/cgreen/doc/cgreen-guide-en.asciidoc

Modified: trunk/cgreen/doc/cgreen-guide-en.asciidoc
===================================================================
--- trunk/cgreen/doc/cgreen-guide-en.asciidoc	2014-05-06 07:20:24 UTC (rev 553)
+++ trunk/cgreen/doc/cgreen-guide-en.asciidoc	2014-07-19 09:20:26 UTC (rev 554)
@@ -27,7 +27,7 @@
 
 - Fully composable test suites
 - 'setup()' and 'teardown()' for tests and test suites
-- Each test runs in it's own process
+- Each test runs in its own process
 - An isolated test can be run in a single process for debugging
 - Ability to mock functions
 - The reporting mechanism can be easily extended
@@ -965,7 +965,7 @@
 }
 --------------------------
 
-We have already factored out the duplicate code into it's own
+We have already factored out the duplicate code into its own
 functions 'create_scheme()' and 'drop_schema()', so things are not so
 bad. At least not yet. What happens when we get dozens of tests? For a
 test subject as complicated as a database
@@ -1030,7 +1030,7 @@
 the test crashes, causing some test interference. This brings us
 nicely onto the next section...
 
-Each test in it's own process
+Each test in its own process
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Consider this test method...
@@ -1048,10 +1048,10 @@
 you need to tackle the problem.
 
 To prevent segmentation faults and other problems bringing down the
-test suites, *Cgreen* runs every test in it's own process.
+test suites, *Cgreen* runs every test in its own process.
 
 Just before calling the 'setup' function, *Cgreen* 'fork()''s. The main
-process wait's for the test to complete normally or die. This includes
+process waits for the test to complete normally or die. This includes
 the calling the 'teardown' function, if any. If the test process dies,
 an exception is reported and the main test process carries on.
 
@@ -1217,7 +1217,7 @@
 an optional argument.  The entire test suite will be searched for the
 named test.  This trick also saves us a recompile when we debug.
 
-We've placed each test suite in it's own file, but that is not
+We've placed each test suite in its own file, but that is not
 necessary.  We could build several test suites in the same file, even
 nesting them.  We can even add mixtures of test functions and test
 suites to the same parent test suite.  Loops will give trouble,
@@ -1301,7 +1301,7 @@
 still attached to the inner 'suite'.
 
 In the real world we would probably place the connection
-fixture in it's own file...
+fixture in its own file...
 
 [source,c]
 -----------------------
@@ -1566,7 +1566,7 @@
 }
 -----------------------
 
-I've been a bit naughty.  As each test runs in it's own process, I
+I've been a bit naughty.  As each test runs in its own process, I
 haven't bothered to free the pointers to the paragraphs.  I've just
 let the operating system do it.  Purists may want to add the extra
 clean up code.
@@ -1577,7 +1577,7 @@
 'read_paragraph()' function could quite legitimately call the stream
 after it had run off of the end.  OK, that would be odd behaviour, but
 that's not what we are testing here.  If we were, it would be placed
-in a test of it's own.  The 'always_expect()' call tells *Cgreen* to
+in a test of its own.  The 'always_expect()' call tells *Cgreen* to
 keep going after the first three letters, allowing extra calls.
 
 As we build more and more tests, they start to look like a
@@ -1783,8 +1783,8 @@
 
 Where are the assertions?
 
-Unlike our earlier stub, 'reader()' can now check it's parameters.  In
-object oriented circles, an object that checks it's parameters as well
+Unlike our earlier stub, 'reader()' can now check its parameters.  In
+object oriented circles, an object that checks its parameters as well
 as simulating behaviour is called a mock object.  By analogy
 'reader()' is a mock function, or mock callback.
 
@@ -2623,7 +2623,7 @@
 and 'reporter_finish()' functions is optional, I want to
 make use of some of the facilities later.
 
-Our output meanwhile, is making it's first tentative steps...
+Our output meanwhile, is making its first tentative steps...
 
 [source,xml]
 -----------------------

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.