\chapter{Afprøvning af editor}

%systematik!!!
%gå frem efter kravspec.
%visual + junit (ekstern afprøvning)
%lav fine skemaer

\begin{intro}
Følgende afsnit vil præsentere en strategi for afprøvning af editoren samt resultater af afprøvningen. Afprøvningen er udført som ekstern afprøvning. Yderligere resultater er at finde i bilag \ref{sec:testresult}.
\end{intro}

\section{Afprøvnings strategi}

For at afprøve editoren tages udgangspunkt i kravspecifikationen i afsnit \ref{editor-kravspek} side \pageref{editor-kravspek}. Herfra er der opstillet afprøvnings scenarier for hvert krav. 

Det har naturligvis ikke været muligt, ej heller ønskværdigt, at præsentere alle mulige scenarier. Hvorfor der kun er udvalgt nogle repræsentative scenarier til dette afsnit. Desuden har der p.g.a. manglende tid ikke været muligt at gennemføre alle scenarier. Ydermere er det enkelte scenario kun afprøvet på en af de understøttede platforme.

Afprøvningen af editor er delt op i 2 hovedgrupper. Brugerafprøvning og ekstern afprøvning af specifikke klasser og algoritmer.

Brugerafprøvningen sikrer at programmet opfører sig som brugeren forventer. Dette gøres ved at opstille nogle scenarier for de krav, der er stillet til programmet fra en brugers synspunkt. En brugers handling skridt for skridt opstilles i et skema, med forventet resultat og egentlige resultat for hvert skridt. Derved kan man danne sig et overblik over eventuelle mangler eller uhensigtsmæssigheder i forhold til ventet.

Den eksterne afprøvning kom aldrig videre end planlægningsfasen p.g.a. den førnævnte mangel på tid. Dette var tænkt udført for nogle få repræsentativt udvalgte klassers vedkommende, ved at opstille ækvivalensklasser for disse. Dette skulle afprøves v.ha. JTest's indbyggede understøttelse for ``Design by Contract''\ \cite{dbc}. JTest er et værktøj til automatiseret afprøvning af Java programmer.

Desuden er der skrevet unit tests af nogle af klasserne. De er alle skrevet i forbindelse med udviklingen af projektet for løbende at kunne undersøge om klassen fungerede som tiltænkt. Uagtet hvilken stand resten af systemet befandt sig i.

Unit tests er udført v.ha. værktøjet JUnit der er et hjælpeværktøj til at udføre unit tests af java kode. 

\section{Brugerafprøvning af editor}

Der er kun medtaget to scenarier fra afprøvningen i denne rapport, resten kan findes i bilag \ref{sec:testresultvis} på side \pageref{sec:testresultvis}. Scenarierne er følgende:

\begin{itemize}
\item Tre punkter danner polygon
\item Vælg og flyt polygon
\item Slet polygon fra bane
\item Skift farve på polygon
\item Sammensmeltning af to punkter
\item Flytning af kant
\end{itemize}

De to er udvalgte er ``Tre punkter danner polygon''\ og ``Skift farve på polygon''\ .

\begin{tabular}{| p{0.3\textwidth} | p{0.3\textwidth} | p{0.3\textwidth} |}
\hline
\textbf{Nr.} & \multicolumn{2}{| p{0.6\textwidth} |}{\textbf{Navn}} \\
\hline
1 & \multicolumn{2}{| p{0.6\textwidth} |}{Tre punkter danner polygon} \\
\hline
\textbf{Platform} & \multicolumn{2}{| p{0.6\textwidth} |}{MacOS X} \\
\hline  
\multicolumn{3}{| p{0.9\textwidth} |}{\textbf{Beskrivelse}} \\
\hline
\multicolumn{3}{| p{0.9\textwidth} |}{Ved at afsætte tre punkter efter hinanden i editoren dannes en udfyldt trekant umiddelbart efter det tredje punkt er afsat.} \\
\hline
\hline
\textbf{Trin beskrivelse} & \textbf{Forventet resultat} & \textbf{Resultat} \\
\hline
Åbn editoren & Editoren startet, klar til input & Editoren er klar til input \\
\hline
Lav en ny bane & Et nyt bane vindue i editoren & Bane vindue klar til input \\
\hline
Afsæt et punkt i banen & Banen indeholder et punkt og der hvor der blev trykket ses nu en lille firkant & Et lille punkt ses i bane vinduet \\
\hline
Afsæt endnu et punkt lidt nord vest for det første punkt & Endnu et punkt i editoren & En lille firkant til \\
\hline
Afsæt endnu et punkt øst for det andet punkt & En hvid trekant dannes med sorte kanter og endnu en lille firkant & Der dannes en trekant \\ 
\hline
\hline 
\multicolumn{2}{| l |}{\textbf{Afprøvning bestået}} & Ja, se evt figur \ref{fig:test1.0r}, \ref{fig:test1.1r} \\
\hline
\end{tabular}

\begin{figure}[h]
\begin{center}
    \begin{minipage}[t]{0.4\textwidth}
        \begin{center}
	\includegraphics[width=0.6\textwidth]{gfx/tests/11.jpg}
            \caption{To punkter afsat}
            \label{fig:test1.0r}
        \end{center}
    \end{minipage}
    \begin{minipage}[t]{0.4\textwidth}
        \begin{center}
	\includegraphics[width=0.6\textwidth]{gfx/tests/12.jpg}
            \caption{Trekant dannet}
            \label{fig:test1.1r}
        \end{center}
    \end{minipage}
\end{center}
\end{figure}

\begin{tabular}{| p{0.3\textwidth} | p{0.3\textwidth} | p{0.3\textwidth} |}
\hline
\textbf{Nr.} & \multicolumn{2}{| p{0.6\textwidth} |}{\textbf{Navn}} \\
\hline
4 & \multicolumn{2}{| p{0.6\textwidth} |}{Skift farve} \\
\hline
\textbf{Platform} & \multicolumn{2}{| p{0.6\textwidth} |}{MacOS X} \\
\hline  
\multicolumn{3}{| p{0.9\textwidth} |}{\textbf{Beskrivelse}} \\
\hline
\multicolumn{3}{| p{0.9\textwidth} |}{Ved at ændre i farve egenskaberne for en polygon skifter polygonet farve} \\
\hline
\hline
\textbf{Trin beskrivelse} & \textbf{Forventet resultat} & \textbf{Resultat} \\
\hline
Følg scenarie 1 & - & - \\
\hline
Vælg polygonen og skift farve & Polygonen skifter farve & Polygonen bliver sort, men først efter at polygonen ikke længere er valgt. Måske burde farven der angiver at en polygon er valgt være en toning af polygonens farve \\
\hline
\hline
\multicolumn{2}{| l |}{\textbf{Afprøvning bestået}} & Ja, men måske bør der ses på hvordan en polygon vises som værende valgt, se evt figur \ref{fig:test4.0r}, \ref{fig:test4.1r} \\
\hline
\end{tabular}

\begin{figure}[h]
\begin{center}
    \begin{minipage}[t]{0.4\textwidth}
        \begin{center}
	\includegraphics[width=0.6\textwidth]{gfx/tests/41.jpg}
            \caption{Polygon valgt}
            \label{fig:test4.0r}
        \end{center}
    \end{minipage}
    \begin{minipage}[t]{0.4\textwidth}
        \begin{center}
	\includegraphics[width=0.6\textwidth]{gfx/tests/42.jpg}
            \caption{Polygonen farvet}
            \label{fig:test4.1r}
        \end{center}
    \end{minipage}
\end{center}
\end{figure}

\section{Unit test}

Resultatet af unit test kørslen kan findes i bilag \ref{sec:unitresult}.

\subsection{Afprøvning af \texttt{Map}}

I \texttt{Map} klassen afprøves metoderne: \texttt{getProperties} for at verificere at egenskaberne for map opdateres ved en setProperties og at de kommer ud igen i samme stand. \texttt{getVerticesInRect(Rectangle)} for at verificere at man ved at specificere et område i planet får returneret hvilke \texttt{Vertex} objekter der ligger inden for. \texttt{getTrianglesInRect(Rectangle)} for at undersøge om man får de \texttt{Triangles} tilbage der ligger i \texttt{Rectangle}. \texttt{select(Point)} undersøges for at se om der returneres \texttt{Vertex}, \texttt{Edge} og \texttt{Triangle} afhængig af \texttt{Point}.

Fælles for alle metoderne er at der forinden er lavet en bane med to polygoner, der ligger op ad hinanden. Selve koden kan findes i bilag \ref{sec:unittestcodeeditor}.

\subsubsection{\texttt{getVerticesInRect(Rectangle} og \texttt{getTrianglesInRect(Rectangle)}}

Et kald til getVerticesInRect kan resultere i 0, 1 eller flere returnerede objekter. Derfor konstrueres 3 kald til metoderne, et der bør give 0, et andet 1 og endelig et der skal returnere to objekter.

\subsubsection{\texttt{select(Point)}}

\texttt{select(Point)} returnerer det objekt der i banen er nærmest \texttt{Point}. Hvis der ingen Vertex, Edge eller Triangle, er returneres banen selv, altså et Map objekt. Derfor konstrueres et kald til select, der bør resultere i en af hver af disse situationer

\subsubsection{\texttt{getProperties}}

Ved først at sætte en mængde egenskaber på et Map trækkes de ud igen og sammenlignes med de oprindelige værdier.

\subsubsection{Resultat}

Alle dele i afprøvningen består.

\subsection{Andre klassers afprøvning}

Det samme er gjort for yderligere to klasser, Vertex og Exporter. Afprøvningen af disse kan findes i bilag \ref{sec:unittestcodeeditor}. Resultatet var at begge bestod. Andre klasser kunne afprøves efter samme mønster hvis der havde været tid.

\section{Opsummering}

Udfra den udførte afprøvning ses det, at langt det meste virker som det er tiltænkt. Unit test består alle, hvilket hovedsageligt skyldes, at de alle har været en del af selve udviklingen af klassen, de afprøver. Brugerafprøvningen påviser visse mangler i brugergrænsefladen.

Der mangler dog stadig den eksterne afprøvning. En hurtig gennemkørsel af programmet med JTest afslører manglende håndtering af RuntimeExceptions flere steder i programmet. Dette er et område til nærmere undersøgelse hvis tiden tillod det.
