Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 361:

To calculate input variable coverage, we included a second variable in the <code>SQLMarker.mark</code> method which allows us to record the number of input variables which were set in the execute method. Initially, the input variable records of each execute method are set to zero, and the <code>SQLMarker.mark</code> method sets them to the passed value. iTrust uses PreparedStatements for its SQL statements and as Figure 8 demonstrates, the number of input variables is always clearly visible in the production code because PreparedStatements require the explicit setting of each variable included in the statement. As with the determination of SQL statements, there are similar issues with determining the number of SQL input variables which we present in Section 7.

== 6. Results and Discussion ==

We found that 90 of the 93 SQL statements in the iTrust serverside production code were executed by the test suite, yielding a

SQL statement coverage score of 96.7%. We found that 209 of

the 212 SQL input variables found in the iTrust back-end were

executed by the test suite, yielding a SQL variable coverage score

of 98.5%. We find that iTrust is a very testable system with

respect to SQL statement coverage, because each SQL statement,

in essence, is embodied within a method of a DAO. This

architectural decision is designed to allow the separation of

concerns. For example the action of editing a patient’s records via

user interface is separated from the action of actually updating

that patient’s records in the database. We find that even though

the refactoring of iTrust was intended to produce this high

testability, there are still untested SQL statements within the

production code. The Action classes of the iTrust framework

represent procedures the client can perform with proper

authorization. Since iTrust’s line coverage is at 91%, the results

for iTrust are actually better than they would be for many existing

systems due to its high testability.

The three uncovered SQL statements occurred in methods which

were never called by any Action class and thus are never used in

production. Two of the statements related to the management of

hospitals and one statement offered an alternate way of managing

procedural and diagnosis codes. The uncovered statements

certainly could have eventually been used by new features added

to the production and thus the fact that they are not executed by

any test is still pertinent.

== 9. References ==

@@ Line 361: / Line 361: @@
 To calculate input variable coverage, we included a second variable in the <code>SQLMarker.mark</code> method which allows us to record the number of input variables which were set in the execute method. Initially, the input variable records of each execute method are set to zero, and the <code>SQLMarker.mark</code> method sets them to the passed value. iTrust uses PreparedStatements for its SQL statements and as Figure 8 demonstrates, the number of input variables is always clearly visible in the production code because PreparedStatements require the explicit setting of each variable included in the statement. As with the determination of SQL statements, there are similar issues with determining the number of SQL input variables which we present in Section 7.
+== 6. Results and Discussion ==
+We found that 90 of the 93 SQL statements in the iTrust serverside production code were executed by the test suite, yielding a
+SQL statement coverage score of 96.7%. We found that 209 of
+the 212 SQL input variables found in the iTrust back-end were
+executed by the test suite, yielding a SQL variable coverage score
+of 98.5%. We find that iTrust is a very testable system with
+respect to SQL statement coverage, because each SQL statement,
+in essence, is embodied within a method of a DAO. This
+architectural decision is designed to allow the separation of
+concerns. For example the action of editing a patient’s records via
+user interface is separated from the action of actually updating
+that patient’s records in the database. We find that even though
+the refactoring of iTrust was intended to produce this high
+testability, there are still untested SQL statements within the
+production code. The Action classes of the iTrust framework
+represent procedures the client can perform with proper
+authorization. Since iTrust’s line coverage is at 91%, the results
+for iTrust are actually better than they would be for many existing
+systems due to its high testability.
+The three uncovered SQL statements occurred in methods which
+were never called by any Action class and thus are never used in
+production. Two of the statements related to the management of
+hospitals and one statement offered an alternate way of managing
+procedural and diagnosis codes. The uncovered statements
+certainly could have eventually been used by new features added
+to the production and thus the fact that they are not executed by
+any test is still pertinent.
 == 9. References ==