Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 347:

The code fragment in Figure 8 demonstrates the execution of a SQL statement found within an iTrust DAO. Each of the JDBC execute method calls represents communication with the DBMS and has the potential to change the database.

We assign each execute method call a unique identifier id in the range 1, 2, ... , n where n is the total number of execute method calls. We then instrument the code to contain a call to <code>SQLMarker.mark(id)</code>. This <code>SQLMarker</code> class interfaces with a research database we have setup to hold status information foreach statically identified execute method call. Before running the test suite, we load (or reload) a SQL table with records corresponding to each unique identifier from 1 to n. These records all contain a field <code>marked<code> which is set to <code>false</code>. The <code>SQLMarker.mark(id)</code> method changes <code>marked</code> to <code>true</code>. If <code>marked</code> is already true, it will remain true.

We assign each execute method call a unique identifier id in the range 1, 2, ... , n where n is the total number of execute method calls. We then instrument the code to contain a call to <code>SQLMarker.mark(id)</code>. This <code>SQLMarker</code> class interfaces with a research database we have setup to hold status information foreach statically identified execute method call. Before running the test suite, we load (or reload) a SQL table with records corresponding to each unique identifier from 1 to n. These records all contain a field <code>marked</code> which is set to <code>false</code>. The <code>SQLMarker.mark(id)</code> method changes <code>marked</code> to <code>true</code>. If <code>marked</code> is already true, it will remain true.

Using this technique, we can monitor the call status of each execute statement found within the iTrust production code. When the test suite is done executing, the table in our research database will contain n unique records which correspond to each method call in the iTrust production code. Each record will contain a boolean flag indicating whether the statement was called during test suite execution. The line with the comment instrumentation shows how this method is implemented in the example code in Figure 8.

@@ Line 347: / Line 347: @@
 The code fragment in Figure 8 demonstrates the execution of a SQL statement found within an iTrust DAO. Each of the JDBC execute method calls represents communication with the DBMS and has the potential to change the database.
-We assign each execute method call a unique identifier id in the range 1, 2, ... , n where n is the total number of execute method calls. We then instrument the code to contain a call to <code>SQLMarker.mark(id)</code>. This <code>SQLMarker</code> class interfaces with a research database we have setup to hold status information foreach statically identified execute method call. Before running the test suite, we load (or reload) a SQL table with records corresponding to each unique identifier from 1 to n. These records all contain a field <code>marked<code> which is set to <code>false</code>. The <code>SQLMarker.mark(id)</code> method changes <code>marked</code> to <code>true</code>. If <code>marked</code> is already true, it will remain true.
+We assign each execute method call a unique identifier id in the range 1, 2, ... , n where n is the total number of execute method calls. We then instrument the code to contain a call to <code>SQLMarker.mark(id)</code>. This <code>SQLMarker</code> class interfaces with a research database we have setup to hold status information foreach statically identified execute method call. Before running the test suite, we load (or reload) a SQL table with records corresponding to each unique identifier from 1 to n. These records all contain a field <code>marked</code> which is set to <code>false</code>. The <code>SQLMarker.mark(id)</code> method changes <code>marked</code> to <code>true</code>. If <code>marked</code> is already true, it will remain true.
 Using this technique, we can monitor the call status of each execute statement found within the iTrust production code. When the test suite is done executing, the table in our research database will contain n unique records which correspond to each method call in the iTrust production code. Each record will contain a boolean flag indicating whether the statement was called during test suite execution. The line with the comment instrumentation shows how this method is implemented in the example code in Figure 8.