Login


 
Newsletter
Werbung
Do, 13. Dezember 2012, 15:00

LanguageTool-Tutorial Teil III: Java-Regeln und falsche Freunde

Von gulp21

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.

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Frohe Weihnachten Fest!
Neue Nachrichten
Werbung