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
-the originally intended behaviour) approach can be a little too much for some
-people's taste. The author tends to sport a \emph{middle ground} approach here,
-with writing enough tests where meaningful but not necessarily testing
+extended because the test is the safety net catching us when the user slips and
+alters the originally intended behaviour) approach can be a little too much for
+some people's taste. The author tends to sport a \emph{middle ground} approach
+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
-found on a path using the ellipsis, like so: \texttt{go test
+directory but can be instructed to look for test files in packages recursively
+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
-the signature. Without it, the function is not detected to be a testing
-function even despite the signature and is therefore \emph{not} executed.This
-behaviour, however, also has a neat side-effect: all the test files can be kept
-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
-author's opinion improves readability. As a failsafe, in case 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. 
+*testing.T)\{\}} and where the function prefix ``Test'' is equally as important
+as the signature. Without it, the function is not considered to be a testing
+function despite having the required signature and is therefore \emph{not}
+executed during testing.
+
+This test lookup behaviour, however, also has a neat side-effect: all the test
+files can be kept 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 author's opinion improves readability. As a failsafe, in case
+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}