Documentation Source Text

Ticket Change Details
Login
Overview

Artifact ID: 0083ac1d55558edefc6f1d445b3d4ecd13abdefa
Ticket: 6afbaac77a52917fc15bfca80826fb78904f92a4
testing.html grammar/spelling errors
User & Date: anonymous 2010-05-07 18:40:12
Changes

  1. Appended to comment:

    anonymous claiming to be eas added on 2010-05-07 18:40:12:
    Checking your source tree, I found a 'testing.in' which I assume gets filtered through some script or another on its way to becoming a real web page. I made a similar patch to that file, assuming patch(1) will work better on with it:

    --- testing.in  2010-05-07 14:32:05.944821183 -0400
    +++ testing.eas.in  2010-05-07 14:36:22.026567435 -0400
    @@ -212,7 +212,7 @@
     of SQLite when something goes wrong.  It is (relatively) easy to build
     an SQL database engine that behaves correctly on well-formed inputs
     on a fully functional computer.  It is more difficult to build a system
    -that responses sanely to invalid inputs and continues to function following
    +that responds sanely to invalid inputs and continues to function following
     system malfunctions.  The anomaly tests are designed to verify the latter
     behavior.</p>
    
    @@ -220,7 +220,7 @@
     <h3>3.1 Out-Of-Memory Testing</h3>
    
     <p>SQLite, like all SQL database engines, makes extensive use of
    -malloc()  (See the separate report on
    +malloc(). (See the separate report on
     [memory allocation | dynamic memory allocation in SQLite] for
     additional detail.)
     On servers and workstations, malloc() never fails in practice and so correct
    @@ -328,7 +328,7 @@
     <h3>3.4 Compound failure tests</h3>
    
     <p>The test suites for SQLite also explore the result of stacking
    -multiple failures.  For example, tests are run to insure correct behavior
    +multiple failures.  For example, tests are run to ensure correct behavior
     when an I/O error or OOM fault occurs while trying to recover from a
     prior crash.
    
    @@ -336,7 +336,7 @@
     <h2>4.0 Fuzz Testing</h2>
    
     <p>[http://en.wikipedia.org/wiki/Fuzz_testing | Fuzz testing]
    -seeks to establish that SQLite response correctly to invalid, out-of-range,
    +seeks to establish that SQLite responds correctly to invalid, out-of-range,
     or malformed inputs.</p>
    
     <h3>4.1 SQL Fuzz</h3>
    @@ -392,7 +392,7 @@
     fixed until new test cases have been added to the TCL test suite which
     would exhibit the bug in an unpatched version of SQLite.  Over the years,
     this has resulted in thousands and thousands of new tests being added
    -to the TCL test suite.  These regression tests insure that bugs that have
    +to the TCL test suite.  These regression tests ensure that bugs that have
     been fixed in the past are not reintroduced into future versions of
     SQLite.</p>
    
    @@ -403,10 +403,10 @@
     are allocated and never freed.  The most troublesome resource leaks
     in many applications are memory leaks - when memory is allocated using
     malloc() but never released using free().  But other kinds of resources
    -can also be linked:  file descriptors, threads, mutexes, etc.</p>
    +can also be leaked:  file descriptors, threads, mutexes, etc.</p>
    
     <p>Both the TCL and TH3 test harnesses automatically track system
    -resources and report resources leaks on <u>every</u> test run.
    +resources and report resource leaks on <u>every</u> test run.
     No special configuration or setup is required.   The test harnesses
     are especially vigilant with regard to memory leaks.  If a change
     causes a memory leak, the test harnesses will recognize this
    @@ -437,7 +437,7 @@
     of lines of code are executed at least once by the test suite.</p>
    
     <p>Branch coverage is more rigorous than statement coverage.  Branch
    -coverage measure the number of machine-code branch instructions that
    +coverage measures the number of machine-code branch instructions that
     are evaluated at least once on both directions.</p>
    
     <p>To illustrate the difference between statement coverage and
    @@ -528,17 +528,17 @@
     <p>Another macro used in conjunction with test coverage measurement is
     the <tt>testcase()</tt> macro.  The argument is a condition for which
     we want test cases that evaluate to both true and false.
    -In non-coverage builds (that is to so, in release builds) the testcase()
    -macro is a no-op:</p>
    +In non-coverage builds (that is to say, in release builds) the 
    +<tt>testcase()</tt> macro is a no-op:</p>
    
     <blockquote><pre>
     #define testcase(X)
     </pre></blockquote>
    
    -<p>But in a coverage measuring build, the testcase() macro generates code
    -that evaluates the conditional expression in its argument.  
    +<p>But in a coverage measuring build, the <tt>testcase()</tt> macro generates 
    +code that evaluates the conditional expression in its argument.  
     Then during analysis, a check
    -is made to insure tests exists that evaluate the conditional to both true
    +is made to ensure tests exist that evaluate the conditional to both true
     and false.  Testcase() macros are used, for example, to help verify that
     boundary values are tested.  For example:</p>
    
    @@ -565,11 +565,12 @@
     }
     </pre></blockquote>
    
    -<p>For bitmask tests, testcase() macros are used to verify that every
    +<p>For bitmask tests, <tt>testcase()</tt> macros are used to verify that every
     bit of the bitmask effects the test.  For example, in the following block
     of code, the condition is true if the mask contains either of two bits
    -indicating either a MAIN_DB or a TEMP_DB is being opened.  The testcase()
    -macros that precede the if statement verify that both cases are tested:</p>
    +indicating either a MAIN_DB or a TEMP_DB is being opened.  The 
    +<tt>testcase()</tt> macros that precede the if statement verify that both 
    +cases are tested:</p>
    
     <blockquote><pre>
     testcase( mask & SQLITE_OPEN_MAIN_DB );
    @@ -578,7 +579,7 @@
     </pre></blockquote>
    
     <p>The SQLite source code contains <tcl>N {$stat(nTestcase)}</tcl>
    -uses of the testcase() macro.</p>
    +uses of the <tt>testcase()</tt> macro.</p>
    
     <tcl>hd_fragment {mcdc} *MC/DC {MC/DC testing}</tcl>
     <h3>7.4 Branch coverage versus MC/DC</h3>
    @@ -658,7 +659,7 @@
     an x86 running a linux binary.  (Ports of valgrind for platforms other
     than linux are in development, but as of this writing, valgrind only
     works reliably on linux, which in the opinion of the SQLite developers
    -means that linux should be preferred platform for all software development.)
    +means that linux should be the preferred platform for all software development.)
     As valgrind runs a linux binary, it looks for all kinds of interesting
     errors such as array overruns, reading from uninitialized memory,
     stack overflows, memory leaks, and so forth.  Valgrind finds problems
    @@ -703,7 +704,7 @@
     <tcl>hd_fragment journaltest</tcl>
     <h3>8.5 Journal Tests</h3>
    
    -<p>One of the things that SQLite does to insure that transactions
    +<p>One of the things that SQLite does to ensure that transactions
     are atomic across system crashes and power failures is to write
     all changes into the rollback journal file prior to changing the
     database.  The TCL test harness contains an alternative
    @@ -748,7 +749,7 @@
     <tcl>hd_fragment summary</tcl>
     <h2>10.0 Summary</h2>
    
    -<p>SQLite is open source.  This gives many people with the idea that
    +<p>SQLite is open source.  This gives many people the idea that
     it is not well tested as commercial software and is perhaps unreliable.
     But that impression is false.
     SQLite has exhibited very high reliability in the field and