- for future work: more approaches like analysis in RESTler, Constructing Operation Dependency Graph in RESTest, precise inference with stemming algor\\
- \\
- \\
\begin{comment}
- What approaches and techniques exist to test OpenAPI specifications?
this is answered by section 3
- Can RAGs be used test OpenAPI specfications?
- Can the analysis techniques from the literature be expressed with RAGs?
this is answered by sec 4 + 5
- What is the benefit of expressing them with RAGs?
this is in the eval section
\end{comment}
- RQ2 : What makes it easier to use RAGs than normal code, what makes it harder?\\
- attributes for navigation/name resolution \\
- implementing relative bigger and structured codes with small definitions\\
- effort to be used to JastAdd\\
% 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 and features of JastAdd 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 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 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.
\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 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 an 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.
\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.
Automated testing is one type of software testing which is expected to review, validate software products and to find errors in these products. Compared to manual testing, it has a huge benefit in execution of test cases, while test cases are automatically generated. \\
Also, it might be a meaningful approach to raise the security, especially in web-based software architectures using REST interfaces. One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. \\
Automated testing is one type of software testing which is expected to review, validate software products and find errors in these products. Compared to manual testing, it has a huge benefit in execution of test cases, while test cases are automatically generated. \\
Also, it might be a meaningful approach to raise the security and quality in web-based software architectures using REST interfaces.
One kind of testing such architectures is to validate REST interfaces and check if there are errors in them. \\
In the last years, the OpenAPI Specification has become the common way to document the communication endpoints and exchanged data structures. This is useful to test REST interfaces, because it enables the black-box testing approach.
OpenAPI specifications are described as JSON or YAML documents and are defined by a semi-formal specification describing permitted and required elements as well as their semantics. While there is no formal definition of the full OpenAPI language, a meta-schema exists for the JSON Schema parts of the language. \\\\
This paper investigates how such specifications can be used to test interfaces described by them. Since these specifications itself are tree-shaped, the investigation focuses on a grammar-based analysis approach, reference attribute grammars (RAGs). \\
To understand what this paper basically is about, it is required to know what is software testing. Software testing is a method to see whether a software product works with its expected functionality and is defect free. The problem without testing is that bugs are expensive or also critical in terms of security. Solving this problem brings the software huge advantages (e.g. effectiveness, stronger security, robust software quality). \\
There are several classifications in software testing. One classification is related to goals of testing: testing if a software does not have critical bugs (Functional Testing), testing if a software is effective enough (Non-Functional Testing) and modifying an existent software product to correct appeared bugs (Regression Testing).
If a software product is implemented small enough, it is commonly better to test manually and a tester individually defines test cases. But, in most industrial softwares, like REST APIs, it is necessary to automate tests, because the products are too big and manual testing is too difficult at this point.\\
To understand what this paper is about, it is required to know what is software testing. Software testing is a method to see whether a software product works with its expected functionality and is defect free. The problem without testing is that bugs are expensive or also critical in terms of security. Solving this problem brings the software huge advantages (e.g. effectiveness, stronger security, robust software quality). \\
There are several classifications in software testing. One classification is related to goals of testing: testing if a software does not have critical bugs (Functional Testing), testing if a software is effective enough (Non-Functional Testing) and modifying an existent software product to correct appeared bugs (Regression Testing) [2].
If a software product is implemented small enough, it is commonly better to test manually and a tester individually defines test cases. But, in most industrial softwares, like REST APIs, it is necessary to automate tests, because the products are too big and manual testing is too difficult at this point.
%2
Afterwards, there is a box approach to divide software testing into three categories, black, white and grey Box Testing. Black box tests are developed without knowledge of the internal structure of the system to be tested, but on the basis of development documents. In practice, black box tests are usually not developed by software developers, but by technically oriented testers or by special test departments or test teams. White box tests are developed on the basis of knowledge about the internal structure of the component to be tested. Grey box test is a combination of black and white box tests practiced in parallel and based on restricted knowledge of the resource. \\
This paper focuses on automated testing with a black box approach. In section 2.3 the selection of the approach is explained.
\ No newline at end of file
Afterwards, there is a box approach to divide software testing into three categories, black and white Box Testing [1]. Black box tests are developed without knowledge of the internal structure of the system to be tested, but on the basis of development documents. In practice, black box tests are usually not processed by developers of a target software, but by technically oriented testers or by special test departments or test teams. White box tests are developed on the basis of knowledge about the internal structure of the component to be tested. \\
This paper focuses on automated testing with a black box approach. In section 2.3 the selection of the approach is explained.
% [1] Saleh, K.A. (2009). Software Engineering. J. Ross Publishing. pp. 224–41.
% [2] Basu, Anirban (2015). Software Quality Assurance, Testing and Metrics. PHI Learning. ISBN 978-81-203-5068-7.
