chapter05.tex

\chapter{Project Tests}
\section{Mobile Application Tests}
\subsection{Unit Tests}
A unit test tests a single class, method, or function~\cite{testing-flutter}. The purpose of the unit test is to check the correctness of a logical unit under various conditions. External dependencies of the tested unit are usually mocked out. Unit tests generally do not render to screen, read from, or write to disk, or receive user actions from outside of the process running the test.

An example of such a test is shown in Listing~\ref{list:login-bloc-test}. First, we have to mock the \texttt{UserRepository} and \texttt{AuthenticationBloc} to eliminate any distortions. In the \texttt{setUp} method, we instantiate a new instance of \texttt{AuthenticationBloc} to ensure that each test runs under the same conditions and does not affect subsequent tests. The \texttt{tearDown} method runs after each test and destroys all unused objects. Next is a group of tests that imitates a user pressing the login button. First, we set the expected response, which consists of three states. In the end, we expect that the \texttt{LoginBloc} will yield \texttt{LoginInitial}, followed by a \texttt{LoginLoading} and lastly a \texttt{LoginInitial} in response to the \texttt{LoginButtonPressed} event.

\lstinputlisting[label=list:login-bloc-test,caption=Flutter login BLoC test]{code05/login_bloc_test.dart}

\subsection{Widget Tests}
A widget test (sometimes called the component test) tests a single widget~\cite{testing-flutter}. The goal of it is to check that the widget's UI looks and interacts as expected. Testing a widget involves many classes and requires a test environment that provides the appropriate widget life cycle context.

For instance, widgets that are being tested should be able to receive and respond to user events and actions, perform layout, and instantiate child widgets. This kind of test is more comprehensive than a unit test. Though, like unit tests, a widget tests' environment is replaced with an implementation much more straightforward than a fully developed UI system.

Two examples of widget tests are shown in Listing~\ref{list:widget-test}. First, we need to create a \texttt{CustomCard} widget that will be tested in the next steps. The component is responsible for rendering items in grades and payments lists (see Figure~\ref{fig:calendar-finances-grades}). The \texttt{buildTestableWidget} method wraps the widget with the \texttt{MaterialApp} and \texttt{MediaQuery} so that it can be built and tested correctly.

The next part checks if the ``CustomCard widget has aside, right and left widgets''. First, we have to build \texttt{CustomCard} inside the test environment by using the \texttt{pumpWidget} method provided by WidgetTester. It builds and renders the provided widget.

The following steps use the \texttt{find} method to search through the widget tree for the aside, right, and left widget. Then, as a result, we expect to locate one \texttt{asideWidget}, two \texttt{rightWidget}s, and one \texttt{leftWidget} component. The test ends successfully if all expected values match what has been found by using \texttt{Finder}.

The second test also uses the \texttt{CustomCard} type. It verifies that the ``CustomCard widget has a color''. First, we have to build the component, and then we can create a predicate used to filter widgets. We want to find only components that are \texttt{Containers} and have a decoration attribute equal to the specified \texttt{BoxDecoration}. If such components are found, the test passes.

\lstinputlisting[label=list:widget-test,caption=Flutter widget tests]{code05/widget_test.dart}

\section{Server Application Tests}
The transformation server required some manual testing when creating the configuration YAML files. All of it was done from the Postman application~\cite{postman}. A sample POST request to fetch calendar data shown in Listing~\ref{list:calendar-request} was used to test the transformation configuration.

\begin{lstlisting}[label=list:calendar-request,caption=Sample content of the POST request to fetch calendar data]
{
	"university": "pwr",
	"username": "pwr230115",
	"studentNumber": "123456",
	"startDate": "2020-01-01",
	"endDate": "2020-01-31"
}
\end{lstlisting}

Apart from the manual testing, the transformation was validated by unit tests. One of them is demonstrated below (List.~\ref{list:transformation-service-test}) and checks if the function responsible for translating all incoming requests and responses works as expected. It is a Spring Boot test, as indicated by the \texttt{@SpringBootTest} annotation. At the top of the \texttt{TransformationServiceTest} class are the static strings used to prepare the tests:
\begin{itemize}
    \item \texttt{REQUEST\_SPEC} - Jolt specification for the request;
    \item \texttt{RESPONSE\_SPEC} - Jolt specification for the response;
    \item \texttt{ADDRESS} - the API endpoint;
    \item \texttt{UNIVERSITY} - the chosen university;
    \item \texttt{CALENDAR\_JSON\_INPUT} - sample calendar request;
    \item \texttt{CALENDAR\_JSON\_OUTPUT} - expected calendar response.
\end{itemize}

\texttt{@BeforeAll} annotation placed above the \texttt{initAll} indicates that the method executes only once, before any test function. Inside it, a new transformation is initialized using predefined static strings.

The last method, called \texttt{transformCalendarJson}, tests the \texttt{transformJson} method from the \texttt{transformationService} class, which was autowired at the beginning. The \texttt{output} variable stores the result of the JSON transformation, which is compared, int the end, with the expected output. If they are equal, the test passes, if they are not the same or there was an exception while creating a new \texttt{JSONObject}, the test fails.

\lstinputlisting[label=list:transformation-service-test,caption=Tests for the transformation service requests]{code05/TransformationServiceTest.java}