|
From: oliver <oli...@gm...> - 2013-05-30 21:13:31
|
Hallo, PatternTesting ist als AOP-Library entstanden, um Anti-Pattern aufzuspüren, z.B., um null als Parameter oder Rückgabewert aufzuspüren. Dazu wird der AspectJ-Compiler verwendet, um die zusätzliche Überprüfungen einzu"weben". Wenn man diese Überprüfungen im ausgelieferten Code nicht will, lässt man diesen Webe-Vorgang beim Build weg (kann man in Maven z.B. über Profiles lösen). Die eingestreuten Überprüfungen sind allerdings nur dann aktiv, wenn Assertions eingeschaltet sind (VM-Option -ea, also 'java -ea …'). Damit können die Überprüfungen auch im ausgelieferten Code verbleiben, da man die Option "-ea" eigentlich nur zum Testen setzt, niemals aber in Produktion. "gdv.xport" (https://github.com/oboehm/gdv.xport) ist z.B. eine Java-Bibliothek, die das so macht. Über diesen ursprünglichen Zweck heraus sind weitere Features in PatternTesting hinzugekommen, die das Aufspüren von Fehlern erleichtern sollen. Dazu gehört Unterstützung für JUnit-Tests, aber auch Unterstützung bei Exceptions oder ein ClasspathMonitor, den man zur Laufzeit über die JConsole aufrufen kann. Die "normalen" Programmierrichtlinien (wie z.B. Zeilenlänge <= 80) lassen sich oft mit statischer Code-Analyse überprüfen. Hier sind Tools wie FindBugs, PMD/CPD oder Checkstyle besser geeignet oder (mein persönlicher Favorit) Sonar, das diese Überprüfungen unter einem Dach zusammenfasst. Der Fokus von PatternTesting liegt eher auf dynamische Prüfungen (wie 'null' als Parameter). Daneben sind noch statische Prüfungen wie "kein JDBC-Aufruf" möglich - wenn dies Bestandteil ihrer Programmierrichtlinien sind, ist das mit PatternTesting möglich. Am 4. Juli halte ich auf dem Java Forum Stuttgart einen Vortrag über Anti-Patterns (http://www.java-forum-stuttgart.de/de/Abstracts+Slot+1.html#art482). Falls Sie dort sind, können wir ja darüber diskutieren, wie man was am besten einsetzt. Ansonsten: bei Fragen einfach fragen... mfg oli b. Am 30.05.2013 um 14:06 schrieb tryist <no...@so...>: > Hallo, > > ich habe die PDF eines ihrer Vorträge \"Pleiten, Pech und > Pattern Testing\" gefunden. > Wir sind prinzipiell sehr daran interessiert automatische > Checks auf dieverse Anti Pattern durchzuführen, aber ich bin > mir noch nicht ganz sicher, ob ich richtig verstanden habe, > was das Projekt macht. > > Wir würden wie gesagt gerne auf anti-Pattern testen. Z.B. > dass Parameter nicht null sein dürfen. Dies würden wir dann > einfach während der Entwicklung und dem Testen mitlaufen > lassen und dann eine Version ohne das alles Releasen. > Allerdings handelt wohl ja ein Großteil von JUnit Tests? Wie > gut funktioniert das ganze, wenn man quasi nur > Programmierrichtlinien einführen will, bin ich da hier > richtig? Oder sind da eher andere Projekte zu empfehlen. > > Mit freundlichen Grüßen > > -- > This message was sent to your SourceForge.net email alias via the web mail form. You may reply to this message via https://sourceforge.net/sendmessage.php?touser=3603495 > To update your email alias preferences, please visit https://sourceforge.net/account |