approach.tex

\section{Approach} \label{Sec:approach}
Our main goal in this work is to generate client-side test cases coupled with
effective test oracles, capable of detecting regression \javascript and DOM-level faults. 
Further, we aim to achieve this goal as efficiently as possible. Hence, we make two design decisions. First, we assume that there is a finite amount of time available to generate test cases. Consequently we guide the test generation  to maximize coverage under a given time constraint. 
The second decision is to minimize the number of test cases and oracles generated to only include those that are essential in detecting potential faults. %Thus, we only include useful oracles that help testers to find the fault without the need for checking the whole state of the system. 
Consequently, to examine the correctness of the test suite generated, the tester would only need to examine a small set of assertions, which minimizes their effort.

Our approach generates test cases and oracles at two complementary levels:
\begin{description}%[noitemsep, nolistsep]
\item[DOM-level event-based tests] consist of DOM-level event sequences and assertions to check the application's behaviour from an end-user's perspective. 
\item[Function-level unit tests]  consist of unit tests with assertions that verify the functionality of \javascript code at the function level.
\end{description}

An overview of the technique is depicted in \figref{approach-view}. 
At a high level, our approach is composed of three main steps:

\begin{figure}[!t]
  \centering
  \includegraphics[width=1\hsize]{fig/approach-view-revised}
  \mycaption{Overview of our test generation approach.}
  \vspace{-0.1in} 
  \label{Fig:approach-view}
  \vspace{-0.1in} 
\end{figure}

\begin{enumerate}%[noitemsep,nolistsep]
 
\item In the first step (Section~\ref{Sec:funcCovg}), we dynamically explore various states of a given web 
application, in such a way as to maximize the number of functions that are covered throughout the program execution. The output of this initial step is a state-flow graph (SFG) \cite{mesbah:tse12}, capturing the explored dynamic DOM states and event-based transitions between them. 

\item In the second step (Section~\ref{Sec:testCaseGen}), we use the inferred SFG to generate event-based test cases.
We run the generated tests against an instrumented version of the application. From the execution trace obtained, we extract DOM element states as well as \javascript function states at the entry and exit points.%, from which we generate function-level unit tests.

\item To create effective test oracles for DOM-level test cases, we perform a DOM-based mutation analysis (Section~\ref{Sec:oracleGen}).
The test oracles are generated at the DOM level by comparing DOM properties inferred from the original and the mutated versions of the application.
To reduce the number of function-level unit test cases as well as generated oracles to only those that are constructive, 
we automatically generate mutated versions of the application (Section~\ref{Sec:oracleGen}). We devise a \emph{state reduction} algorithm that minimizes the number of states by selecting representative mutated function states. The corresponding original states are used to generate function-level unit tests.
Assuming that the original version of the application is fault-free, the test oracles are then generated at the code level by comparing the states traced from the original and the mutated versions.

\end{enumerate}

%Next, we describe each of these three steps in detail.

\input{funcCovg}
\input{testCaseGen}
\input{oracleGen}