Proposing SQL Statement Coverage Metrics: Difference between revisions

Line 364:

== 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

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.

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

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

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.

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 364: / Line 364: @@
 == 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
+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.
-SQL statement coverage score of 96.7%. We found that 209 of
-the 212 SQL input variables found in the iTrust back-end were
+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.
-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 ==