tex: update unit testing stuff

tex/text.tex

@@ -1119,10 +1119,10 @@ seems to discount any benefit there is to unit testing, while a `` TDD-only''
 written first, then a complementary piece of code that is supposed to be
 tested, just enough to get past the compile errors and to see the test fail,
 then the code is refactored to make the test pass and then it can be fearlessly
-extended because the test is the safety net catching us when we slip and alter
+extended because the test is the safety net catching us when the user slips and
-the originally intended behaviour) approach can be a little too much for some
+alters the originally intended behaviour) approach can be a little too much for
-people's taste. The author tends to sport a \emph{middle ground} approach here,
+some people's taste. The author tends to sport a \emph{middle ground} approach
-with writing enough tests where meaningful but not necessarily testing
+here, with writing enough tests where meaningful but not necessarily testing
 everything or writing tests prior to code, although arguably that practice
 should result in writing a \emph{better} designed code, particularly because
 there has to be a prior though about it because it needs to be tested
@@ -1131,22 +1131,25 @@ there has to be a prior though about it because it needs to be tested
 Thanks to Go's built in support for testing in its \texttt{testing} package and
 the tooling in the \texttt{go} tool, writing tests is relatively simple. Go
 looks for files in the form \texttt{<filename>\_test.go} in the present working
-directory but can be instructed to look for the files in packages recursively
+directory but can be instructed to look for test files in packages recursively
-found on a path using the ellipsis, like so: \texttt{go test
+found on any path using the ellipsis, like so: \texttt{go test
 ./path/to/package/\ldots}, which then \emph{runs} all the tests found and
 reports some statistics, such as the time it took to run the test or whether it
-succeeded or failed. To be precise, the test files need to contain test
+succeeded or failed. To be precise, the test files also need to contain test
 functions, which are functions with the signature \texttt{func TestWhatever(t
-*testing.T)\{\}}, where the function prefix ``Test'' is equally as important as
+*testing.T)\{\}} and where the function prefix ``Test'' is equally as important
-the signature. Without it, the function is not detected to be a testing
+as the signature. Without it, the function is not considered to be a testing
-function even despite the signature and is therefore \emph{not} executed.This
+function despite having the required signature and is therefore \emph{not}
-behaviour, however, also has a neat side-effect: all the test files can be kept
+executed during testing.
-side-by-side their regular source counterparts, there is no need to segregate
+
-them into a specially blessed \texttt{tests} folder or similar, which in
+This test lookup behaviour, however, also has a neat side-effect: all the test
-author's opinion improves readability. As a failsafe, in case no actual test
+files can be kept side-by-side their regular source counterparts, there is no
-are found, the current behaviour of the tool is to print a note informing the
+need to segregate them into a specially blessed \texttt{tests} folder or
-developer that no tests were found, which is handy to learn if it was not
+similar, which in author's opinion improves readability. As a failsafe, in case
-intended/expected. 
+no actual test are found, the current behaviour of the tool is to print a note
+informing the developer that no tests were found, which is handy to learn if it
+was not intended/expected. When compiling regular source code, the Go files
+with \texttt{\_test} in the name are simply ignored by the build tool.
 
 \n{2}{Integration tests}