Re: [PATCH linux-kselftest/test v2] Documentation: kunit: fix typos and gramatical errors

[Randy Dunlap <rdunlap@infradead.org>]

On 11/19/19 3:38 PM, Brendan Higgins wrote:
> Fix typos and gramatical errors in the Getting Started and Usage guide
> for KUnit.
> 
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Link: https://patchwork.kernel.org/patch/11156481/
> Reported-by: Rinat Ibragimov <ibragimovrinat@mail.ru>
> Link: https://github.com/google/kunit-docs/issues/1
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> Reviewed-by: David Gow <davidgow@google.com>

Acked-by: Randy Dunlap <rdunlap@infradead.org>

Thanks.

> ---
>  Documentation/dev-tools/kunit/start.rst |  8 ++++----
>  Documentation/dev-tools/kunit/usage.rst | 24 ++++++++++++------------
>  2 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
> index f4d9a4fa914f8..9d6db892c41c0 100644
> --- a/Documentation/dev-tools/kunit/start.rst
> +++ b/Documentation/dev-tools/kunit/start.rst
> @@ -26,7 +26,7 @@ For more information on this wrapper (also called kunit_tool) checkout the
>  
>  Creating a kunitconfig
>  ======================
> -The Python script is a thin wrapper around Kbuild as such, it needs to be
> +The Python script is a thin wrapper around Kbuild. As such, it needs to be
>  configured with a ``kunitconfig`` file. This file essentially contains the
>  regular Kernel config, with the specific test targets as well.
>  
> @@ -62,8 +62,8 @@ If everything worked correctly, you should see the following:
>  followed by a list of tests that are run. All of them should be passing.
>  
>  .. note::
> -   Because it is building a lot of sources for the first time, the ``Building
> -   kunit kernel`` step may take a while.
> +	Because it is building a lot of sources for the first time, the
> +	``Building KUnit kernel`` step may take a while.
>  
>  Writing your first test
>  =======================
> @@ -162,7 +162,7 @@ Now you can run the test:
>  
>  .. code-block:: bash
>  
> -	./tools/testing/kunit/kunit.py
> +	./tools/testing/kunit/kunit.py run
>  
>  You should see the following failure:
>  
> diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
> index c6e69634e274b..b9a065ab681ee 100644
> --- a/Documentation/dev-tools/kunit/usage.rst
> +++ b/Documentation/dev-tools/kunit/usage.rst
> @@ -16,7 +16,7 @@ Organization of this document
>  =============================
>  
>  This document is organized into two main sections: Testing and Isolating
> -Behavior. The first covers what a unit test is and how to use KUnit to write
> +Behavior. The first covers what unit tests are and how to use KUnit to write
>  them. The second covers how to use KUnit to isolate code and make it possible
>  to unit test code that was otherwise un-unit-testable.
>  
> @@ -174,13 +174,13 @@ Test Suites
>  ~~~~~~~~~~~
>  
>  Now obviously one unit test isn't very helpful; the power comes from having
> -many test cases covering all of your behaviors. Consequently it is common to
> -have many *similar* tests; in order to reduce duplication in these closely
> -related tests most unit testing frameworks provide the concept of a *test
> -suite*, in KUnit we call it a *test suite*; all it is is just a collection of
> -test cases for a unit of code with a set up function that gets invoked before
> -every test cases and then a tear down function that gets invoked after every
> -test case completes.
> +many test cases covering all of a unit's behaviors. Consequently it is common
> +to have many *similar* tests; in order to reduce duplication in these closely
> +related tests most unit testing frameworks - including KUnit - provide the
> +concept of a *test suite*. A *test suite* is just a collection of test cases
> +for a unit of code with a set up function that gets invoked before every test
> +case and then a tear down function that gets invoked after every test case
> +completes.
>  
>  Example:
>  
> @@ -211,7 +211,7 @@ KUnit test framework.
>  .. note::
>     A test case will only be run if it is associated with a test suite.
>  
> -For a more information on these types of things see the :doc:`api/test`.
> +For more information on these types of things see the :doc:`api/test`.
>  
>  Isolating Behavior
>  ==================
> @@ -338,7 +338,7 @@ We can easily test this code by *faking out* the underlying EEPROM:
>  		return count;
>  	}
>  
> -	ssize_t fake_eeprom_write(struct eeprom *this, size_t offset, const char *buffer, size_t count)
> +	ssize_t fake_eeprom_write(struct eeprom *parent, size_t offset, const char *buffer, size_t count)
>  	{
>  		struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent);
>  
> @@ -454,7 +454,7 @@ KUnit on non-UML architectures
>  By default KUnit uses UML as a way to provide dependencies for code under test.
>  Under most circumstances KUnit's usage of UML should be treated as an
>  implementation detail of how KUnit works under the hood. Nevertheless, there
> -are instances where being able to run architecture specific code, or test
> +are instances where being able to run architecture specific code or test
>  against real hardware is desirable. For these reasons KUnit supports running on
>  other architectures.
>  
> @@ -557,7 +557,7 @@ run your tests on your hardware setup just by compiling for your architecture.
>  .. important::
>     Always prefer tests that run on UML to tests that only run under a particular
>     architecture, and always prefer tests that run under QEMU or another easy
> -   (and monitarily free) to obtain software environment to a specific piece of
> +   (and monetarily free) to obtain software environment to a specific piece of
>     hardware.
>  
>  Nevertheless, there are still valid reasons to write an architecture or hardware
> 


-- 
~Randy