Merge branch '9.0' into 9.1

Author: sebastianbergmann

src/extending-phpunit.rst

@@ -28,7 +28,7 @@ Write custom assertions
 When writing custom assertions it is the best practice to follow how
 PHPUnit's own assertions are implemented. As you can see in
 :numref:`extending-phpunit.examples.Assert.php`, the
-``assertTrue()`` method is just a wrapper around the
+``assertTrue()`` method is a wrapper around the
 ``isTrue()`` and ``assertThat()`` methods:
 ``isTrue()`` creates a matcher object that is passed on to
 ``assertThat()`` for evaluation.

src/fixtures.rst

@@ -12,8 +12,8 @@ original state when the test is complete. This known state is called
 the *fixture* of the test.
 
 In :ref:`writing-tests-for-phpunit.examples.StackTest.php`, the
-fixture was simply the array that is stored in the ``$stack``
-variable. Most of the time, though, the fixture will be more complex
+fixture was the array that is stored in the ``$stack`` variable.
+Most of the time, though, the fixture will be more complex
 than a simple array, and the amount of code needed to set it up will
 grow accordingly. The actual content of the test gets lost in the noise
 of setting up the fixture. This problem gets even worse when you write

src/incomplete-and-skipped-tests.rst

@@ -112,8 +112,8 @@ Skipping Tests
 
 Not all tests can be run in every environment. Consider, for instance,
 a database abstraction layer that has several drivers for the different
-database systems it supports. The tests for the MySQL driver can of
-course only be run if a MySQL server is available.
+database systems it supports. The tests for the MySQL driver can
+only be run if a MySQL server is available.
 
 :numref:`incomplete-and-skipped-tests.skipping-tests.examples.DatabaseTest.php`
 shows a test case class, ``DatabaseTest``, that contains one test

src/installation.rst

@@ -154,7 +154,7 @@ Environment, was created. You can learn about PHIVE on its `website <https://pha
 Composer
 ########
 
-Simply add a (development-time) dependency on
+Add a (development-time) dependency on
 ``phpunit/phpunit`` to your project's
 ``composer.json`` file if you use `Composer <https://getcomposer.org/>`_ to manage the
 dependencies of your project:

src/logging.rst

@@ -142,9 +142,9 @@ Code Coverage (TEXT)
 
 Human readable code coverage output for the command-line or a text file.
 
-The aim of this output format is to provide a quick coverage overview while
+The aim of this output format is to provide a coverage overview while
 working on a small set of classes. For bigger projects this output can be
-useful to get an quick overview of the projects coverage or when used with
+useful to get an overview of the projects coverage or when used with
 the ``--filter`` functionality.
 When used from the command-line by writing to ``php://stdout``
 this will honor the ``--colors`` setting.

src/organizing-tests.rst

@@ -39,7 +39,7 @@ package and class structure of the System Under Test (SUT) in the
     `-- Money.php                       `-- MoneyTest.php
     `-- autoload.php
 
-To run all tests for the library we just need to point the PHPUnit
+To run all tests for the library we need to point the PHPUnit
 command-line test runner to the test directory:
 
 .. parsed-literal::

src/test-doubles.rst

@@ -41,7 +41,7 @@ then you can use the ``getMockBuilder($type)`` method to
 customize the test double generation using a fluent interface.
 
 By default, all methods of the original class are replaced with a dummy
-implementation that just returns ``null`` (without calling
+implementation that returns ``null`` (without calling
 the original method). Using the ``will($this->returnValue())``
 method, for instance, you can configure these dummy implementations to
 return a value when called.
@@ -374,7 +374,7 @@ shows how to use ``throwException()`` to do this.
 
 Alternatively, you can write the stub yourself and improve your design
 along the way. Widely used resources are accessed through a single façade,
-so you can easily replace the resource with the stub. For example,
+so you can replace the resource with the stub. For example,
 instead of having direct database calls scattered throughout the code,
 you have a single ``Database`` object, an implementor of
 the ``IDatabase`` interface. Then, you can create a stub
@@ -841,9 +841,9 @@ Stubbing and Mocking Web Services
 #################################
 
 When your application interacts with a web service you want to test it
-without actually interacting with the web service. To make the stubbing
-and mocking of web services easy, the ``getMockFromWsdl()``
-can be used just like ``getMock()`` (see above). The only
+without actually interacting with the web service. To create stubs
+and mocks of web services, the ``getMockFromWsdl()``
+can be used like ``getMock()`` (see above). The only
 difference is that ``getMockFromWsdl()`` returns a stub or
 mock based on a web service description in WSDL and ``getMock()``
 returns a stub or mock based on a PHP class or interface.

src/writing-tests-for-phpunit.rst

@@ -147,7 +147,7 @@ depends upon ``testPush()``.
    (normal shallow) clone (based on PHP keyword ``clone``) via
    ``@depends shallowClone`` are possible too.
 
-To quickly localize defects, we want our attention to be focussed on
+To localize defects, we want our attention to be focussed on
 relevant failing tests. This is why PHPUnit skips the execution of a test
 when a depended-upon test has failed. This improves defect localization by
 exploiting the dependencies between tests as shown in