tex: add stuff on testing

tex/abbreviations.tex

@@ -25,6 +25,8 @@ CLI & Command Line Interface \\
 SCM & Source Code Management \\
 HIBP & Have I Been Pwned \\
 
+TDD & Test Driven Development \\
+
 TOML & Tom's Obvious Minimal Language \\
 YAML & Yet Another Markup Language \\
 JSON & Java Script Object Notation \\

tex/text.tex

@@ -1012,8 +1012,51 @@ the former and CoreDNS for the latter.
 
 \n{2}{Unit tests}
 
+Unit testing is a hot topic for many people and the author does not count
+himself to be a staunch supporter of neither extreme. The ``no unit tests''
+seems to discount any benefit there is to unit testing, while a `` TDD-only''
+(TDD, or Test Driven Development is a development methodology whereby tests are
+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
+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
+\emph{first}.
+
+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
+./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
+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. 
+
 \n{2}{Integration tests}
 
+Integrating with external software, namely the database in case of this program
+is designed to utilise the same mechanism that was mentioned in the previous
+section: Go's \texttt{testing} package. These test verify that the code changes
+can still perform the same actions with the external software that were
+possible before the change and are equally run before every commit locally and
+then in the CI.
+
 \n{2}{Click-ops}
 
 % =========================================================================== %