added literature, improved terms

Author: thomasWeise

bookbase

@@ -29,7 +29,7 @@
 In the scripts, we install tools if they are not yet installed.
 We then apply the tools to whatever the parameters of the scripts state.
 Now, in a real environment, a tool can either succeed or fail.
-A unit test executed with \pytest\ will fail and exit with a non-zero exit code if the test, well, fails.
+A \pgls{unitTest} executed with \pytest\ will fail and exit with a non-zero exit code if the test, well, fails.
 A static code analysis tool like \ruff\ will fail with a non-zero exit code if it discovers any issue with the code.
 However, our scripts invoking these tools will \emph{not} fail in such cases.
 They will collect the \pgls{exitCode} of the tool they are invoking and print it.
@@ -66,7 +66,7 @@
 It then applies \pylint\ to a the selected set of files, using a reasonable default configuration.
 \Cref{exec:loops:for_loop_no_enumerate:pylint} is an example of the output of this \pgls{linter}.
 
-\Cref{lst:bash:pytest} is similarly structured, but instead of performing \emph{static} code analysis, it executes unit test cases.
+\Cref{lst:bash:pytest} is similarly structured, but instead of performing \emph{static} code analysis, it executes \pgls{unitTest} cases.
 The directory and list of \python\ files with the test cases are provided as command line arguments.
 This script checks if \pytest\ and its plugin \textil{pytest-timeout} are installed and, if not, installs them.
 It then executes the tests with a fixed ten second timeout that we use in this book.

text/back/scripts.tex

@@ -5,7 +5,7 @@ \chapter*{Preface}%
 It aims to strike a good balance between theory and practice, leaning more to the practice side.
 In particular, we try to teach programming together with some software engineering concepts.
 It is the firm opinion of the author that these two cannot be separated.
-Teaching programming alone without introducing tools such as static code analysis, unit tests, and enforcing principles such as code style and proper commenting will create bad programmers.
+Teaching programming alone without introducing tools such as static code analysis, \pglspl{unitTest}, and enforcing principles such as code style and proper commenting will create bad programmers.
 So we discuss these aspects while working our way through the principles of programming.
 
 This book is intended to be read on an electronic device.

text/front/preface/preface.tex

@@ -44,7 +44,7 @@
 So what is the advantage of sets?
 Sets are fast.
 In \python, sets are implemented based on the concept of hash tables and thus inherit the computational performance of these datastructures~\cite{K1998SAS,CLRS2009ITA,SKS2019DSC}.
-The operation for checking whether one object is contained in a set can be done in \bigOb{1} in average, whereas lists need \bigOb{n} in average, with $n$~being the list length~\cite{H2024PBOTTCODDSIPP33,B2023T,N2022CCSFPO}.
+The operation for checking whether one object is contained in a set can be done in \bigOb{1} in average, whereas lists need \bigOb{n} in average, with $n$~being the list length~\cite{H2025PM:PBOTTCODDSIPP33,B2023T,N2022CCSFPO}.
 This means that checking whether an element is contained in a set costs approximately a constant number of CPU cycles, whereas doing the same for a list takes a number of cycles roughly linear in the length of the list.
 Lists thus can be preferred if we either only have very few elements to check or if we need to access elements using integer indices.
 If we have more than just very few elements and/or need to perform set operations such as those discussed in the following text, sets are the way to go.%

text/main/basics/collections/sets/sets.tex

@@ -10,7 +10,7 @@
 You need a nice editor in which you can write the programs.
 Actually, you want an editor where you can not just write programs.
 You want an editor where you can also directly execute and test your programs.
-In software development, you often work with a \pgls{vcs} like \git.
+In software development, you often work with a \pgls{VCS} like \git.
 You want to do that convenient from your editor.
 Such an editor, which integrates many of the common tasks that occur during programming, is called an \pgls{ide}.
 In this book, we will use the \pycharm\ \pgls{ide}~\cite{VHN2023HOADWP,Y2022PPADT}.

text/main/basics/gettingStarted/gettingStarted.tex

@@ -120,7 +120,7 @@
 We use the \bash\ script given in \cref{lst:bash:mypy} on \cpageref{lst:bash:mypy} to apply \mypy\ to the example programs in this book.%
 }%
 %
-If we instead apply \mypy\ the completely fine (albeit useless) program \cref{lst:variables:types}, it will tell us that there is no error, as illustrated in \cref{exec:variables:variable_types:mypy}.
+If we instead apply \mypy\ to the completely fine (albeit useless) program \cref{lst:variables:types}, it will tell us that there is no error, as illustrated in \cref{exec:variables:variable_types:mypy}.
 So we now have one tool at our hands with which we can check our source code for type-related problems.
 Notice that this program just checks the source code.
 It does not change the code and it does not execute our program.
@@ -136,6 +136,25 @@
 Repeat this until no errors are found anymore.%
 }%
 %
+When reading the text, you may think:
+\mypy\ is an additional software.
+If I want to use it, I need to install it and I will have to learn its command line parameters.
+Everytime I do use it and apply it to some \python\ code, I need to open the \pgls{terminal}, go into the directory where my program code is located, run the \mypy\ program, and read the output.
+This is, like, lots of work.
+Why do I need to bother?
+There are two answers, the first one is \inQuotes{This will improve the quality of your code.}
+We elaborate this answer more later.
+But there also is a second answer:%
+%
+\bestPractice{manyTools}{%
+A professional software engineer or programmer or, actually, any professional computer scientist knows many tools and is always keen to learn new tools.%
+}%
+%
+In your professional life, you will learn dozens if not hundreds of tools on different \pglspl{OS}.
+The more tools you know, the easier it gets to learn and dig into other software if need be.
+Today, automated builds in \pgls{continuousIntegration}, for example, alone may involve more than a dozen programs.
+Being able to learning new tools and becoming proficient with them is thus an essential skill of a programmer.%
+%
 \endhsection%
 %
 \hsection{Type Hints}%

text/main/basics/variables/typesAndTypeHints/typesAndTypeHints.tex

@@ -211,7 +211,7 @@
 Differently from lists, new elements are not added at the end.
 Instead, they would be more like lists of a fixed length where new elements are placed at specific indices where they can be found again.
 These hash tables~\cite{K1998SAS,CLRS2009ITA,SKS2019DSC} are very fast.
-They have an element-wise access/update time complexity of~\bigOb{1}~\cite{H2024PBOTTCODDSIPP33,B2023T,N2022CCSFPO}.
+They have an element-wise access/update time complexity of~\bigOb{1}~\cite{H2025PM:PBOTTCODDSIPP33,B2023T,N2022CCSFPO}.
 As you know, lists can be indexed by integers.
 Since we also want to be able to use objects that are \emph{not} integers as keys, too, we need a way to \inQuotes{translate} these objects to integers.
 That is what \dunder{hash} is supposed to do.
@@ -1590,7 +1590,7 @@
 \label{fig:pythonDunder:3}%
 \end{figure}%
 %
-Besides the examples mentioned above, there are many more duner methods in \python~\cite{H2024EDMIP}.
+Besides the examples mentioned above, there are many more duner methods in \python~\cite{H2025PM:EDMIP}.
 We can only provide an abridged overview in \cref{fig:pythonDunder:1,fig:pythonDunder:2,fig:pythonDunder:3}.
 
 From \cref{fig:pythonDunder:1} we learn that there are three string representation dunder functions.
@@ -1661,7 +1661,7 @@
 Finally, \cref{fig:pythonDunder:3} lists the dunder methods for operators such as~\pythonilIdx{\&}, \pythonil{|}\pythonIdx{\textbar}, \pythonil{\^}\pythonIdx{\textasciicircum}, \pythonil{>>}\pythonIdx{>\strut>}, and \pythonil{<<}\pythonIdx{<\strut<}, which we learned about when we first got in touch with integer numbers in~\cref{sec:int:bitstrings}.
 These dunder methods follow the same schematic as those for arithmetics and also have \inQuotes{\pythonil{r}} and \inQuotes{\pythonil{i}}~variants.
 
-Even more dunder methods are listed in the comprehensive overview~\cite{H2024EDMIP}.
+Even more dunder methods are listed in the comprehensive overview~\cite{H2025PM:EDMIP}.
 %
 %\FloatBarrier%
 \endhsection%

text/main/classes/dunder/dunder.tex

@@ -7,7 +7,7 @@
 When we execute our programs, then there are at least two things that can go wrong.
 On one hand, we can never really be sure that our program code is free of programming mistakes.
 The larger a project gets, the more likely it is that there are some bugs hidden somewhere in the code.
-Thorough unit testing can reduce the likelihood of bugs, but it cannot entirely prevent them.
+Thorough \pglspl{unitTest} can reduce the likelihood of bugs, but it cannot entirely prevent them.
 
 On the other hand, our programs do not exist all by themselves in a vacuum.
 They receive input, maybe from files, maybe from the user, maybe from sensors.
@@ -628,19 +628,19 @@
 \label{sec:testingExceptions}%
 %
 \gitPython{\programmingWithPythonCodeRepo}{exceptions/test_sqrt_raise.py}{--args format}{exceptions:test_sqrt_raise}{%
-A unit test checking that our new variant of the \pythonil{sqrt} function given in \cref{lst:exceptions:sqrt_raise} properly raises an \pythonilIdx{ArithmeticError} if its input is non-finite or negative.}%
+A \pgls{unitTest} checking that our new variant of the \pythonil{sqrt} function given in \cref{lst:exceptions:sqrt_raise} properly raises an \pythonilIdx{ArithmeticError} if its input is non-finite or negative.}%
 %
 \gitOutputTool{\programmingWithPythonCodeRepo}{.}{_scripts_/pytest.sh exceptions test_sqrt_raise.py}{exceptions:test_sqrt_raise:pytest}{%
-The output of the unit tests in \cref{lst:exceptions:test_sqrt_raise}: %
+The output of the \pglspl{unitTest} in \cref{lst:exceptions:test_sqrt_raise}: %
 The \pythonilsIdx{ArithmeticError} are correctly raised.}%
 %
 
-Back in \cref{sec:unitTesting}, we introduced the concept of unit tests and show how the tool \pytest\ can be used to test our functions.
-We stated in \cref{bp:unitTestCoverage} that we should cover all the branches of the control flow inside a function with unit tests.
+Back in \cref{sec:unitTesting}, we introduced the concept of \pglspl{unitTest} and show how the tool \pytest\ can be used to test our functions.
+We stated in \cref{bp:unitTestCoverage} that we should cover all the branches of the control flow inside a function with \pglspl{unitTest}.
 One kind of branch that is often overlooked are \pythonilsIdx{Exception} and extension handling~\cite{LRBP2021AEHTPIOSL}.
 
-If our function is supposed to \pythonilIdx{raise} a certain exception in some cases, then we should have a unit test that checks if this \pythonilsIdx{Exception} is actually raised as it should be.
-Now, any exception raised by a unit test will cause the test to fail.
+If our function is supposed to \pythonilIdx{raise} a certain exception in some cases, then we should have a \pgls{unitTest} that checks if this \pythonilsIdx{Exception} is actually raised as it should be.
+Now, any exception raised by a \pgls{unitTest} will cause the test to fail.
 This seems to contradict our goal to intentionally raise the exceptions.
 Luckily, \pytest\ offers us a device for this.
 
@@ -652,10 +652,10 @@
 If it is raised, the text succeeds.
 
 \gitPython{\programmingWithPythonCodeRepo}{exceptions/test_sqrt.py}{--args format}{exceptions:test_sqrt}{%
-Two unit tests checking the original variant of the \pythonil{sqrt} function from back in \cref{lst:functions:test_my_math_2} that does not raise errors.}%
+Two \pglspl{unitTest} checking the original variant of the \pythonil{sqrt} function from back in \cref{lst:functions:test_my_math_2} that does not raise errors.}%
 %
 \gitOutputTool{\programmingWithPythonCodeRepo}{.}{_scripts_/pytest.sh exceptions test_sqrt.py}{exceptions:test_sqrt:pytest}{%
-The output of the unit tests in \cref{lst:exceptions:test_sqrt}: %
+The output of the \pglspl{unitTest} in \cref{lst:exceptions:test_sqrt}: %
 No error was raised in it, so the first fails and the error message in the second test does not fit, so it fails as well.}%
 %
 In particular, we can provide the exception class as well as a \pgls{regex} via the parameter~\pythonil{match} to \pythonilIdx{raises}.
@@ -676,13 +676,13 @@
 Therefore, our produced error message must follow this pattern for the test to work.
 And, as you can find in the \pytest\ output in \cref{exec:exceptions:test_sqrt_raise:pytest}, for the values \pythonil{v in [-1.0, inf, -inf, nan]}, no error is reported.
 For these values, our \pythonil{sqrt} function does indeed raise\pythonIdx{raise} the expected \pythonilsIdx{Exception}, with the expected error messages.
-The unit test succeeds.%
+The \pgls{unitTest} succeeds.%
 \end{sloppypar}%
 %
 In \cref{lst:exceptions:test_sqrt}, we write a similar test.
 This time, we use basically the original version of our \pythonil{sqrt} function which does not by itself raise any exception.
 This function is directly implemented in the listing, in the same way as we did in \cref{lst:functions:my_math_2}, and again called \pythonil{sqrt}.
-We also write two unit tests into the new file \textil{test_sqrt.py}.
+We also write two \pglspl{unitTest} into the new file \textil{test_sqrt.py}.
 Both are intentionally designed to show what happens if either an expected exception is not raised~(\pythonil{test_sqrt_1}) or if its error message does not match the \pythonil{match} argument~(\pythonil{test_sqrt_2}).%
 %
 \begin{sloppypar}%
@@ -705,7 +705,7 @@
 So indeed, this does fulfill our testing requirement:
 If an \pythonilsIdx{OverflowError} is also a \pythonilIdx{ArithmeticError}, so the right type of exception was raised.
 However, its error message will not fit to our \pythonil{match} argument.
-Therefore, the unit test still fails.
+Therefore, the \pgls{unitTest} still fails.
 The output of \cref{exec:exceptions:test_sqrt:pytest} explains this clearly.%
 \end{sloppypar}%
 %
@@ -727,11 +727,11 @@
 %
 This allows us to cover both the expected and correct use of our function with tests as well as unexpected incorrect uses.
 We can then be confident that our code is unlikely to cause harm, neither due to bugs created by ourselves nor due to accidental misuse by other programmers due to misunderstandings (which would immediately signaled to them by \pythonilsIdx{Exception}).
-Notice that good unit testing goes hand in hand with good documentation in \pglspl{docstring}, because good \pglspl{docstring} reduce the chance of such misunderstandings.%
+Notice that good \pglspl{unitTest} go hand in hand with good documentation in \pglspl{docstring}, because good \pglspl{docstring} reduce the chance of such misunderstandings.%
 %
 \bestPractice{testAll}{%
 It is important to cover both the reasonable expected use of our functions as well as unexpected use with incorrect arguments with test cases. %
-The latter case should raise\pythonIdx{raise} \pythonilsIdx{Exception}, which we should verify with unit tests.%
+The latter case should raise\pythonIdx{raise} \pythonilsIdx{Exception}, which we should verify with \pglspl{unitTest}.%
 }%
 %
 \FloatBarrier%
@@ -865,7 +865,7 @@
 
 Error handling in \python\ therefore allows us to develop software that is both robust and that clearly indicates if something goes wrong.
 Of course, for software to be called \emph{robust}, it has to be tested.
-Luckily, \pytest\ offers us also unit testing capabilities that check whether \pythonilsIdx{Exceptions} are raised where expected.
+Luckily, \pytest\ offers us also \pgls{unitTest} capabilities that check whether \pythonilsIdx{Exceptions} are raised where expected.
 This completes our discussion of the error-related control flow.%
 \endhsection%
 %