97 lines
5.3 KiB
TeX
97 lines
5.3 KiB
TeX
\section{Testing}
|
|
|
|
For the testing section of this project, the group focused mostly on creating tests that verify CRUD behaviour of subjects, assignments and tasks + an auth guard test. The reason that these specific tests were chosen is because they are core to the requirements while also being relatively obvious on how they should be set up.
|
|
|
|
\vspace{2mm}
|
|
|
|
An important note for all of these tests is that the tests should not actually interact with elements like \texttt{expo-router}, \texttt{asyncStorage}, \texttt{expo-notifications} or API's like \texttt{supabase}. Instead, they should be mocked/simulated using \texttt{jest.mock}.
|
|
% forklare hvorfor de mockes, og ikke tester direkte med UI?
|
|
|
|
|
|
|
|
\subsection{Subject Tests}
|
|
|
|
\subsubsection{Create Subject Test}
|
|
|
|
For the Create Subject test, the goal was to verify that a new subject can be created through the creation branch of the \texttt{handleSubmit} function in \texttt{upsertSubject.tsx}. Since this component normally relies on \texttt{supabase} and \texttt{expo-router}, these have to be mocked using \texttt{jest.mock}.
|
|
|
|
\vspace{2mm}
|
|
|
|
The test mocks \texttt{supabase.auth.getUser} so that a fake authenticated user exists for the test. This is important because the row level policy implemented in supabase for creating subjects requires authentication, meaning the test needs to simulate a logged in user. The supabase insert chain is also mocked, meaning one call to \texttt{insert}, one to \texttt{select}, and one to \texttt{single}. With this chain the test can simulate the supabase command used in the component.
|
|
|
|
\vspace{2mm}
|
|
|
|
For the actual test logic, the test starts by mocking a resolved value for \texttt{single}. This represents a successful database response after creating the subject. The test then renders the actual \texttt{UpsertSubject} component. Then it fills in the title field to pass the requirement that title must not be empty and presses the submit button. At this point it waits for asynchronous logic to finish.
|
|
|
|
\vspace{2mm}
|
|
|
|
Finally, the test defines its expectations. It expects \texttt{supabase.from} to have been called with \texttt{subjects}, which confirms that the correct table was targeted. Then it expects the mocked \texttt{insert} to have been called with an object containing the subject title and authenticated user id. Next, it expects the mocked \texttt{select} and \texttt{single} to have been called, completing the insert chain. Finally, it expects \texttt{router.back}, which confirms that the user would be routed back upon subject creation. If all these expectations pass, the test passes.
|
|
|
|
|
|
|
|
\subsubsection{Update Subject Test}
|
|
|
|
For the Update Subject test, the goal was to verify that an already existing subject can be updated through the update branch of the \texttt{handleSubmit} function in \texttt{upsertSubject.tsx}. Since this component normally relies on \texttt{supabase} and \texttt{expo-router}, these have to be mocked using \texttt{jest.mock}.
|
|
|
|
\vspace{2mm}
|
|
|
|
The test mocks \texttt{supabase.auth.getUser} so that a fake authenticated user exists for the test. This is important because the row level policy implemented in supabase for updating subjects requires authentication, meaning the test needs to simulate a logged in user. The test also mocks \texttt{useLocalSearchParams} so that the component receives an existing subject id. This makes the component behave as if it is updating an existing subject rather than creating a new one. The supabase update and select chains are also mocked. For update this means one call to \texttt{update}, and one to \texttt{eq} and for select this means one call to \texttt{select}, one to \texttt{eq} and one to \texttt{single}. With these chains the test can simulate the supabase commands used in the component.
|
|
|
|
\vspace{2mm}
|
|
|
|
For the actual test logic, the test starts by mocking a resolved value for \texttt{single}. This represents a successful database response after selecting the subject. It also mocks a resolved value for the update chain \texttt{eq}. This represents no errors upon submitting the update. The test then renders the actual \texttt{UpsertSubject} component. Then it verifies that the title field is filled in to pass the requirement that title must not be empty and presses the submit button. At this point it waits for asynchronous logic to finish.
|
|
|
|
\vspace{2mm}
|
|
|
|
Finally, the test defines its expectations. It expects \texttt{supabase.from} to have been called with \texttt{subjects}, which confirms that the correct table was targeted. Then it expects the mocked \texttt{select} to have been called. After that it expects the mocked \texttt{update} to have been called with an object containing the subject title and authenticated user id. Next, it expects the mocked update chain \texttt{eq} to have been called with a subject id, completing the update chain. Finally, it expects \texttt{router.back}, which confirms that the user would be routed back upon the subject update. If all these expectations pass, the test passes.
|
|
|
|
|
|
|
|
\subsubsection{Delete Subject Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsection{Assignment Tests}
|
|
|
|
\subsubsection{Create Assignment Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsubsection{Update Assignment Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsubsection{Delete Assignment Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsection{Task Tests}
|
|
|
|
\subsubsection{Create Task Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsubsection{Update Task Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsubsection{Delete Task Test}
|
|
|
|
.
|
|
|
|
|
|
|
|
\subsection{Auth Guard Test}
|