conference_poster_5.tex

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% a0poster Landscape Poster
% LaTeX Template
% Version 1.0 (22/06/13)
%
% The a0poster class was created by:
% Gerlinde Kettl and Matthias Weiser (tex@kettl.de)
% 
% This template has been downloaded from:
% http://www.LaTeXTemplates.com
%
% License: 
% CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
%----------------------------------------------------------------------------------------
%	PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
%----------------------------------------------------------------------------------------

\documentclass[a0,landscape]{a0poster}
\usepackage[utf8]{inputenc}
\usepackage{hyperref}
\usepackage{multicol} % This is so we can have multiple columns of text side-by-side
\columnsep=100pt % This is the amount of white space between the columns in the poster
\columnseprule=3pt % This is the thickness of the black line between the columns in the poster

\usepackage[svgnames]{xcolor} % Specify colors by their 'svgnames', for a full list of all colors available see here: http://www.latextemplates.com/svgnames-colors

\usepackage{times} % Use the times font
%\usepackage{palatino} % Uncomment to use the Palatino font

\usepackage{graphicx} % Required for including images
\graphicspath{{figures/}} % Location of the graphics files
\usepackage{booktabs} % Top and bottom rules for table
\usepackage[font=small,labelfont=bf]{caption} % Required for specifying captions to tables and figures
\usepackage{amsfonts, amsmath, amsthm, amssymb} % For math fonts, symbols and environments
\usepackage{wrapfig} % Allows wrapping text around tables and figures
\usepackage[ngerman]{babel}
\usepackage{setspace}
\usepackage{titlesec}

% listings
\usepackage{listings}
\lstset{
    language=Python,
    basicstyle=\ttfamily\scriptsize
}

% create \gqq command for german quotes
\newcommand{\gqq}[1]{\glqq #1\grqq}


% # Ablauf (Johannes)
%     -Stickpunkte

% # Vorteile (Fabi)
%     -Stickpunkte

% # Nachteile (Fabi)
%     -Stickpunkte

% # Bezug zum Agilen Manifest

% # Best Practices (Stefan)

% # Tools (Tobi)

% # Fazit (Zusammen)



\hypersetup{
    colorlinks=true,
    urlcolor=blue,
}

\titlespacing\section{0pt}{12pt plus 4pt minus 2pt}{5pt plus 2pt minus 2pt}
\titlespacing\subsection{0pt}{12pt plus 4pt minus 2pt}{5pt plus 2pt minus 2pt}
\titlespacing\subsubsection{0pt}{12pt plus 4pt minus 2pt}{5pt plus 2pt minus 2pt}

\setlength{\parindent}{0pt}

\begin{document}

%----------------------------------------------------------------------------------------
%	POSTER HEADER 
%----------------------------------------------------------------------------------------

% The header is divided into three boxes:
% The first is 55% wide and houses the title, subtitle, names and university/organization
% The second is 25% wide and houses contact information
% The third is 19% wide and houses a logo for your university/organization or a photo of you
% The widths of these boxes can be easily edited to accommodate your content as you see fit

\begin{minipage}[b]{0.55\linewidth}
\huge \color{NavyBlue} \textbf{Test-Driven-Development} \color{Black}\\ % Title
\huge\textit{AVM Workshop Poster}\\[1cm] % Subtitle
%\Large\textit{}\\[1cm]
\huge \textbf{Ambs, Brandenburger, Jerke, Klimpel, Tögel}\\ % Author(s)
\huge HTWG Konstanz, Fakultät Informatik\\ % University/organization
\end{minipage}
%
\begin{minipage}[b]{0.25\linewidth}
\color{DarkSlateGray}\Large \textbf{Contact Information:}\\
Fakultät Informatik\\ % Address
HTWG Konstanz\\
Alfred-Wachtel-Str. 8 78462 Konstanz\\\\
% Phone: +1 (000) 111 1111\\ % Phone number
GitHub: \href{https://github.com/msi-se/avm-workshop-tdd}{msi-se/avm-workshop-tdd}\\
\end{minipage}
%
\begin{minipage}[b]{0.19\linewidth}
\includegraphics[width=20cm]{logo200.jpg} % Logo or a photo of you, adjust its dimensions here
\end{minipage}

\vspace{1cm} % A bit of extra whitespace between the header and poster content

%----------------------------------------------------------------------------------------

\begin{multicols}{4} % This is how many columns your poster will be broken into, a poster with many figures may benefit from less columns whereas a text-heavy poster benefits from more

%----------------------------------------------------------------------------------------
%	ABSTRACT
%----------------------------------------------------------------------------------------

\color{Navy} % Navy color for the abstract

\begin{abstract}

Test-Driven Development (TDD) ist eine Softwareentwicklungsmethodik, bei der die Entwicklung um das Schreiben von Tests herum strukturiert ist. Ziele von TDD sind durch hohe Codequalität eine robuste und besser wartbare Software zu entwickeln. Der TDD Prozess besteht aus den Schritten "red, green, refactor". Im Schritt "red" wird ein Tests geschrieben, der alle Anforderungen an Funktionalitäten abdeckt. Im Schritt "green" werden die Funktionalitäten implementiert bis die Tests bestehen. Im Schritt "refactor" wird der Code optimiert. Nachteile von TDD sind ein hoher initialer Zeitaufwand, ein erforderliches Umdenken der Entwickler, es ist nicht für alle Projekte geeignet und die Gefahr für Overengineering. TDD kann agil betrieben werden und ist mit den agilen Prinzipien vereinbar, wenn es effektiv praktiziert wird. Best Practices für TDD sind Tests klein und unabhängig zu halten, so wenig Code wie nötig für das bestehen der Tests, schreiben von positiven und negativen Testsfällen und das wiederholende ausführen der Tests.

\end{abstract}

%----------------------------------------------------------------------------------------
%	INTRODUCTION
%----------------------------------------------------------------------------------------

% \color{SaddleBrown} % SaddleBrown color for the introduction

% TOCHECK: brauchen wir eigentlich nicht?

% \section*{Kontext}

% \dots

% \section*{Introduction}


\color{DarkSlateGray} % DarkSlateGray color for the rest of the content

\section*{Grundlagen und Ziele}

Test-Driven Development (TDD) ist eine Softwareentwicklungsmethodik, die sich durch das Ziel auszeichnet, die Qualität und Zuverlässigkeit von Code zu verbessern. Der Kerngedanke hinter TDD ist es, den Entwicklungsprozess um das Schreiben von Tests herum zu strukturieren. Diese Tests definieren die Anforderungen und das gewünschte Verhalten der Software, noch bevor die eigentliche Implementierung beginnt. TDD fördert damit ein tieferes Verständnis für die Anforderungen und hilft, Fehler frühzeitig zu erkennen und zu beheben. Durch diesen Ansatz wird eine kontinuierliche Überprüfung und Verbesserung des Codes ermöglicht, was zu robusteren und besser wartbaren Softwareprodukten führt. \cite{ieee_tdd_2007}

\section*{Ablauf} % von TDD

Bei Test-Driven-Development (TDD) wird die Entwicklung von Software durch einen Zyklus aus Testen und Implementieren gesteuert.
Dabei werden die Tests optimalerweise vor der Implementierung geschrieben, in Einzelfällen auch parallel dazu.
Der genaue Ablauf eines Zyklus unterscheidet sich zwischen verschiedenen Quellen leicht, im Kern ist er aber immer gleich.
In diesem Poster werden die typischen drei Schritten (\gqq{red, green, refactor} z. B. nach dem Vorgehen von \gqq{Agile-Ikone} Kent Beck (vgl. \cite{beck_test_2022} S. x)) um einen weiteren verbreiteten Schritt erweitert, um möglichst viel abzudecken. 

\begin{itemize}
\item \textbf{0. Schritt: \gqq{Think}}\\
Zunächst sollten die Anforderungen an die gerade zu implementierende Funktionalität klar sein.
Wenn dies nicht der Fall ist, muss es erneute Absprachen geben.
Der/die Entwickler:in sollte sich hier aus Sichtweise des Nutzers der Softwarekomponente in die Funktionalität hineinversetzen.
In diesem Schritt muss auch entschieden werden, welche Anforderungen genau in diesem Zyklus umgesetzt werden sollen und welche erst in einer zukünftigen Iteration in Betracht gezogen werden.
\item \textbf{1. Schritt: \gqq{Red}}\\
Im ersten richtigen Schritt wird ein Test geschrieben, der alle Anforderungen an die Funktionalität abdeckt.
Hierzu können verschiedene Testarten verwendet werden, z. B. Unit-Tests, Integrationstests, etc.
Wichtig: Der Test muss fehlschlagen, da die Funktionalität noch nicht implementiert ist (\gqq{red}).
So wird sichergegangen, dass auch wirklich neue Funktionalität getestet und implementiert wird.
Oft lassen sich die Tests noch nicht einmal kompilieren, da beispielsweise die zu testende Methode noch gar nicht existiert.
\item \textbf{2. Schritt: \gqq{Green}}\\
Bei der anschließenden Implementierung wird nun darauf geachtet, dass der Test so schnell wie möglich erfolgreich durchläuft (\gqq{green}).
Es kommt hier nur auf die Funktionalität an, die Implementierung muss nicht \gqq{schön/sauber} sein (\gqq{quick and dirty}), sprich \gqq{so wenig Code wie möglich}.
\item \textbf{3. Schritt: \gqq{Refactor}}\\
Sind alle Tests erfolgreich, wird \gqq{aufgeräumt}.
Der Code wird optimiert, Duplikate werden entfernt und die Lesbarkeit wird verbessert.
Dabei werden die Tests immer wieder ausgeführt, um sicherzustellen, dass die Funktionalität bestehen bleibt.
\end{itemize}

(vgl. \cite{beck_test_2022} S. x, \cite{schatten_qualitatssicherung_2010} S. 153, \cite{ionos_test_2020})


\section*{Vorteile}
\begin{itemize}
    \item \textbf{Hochwertige Software}\\
    TDD ermöglicht eine effektive und effiziente Erstellung der Software, indem unnötiger Code vermieden wird. Es wird immer nur der Code geschrieben, der für die Erfüllung der Anforderungen benötigt wird.
    \item \textbf{Geringerer Wartungsaufwand}\\
    Durch die Vermeidung von Fehlern durch Tests wird der Wartungsaufwand reduziert. Dadurch können Entwickler:innen mehr Zeit in die Entwicklung neuer Features investieren.
    \item \textbf{Frühe Fehlererkennung}\\
    TDD ermöglicht eine frühzeitige Erkennung von Fehlern, wodurch die Kosten für spätere Korrekturen minimiert werden. Ebenfalls wird dadurch nicht getesteter Code vermieden und dadurch die korrekte Funktionalität der gesamten Software von Beginn an sichergestellt.
\end{itemize}

\section*{Nachteile}
\begin{itemize}
    \item \textbf{Hoher initialer Zeitaufwand}\\
    TDD kann zeitaufwändig sein, da Tests in kleinen Schritten entwickelt werden müssen. Ebenfalls wird der initiale Zeitaufwand durch das Schreiben von Tests bevor die eigentliche Implementierung erfolgt ist, erhöht.
    \item \textbf{Erfordert Umdenken}\\
    TDD erfordert ein Umdenken in der Art und Weise, wie Software entwickelt wird, was für einige Entwickler:innen eine Herausforderung darstellen kann.
    \item \textbf{Nicht für alle Projekte geeignet}\\
    TDD ist nicht für alle Projekte geeignet, insbesondere für kleinere Projekte. Für kleinere Projekte gibt es Ansätze, die hierfür besser geeignet sind.
    \item \textbf{Gefahr für Overengineering}\\
    TDD kann zu Overengineering führen, wenn Entwickler:innen zu viele oder zu komplexe Tests schreiben, damit alle Anforderung abgedeckt werden können.
\end{itemize}

\section*{Vereinbarkeit mit den agilen Prinzipien}
TDD lässt sich im agilen Umfeld ähnlich zu klassischeren Entwicklungsprozessen, bei denen erst nach der Implementierung getestet wird, umsetzen. Dabei können die agilen Prinzipien größtenteils erfüllt werden.
\newline 
Aufgrund der Nachteile von TDD haben Entwicklungsteams allerdings oft Schwierigkeiten TDD anzunehmen und effektiv zu betreiben \cite{smart2023bdd}.  
Das liegt daran, dass Entwickler nicht genau wissen mit welchem Test sie starten und welchen sie als Nächstes schreiben sollen \cite{smart2023bdd}. 
\newline 
Aufgrund des höheren Zeitaufwands lässt sich argumentieren, dass Prinzipien 1 und 3 des agilen Manifests deshalb nicht komplett erfüllt werden können.
\newline 
Allerdings ist es möglich hochwertige Software mit geringerem Wartungsaufwand zu entwickeln. Das agile Prinzip \textit{„Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“} kann somit erfüllt werden und klassische Entwicklungsprozesse möglicherweise sogar übertroffen werden.
\newline 
Die Vereinbarkeit von TDD mit den agilen Prinzipien hängt also stark davon ab, wie effektiv es im Entwicklungsprozess praktiziert wird.
\newline 
Um die Nachteile zu umgehen und TDD einfacher zu lernen und praktizieren, wurde deshalb basierend auf TDD das Entwicklungsverfahren Behavior-Driven Development (BDD) von Dan North erfunden \cite{smart2023bdd}.


\section*{Best Practices}

\subsubsection*{Kleine unabhängige Tests}
Beim Erstellen von Tests sollte darauf geachtet werden, dass sie klein und unabhängig sind. Das bedeutet, dass ein Test nur eine spezifische Funktionalität testet und nicht von anderen Tests abhängig ist. Dadurch wird die Wartbarkeit der Tests erhöht und die Ursache von Fehlern ist leichter zu finden.

\subsubsection*{So wenig Code wie nötig}
Es sollte nur so viel Code geschrieben werden, wie erforderlich ist, um den Test zu bestehen. Dabei sollte vermieden werden, Code zu implementieren der nicht direkt mit dem aktuellen Testfall zusammenhängt. Dies trägt dazu bei, die Codebasis schlanker und besser wartbar zu machen, da sich jeder geschriebene Code auf spezifische Anforderungen und Funktionalitäten konzentriert.

\subsubsection*{Positve und Negative Tests}
Beim Schreiben von Tests ist es wichtig, sowohl positive als auch negative Szenarien zu testen. Das bedeutet, dass sowohl Fälle getestet werden sollten, in denen der Code korrekt funktionieren soll, als auch solche, in denen er scheitern soll. So können mögliche Probleme mit dem Code erkannt und sichergestellt werden, dass er robust und zuverlässig ist.

\subsubsection*{Testen Testen Testen}
Tests sollten immer wieder ausgeführt werden. So kann sichergestellt werden, dass der Code auch nach Änderungen noch korrekt funktioniert. Darüber hinaus ermöglicht es, Fehler frühzeitig zu erkennen und eine zuverlässige Codebasis aufrechtzuerhalten.

\section*{Codebeispiel}

\subsubsection*{Anforderung (Schritt 0)}
Es ist eine Funktion benötigt, die die Zahlen von 1-3 quadrieren kann.
Die Funktion soll als Input eine Zahl entgegennehmen und als Output die quadrierte Zahl zurückgeben.
Die Funktion soll den Namen \gqq{square} haben.

\subsubsection*{Testfälle (Schritt 1 \gqq{Red})}

\begin{lstlisting}[language=Python]
assert(square(1) == 1) # RED
assert(square(2) == 4) # RED
assert(square(3) == 9) # RED
\end{lstlisting}

\subsubsection*{Implementierung (Schritt 2 \gqq{Green})}
\begin{lstlisting}[language=Python]
def square(x):
    if number == 1:
        return 1
    elif number == 2:
        return 4
    elif number == 3:
        return 9

assert(square(1) == 1) # GREEN
assert(square(2) == 4) # GREEN
assert(square(3) == 9) # GREEN
\end{lstlisting}

\subsubsection*{Refactoring (Schritt 3 \gqq{Refactor})}
\begin{lstlisting}[language=Python]
def square(x):
    return x * x

assert(square(1) == 1) # GREEN
assert(square(2) == 4) # GREEN
assert(square(3) == 9) # GREEN
\end{lstlisting}

\color{SaddleBrown}
\section*{Fazit}
TDD ist ein Ansatz in der Softwareentwicklung, der mit seinen spezifischen Vorteilen wie Fehlerreduzierung und Verbesserung der Codequalität überzeugt, allerdings auch Herausforderungen wie höheren Zeitaufwand und Eignungsbegrenzungen mit sich bringt. Es ist eine Methode unter vielen, die in bestimmten Kontexten Vorteile bietet, aber nicht universell die optimale Lösung darstellt. Die Entscheidung für oder gegen TDD sollte daher projekt- und teamspezifisch getroffen werden.

\color{DarkSlateGray}


\nocite{*} % Print all references regardless of whether they were cited in the poster or not
\bibliographystyle{plain} % Plain referencing style
\bibliography{literature} % Use the example bibliography file literature.bib



\end{multicols}
\end{document}