OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie$^{5}$. In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
OpenAPI defines a parameter in an operation in four types, Query, Path, Header and Cookie$^{5}$. \footnote{this is described at \url{http://test.com}}In this work, only Query and Path parameters are considered to research the functionality of the Fuzzing prototype in RAG. These parameters are clearly describable in String values and also comfortably testable, because they target only variable URIs. \\
For the experiments, the OpenAPI document of a Pet Store is mainly used$^{6}$. Additionally, only GET and POST operations are tested to research basic functionality firstly.
% Process
The main attributed code at random testing is following:
@@ -17,11 +17,11 @@ for (ParameterOb o : operationObject.getParameterObs()) {
}
connect(Uri);
\end{lstlisting}
Initially, the attribute for random testing computes a list of parameter objects stored in RAG and iterates all elements in this list (Line 2). Subsequently, each iteration examines in which type the parameter is and produces a random URI. This URI is saved in a String variable (Line 4-7). Finally, the generator attribute sends a request
Initially, the generator for random testing computes a list of parameter objects stored in RAG and iterates all elements in this list (Line 2). Subsequently, each iteration examines in which type the parameter is and produces a random URI. This URI is saved in a String variable (Line 4-7). Finally, the test generator sends a request
with the generated URI (Line 9).
% Result
Besides operations with requirements of request bodies, results of this attribute implementation made possible to observe that parameters based on the specification were successfully randomized and they produced documented status codes in their operations. For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
Besides operations with requirements of request bodies, results of this implementation made possible to observe that parameters based on the specification were successfully randomized and they produced documented status codes in their operations. For future work, constraints of schema (minItems, maxItems, minLengths, maxLengths, etc.) can be completely extended. In this approach, the generator considers only the existence of enums.
@@ -48,7 +48,7 @@ As results, the test case generator with parameter inference implemented in this
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and back-transformation, attributes could not be applied, because the functional parts change the structure of AST, which conflicts to the definition of attribute and also in JastAdd. So, it could not be realized that attributes can be practical. But, following attributes and features of JastAdd were helpful to construct the generators and implement them:
\begin{itemize}
\item As long as a returning value can be called or storable in primitive way, the syntax in RAG is reduced with an equals sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing 5.3 and how this attribute is defined in common Java description in Listing 5.4.
\item As long as a returning value can be called or storable by an AST node, the syntax in RAG is reduced with an equals sign and simpler than in common programming language. Therefore, the source codes are compact. To compare how RAG could be implemented effectively, see the implementation of an attribute in this work in Listing 5.3 and how this attribute is defined in common Java description in Listing 5.4.
\item To iterate all paths available in OpenAPI, an inherited attribute facilitated the writing effort. Paths Objects are child nodes of OpenAPI Object, so, all that should have been done was only two lines of code instead of writing an extra for loop. See Listing 5.5.
\item As its name, Reference Attribute Grammar, every AST node can be referenced by an attribute. For instance, with a collection attribute. A reference defined in Listing 4.1 contains only a String variable named Ref, it still could provide its Object like in Listing 5.6.
