LanguageTool-Tutorial Teil III: Java-Regeln und falsche Freunde
Testen von Java-Regeln
Im Gegensatz zu XML-Regeln befinden sich die Testdaten der (deutschen) Java-Regeln in separaten Dateien im Verzeichnis src/test/java/org/languagetool/rules/de. Jede Testdatei hat denselben Dateinamen wie die Regeldatei, ergänzt um das Suffix Test
.
Es folgt nun eine kurze Erläuterung der (gekürzten) WiederVsWiderRuleTest.java.
package org.languagetool.rules.de; import java.io.IOException; import junit.framework.TestCase; import org.languagetool.JLanguageTool; import org.languagetool.Language;
Zunächst werden wieder die benötigten Klassen importiert.
public class WiederVsWiderRuleTest extends TestCase {
Der Klassenname entspricht wieder dem Dateinamen und die Klasse ist eine Unterklasse der Klasse TestCase.
public void testRule() throws IOException { WiederVsWiderRule rule = new WiederVsWiderRule(null); JLanguageTool langTool = new JLanguageTool(Language.GERMAN); // correct sentences: assertEquals(0, rule.match(langTool.getAnalyzedSentence("Das spiegelt wider, wie es wieder läuft.")).length); // errors: assertEquals(1, rule.match(langTool.getAnalyzedSentence("Das spiegelt wieder, wie es wieder läuft.")).length); } }
Innerhalb der testRule
-Funktion wird geprüft, ob die Regel in bestimmten Sätzen einen Fehler findet. Dazu wird zunächst eine Instanz der Regel gestartet und die Sprache auf Deutsch gesetzt. Anschließend wird überprüft, ob die Regel in den angegebenen Beispielsätzen genau null bzw. einen Fehler findet.
Um die automatischen Tests von LanguageTool durchzuführen, führt man den Befehl
$ ant test
im Verzeichnis languagetool
aus. Bei einem Fehler wird der Test sofort mit einer Fehlermeldung beendet.
Auch Java-Regeln können anhand von Wikipedia-Artikeln getestet werden. Dies funktioniert wie bei den XML-Regeln mit testwikipedia.sh
(vgl. letzte Folge).
POS-Tags in Java-Regeln
Da diese recht einfache Regel keine POS-Tags (Wortarten) auswerten muss, diese aber in komplexeren Regeln oft Verwendung finden, soll noch kurz erklärt werden, wie man mit POS-Tags in Java-Regeln arbeitet. Eine Übersicht aller POS-Tags befindet sich in dem PDF-Dokument von Wolfgang Lezius.
Die Klasse AnalyzedTokenReading bietet dazu verschiedene Funktionen an. So kann mit hasPosTag()
geprüft werden, ob ein Token ein bestimmtes POS-Tag hat, beispielsweise tokens[i].hasPosTag("SUB:NOM:SIN:MAS")
(Substantiv Nominativ Singular Maskulinum).
Wenn nur ein Teil eines POS-Tags gefunden werden soll, verwendet man stattdessen tokens[i].hasPartialPosTag("SUB:NOM:")
.
Zu beachten ist, dass beide Funktionen prüfen, ob bei irgendeiner möglichen Lesart eine Übereinstimmung vorhanden ist. Beispielsweise gibt token.hasPartialPosTag("SUB:NOM:")
bei »Autos« true
zurück, auch wenn »Autos« auch Genitiv sein kann.
Will man solche Doppeldeutigkeiten behandeln, muss man mit Hilfe der Funktion getReadings()
alle Lesarten des Tokens prüfen. getReadings()
gibt dabei eine Liste von AnalyzedToken
zurück.
SVN-Grundlagen
Weil für die LanguageTool-Entwicklung das Arbeiten mit grundlegenden Funktionen der Versionsverwaltung Subversion beherrscht werden sollte, werden an dieser Stelle die für die Entwicklungsarbeit wichtigsten Befehle kurz erklärt.
Nachdem man den Quelltext mit dem am Anfang erwähnten Befehl svn co
heruntergeladen hat, hält man den Code mit svn update
auf dem aktuellen Stand. Mit svn status
kann man sich anzeigen lassen, welche Dateien sich lokal im aktuellen Ordner und allen Unterordnern geändert haben und ob neue Dateien existieren, die noch nicht hochgeladen wurden. svn add Dateiname
wird benutzt, um Dateien hinzuzufügen.
Um die Änderungen an Dateien anzuzeigen, verwendet man svn diff
; wenn man eine grafische Ausgabe bevorzugt, kann man die Ausgabe auch an ein grafisches Diff-Tool wie z.B. Kompare weiterleiten (svn diff - kompare -
).
Mit svn commit
werden alle Änderungen, die von svn status
angezeigt werden, hochgeladen, sofern man die Berechtigung hat, Änderungen am öffentlichen Code von LanguageTool vorzunehmen. Wenn man diese Berechtigung nicht hat, kann mit svn diff > datei.patch
ein Patch erstellt werden, den man dann z.B. auf der Mailingliste veröffentlichen kann, damit die neue Regel in LanguageTool aufgenommen wird. Bevor man Änderungen hochlädt oder einen Patch erstellt, sollte aber noch ant test
durchgeführt werden, um nicht versehentlich bestehende Funktionen kaputt zu machen.