Seit langem bin ich mal wieder aktiv in der Implementierung einer Komponente, wenn auch erst mal nur ein Prototyp.<\/p>\n
Die Persistenz ist – nach dem neusten Trend “back to the roots” – nur noch mit dem JdbcTemplate von Spring gemacht. Da kann man wieder richtiges SQL schreiben und wei\u00df auch genau was passiert (bei Hibernate war ich mir nicht immer so ganz sicher).<\/p>\n
Als es dann ans Testen ging und ich mir Gedanken um die Testabdeckung machte, fiel mir auf, dass das was bei if-Anweisungen oder bedingter Zuweisung im Java-Code als “missed 2 of 4 branches” an gemeckert wurde, an vielen Stellen in den Where-Clauses der SQL-Statements genauso auftritt.<\/p>\n
Die Coverage in Java war also bei mancher Methode auf 100% aber das SQL-Statement lie\u00df viele Varianten von ResultSets zu je nach dem, was man f\u00fcr Testdaten verwendet und welche konkreten Parameter man bindet.<\/p>\n
Wie also l\u00e4\u00dft sich die SQL-Coverage messen?
\n<\/p>\n
Zun\u00e4chst einmal ist es n\u00fctzlich die SQL-Statement mitschrieben zu lassen, die tats\u00e4chlich ausgef\u00fchrt werden inklusive der aktuell gebundenen Parameter. Hierf\u00fcr kann man Tools wie http:\/\/code.google.com\/p\/log4jdbc-remix\/<\/a> bzw. http:\/\/code.google.com\/p\/log4jdbc\/<\/a> verwenden. Diese JDBC-Treiber arbeiten als Proxy und werden einfach “zwischen” die Applikation und den echten Treiber “geh\u00e4ngt”. Dadurch wird es einfach m\u00f6glich alle SQL-Statements die man bei Ablauf einer Testsuite an die Datenbank schickt mitzuschreiben.<\/span><\/p>\n Aber leider weiss man damit immer noch nicht, ob man nun alle m\u00f6glichen “Zweige” aller Where-Bedingungen aller SQL-Statements durchlaufen hat.<\/p>\n SQL Rules und QAShrink sind zwei Tool, die genau dar\u00fcber Aufschluss geben k\u00f6nnen. Sie sind in der Lage ein gegebenes SQL-Statement zu analysieren nach der “Full Predicate Coverage” Methode. Es werden also Regeln erzeugt, die alle Verzweigungen oder Varainten die ein SQL-Statement erzeugen kann, ber\u00fccksichtigt.<\/span><\/p>\n Dabei werden nicht nur Where-Bedingungen in Betracht gezogen, sondern nat\u00fcrlich auch Joins oder Group By-Klauseln. SQLRules zeigt zu einen einzelnen Statement diese Rules an, so dass man sich anschauen kann, welche m\u00f6glichen “Pfade” zur Ergebnisfindung durchlaufen werden k\u00f6nnen.<\/p>\n Im n\u00e4chsten Schritt lassen sich diese Regeln dann gegen einen Testdatenbestand anwenden \/ testen. Als Ergebnis bekommt man eine Aussage, ob die betreffende Regel verwendet wurde oder nicht, also ob dieser Pfad bei den zugrunde gelegten Daten durchlaufen wurde oder nicht. Das ist genau die SQL-Coverage die man braucht.<\/span><\/p>\n Das andere Tool QAShrink kann dieses Prinzip gleich auf eine ganze Liste von SQL-Statements anwenden. Es erzeugt dann Aussagen bzgl. der Coverage der SQL-Statements und der Vollst\u00e4ndigkeit bzw. der Redundanz der Testdaten.<\/span><\/p>\n Auf diese Weise kann man also ziemlich schnell herausfinden, welche Testdaten \u00fcberfl\u00fcssig und welche noch zu erg\u00e4nzen sind, um – bei gegebener Liste der SQL-Statements – die SQL-Coverage m\u00f6glichst hoch zu machen.<\/p>\n Das Vorgehen zum Erreichen einer m\u00f6glichst hohen SQL-Coverage l\u00e4\u00dft sich also so zusammenfassen:<\/p>\n Links zu den Tools: Seit langem bin ich mal wieder aktiv in der Implementierung einer Komponente, wenn auch erst mal nur ein Prototyp. Die Persistenz ist – nach dem neusten Trend “back to the roots” – nur noch mit dem JdbcTemplate von Spring gemacht. … Weiterlesen SQL Rules und QAShrink<\/h2>\n
Regeln anwenden<\/h2>\n
Zusammenfassung<\/h2>\n
\n
\nhttp:\/\/in2test.lsi.uniovi.es\/sqltools\/sqlrules\/<\/a>
\nhttp:\/\/in2test.lsi.uniovi.es\/sqltools\/qashrink\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"