From 3060b09a83faefcf06e53fff6de9ee07d8331eff Mon Sep 17 00:00:00 2001 From: leo Date: Tue, 23 May 2023 18:40:39 +0200 Subject: [PATCH] tex: add stuff on testing --- tex/abbreviations.tex | 2 ++ tex/text.tex | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+) diff --git a/tex/abbreviations.tex b/tex/abbreviations.tex index f5dcfa5..d1e0468 100644 --- a/tex/abbreviations.tex +++ b/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 \\ diff --git a/tex/text.tex b/tex/text.tex index c316a4b..5547b0e 100644 --- a/tex/text.tex +++ b/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{\_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} % =========================================================================== %