@@ -6,7 +6,7 @@ To solve this problem, most of REST API testing approaches use a stateful proces
\begin{itemize}
\item Case insensitive
\item Id completion in a field name (e.g. if a property is named with "id", it gets an additional field name available in the specification)aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
\item Id completion in a field name (e.g. if a property is named with "id", it gets an additional field name available in the specification)
\item Stemming algorithm (e.g. pet and pets are considered as a same value.)
\end{itemize}
...
...
@@ -42,7 +42,23 @@ for (String path : paths)
Before it starts with the parameter inference, the random testing generator of Section 5.1 is executed first (Line 1). During this execution, the status code of a response is checked if it is a successful response with 200 status code (Line 4). Afterwards, the response schema of returned values is also checked. If it is in type array, the function "writeDictionary" is iterated, otherwise it only executed once (Line 6-9). "writeDictionary" is not attributed, because it would be critical for the rule of RAG that an AST structure must not be edited, while attributes are computed. However, the function "writeDictionary" saves the returend values of a successful response in seperate properties and write them in a dictionary (e.g. properties "id" and "name" are seperately stored with their value in the dictionary). If the schema of a response provides a reference of a schema object, the field name gets a name of a reference as prefix. Subsequently, this implementation does the similar way of execution in random testing at the generation phase. Firstly, it iterates all parameter objects (Line 14) and examines whether the parameter type is Path or Query (Line 15-18). Both attributes return URIs with parameter values inferred by the dictionary and case insensitive comparison. Generated URIs are put in a list. Lastly, the generator attribute sends requests with the URIs and starts with observation (Line 20-21).
% Helpful attributes (Collection, inherited, easier return with =)
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and backtransformation, attributes could not be applicated, 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 were helpful to construct the generators and implement them:
During the implementation phase of parameter inference, RAG was beneficial at writing codes. At writing codes for parser and backtransformation, attributes could not be applicated, 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 returned type can be called or storable in primitive way, the syntax in RAG is reduced with an equlas 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.
