5.testing.tex (3710B)
1 \chapter{Testing} 2 3 KYCID uses a TDD \cite{Fowler_TDD} approach which consists of writing the tests before the code and following the cycle below. 4 5 \begin{figure}[H] 6 \centering 7 \includegraphics[width=0.75\textwidth]{tdd-cycle} 8 \caption{TDD Developpment Cycle} 9 \label{fig:TDD-Cycle} 10 \end{figure} 11 12 Cycle steps: 13 \begin{enumerate} 14 \item write the test, run it and then fail it (to check the test's ability to detect) 15 \item have the tests taken as directly as possible 16 \item refactor the code 17 \item repeat the cycle as many times as necessary 18 \end{enumerate} 19 20 \begin{bfhNoteBox} 21 The following narrative scheme \cite{Fowler_GWT} is particularly useful for writing tests: 22 \begin{enumerate} 23 \item \textbf{Given}: a certain situation (arrange) 24 \item \textbf{When}: trigger action (act) 25 \item \textbf{Then}: verify result of action (assert) 26 \end{enumerate} 27 \end{bfhNoteBox} 28 29 \section{Strategy} \label{test-strategy} 30 31 It is important to note that not all tests are equally useful or even cost the same. 32 In our case, we can list four types of test: unit tests, acceptance tests, integration tests and end-to-end tests. 33 These can be hierarchised in a diamond below: 34 35 \begin{figure}[H] 36 \centering 37 \includegraphics[width=0.45\textwidth]{DiamondTesting} 38 \caption{Diamond testing strategy} 39 \label{fig:DiamondTesting} 40 \end{figure} 41 42 The subsequent section will provide detailed information regarding the specific nature of each test. 43 44 \section{Unit tests} 45 46 These tests are designed to assess a single unit of code, hence the name. They are relatively simple and quick to write. 47 48 However, they tend to focus on minor technical details that may not be directly relevant to the final project. Consequently, we only use unit tests when necessary and not as a systematic approach. This is in contrast to pyramid testing \cite{Fowler_TPyramid}, which relies on them as a fundamental basis. 49 50 51 \section{Acceptance tests} \label{acceptance-tests} 52 53 The purpose of acceptance testing is to validate/accept the existence of a given use case. 54 55 They are more interesting because they verify functionality, which is the most valuable thing in software (at least in terms of agility). 56 57 These tests are more difficult to write. However, with a clean architecture (see section \ref{clean-arch}), these tests are greatly simplified because we are testing the core layer (domain and application layer). This layer does not depend on the infrastructure, but on ports that have been specially designed for this case. There is therefore no technical code, only business code, which means that the acceptance test becomes a kind of large unit acceptance test. 58 59 \section{Integration tests} 60 61 The objective of integration tests is not to be exhaustive but to verify the communication (integration) between components. These tests are necessary to ensure the overall functionality of the application, but they are complex to write. Consequently, the strategy in diamand is to write the minimum necessary and no more. 62 63 \section{End-to-end tests} 64 65 In end-to-end testing, the objective is to test from the perspective of the end user. This makes these tests the most challenging to write, as they require the control of a significant amount of code, which introduces a high degree of complexity and technical detail. Unlike integration tests (see section A), they must also simulate the entire application and its infrastructure, which contributes to the high cost. 66 67 However, these tests, which verify the user's point of view, are considered the most valuable according to the principles of agility. Consequently, there will be few end-to-end tests in the diamond strategy. 68