cool, das neue iceScrum ist da:
http://www.icescrum.org/features/
Wer von den PMs da draussen benützt das?
Dieses Blog ist in erster Linie ein öffentliches Notizbuch für mich selber: ich notiere darin kleine Dinge, die ich immer wieder vergesse. Oder Entwicklungen, die ich spannend finde.
Donnerstag, 26. Januar 2012
Cucumber
Das tönt ja spannend, Cucumber: BDD, BehaviourDrivenDevelopment, mit einer natürlichen, Deutschen Sprache Gherkin (Gherkin is the language that Cucumber understands. It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. )
Ich muss das mal genauer anschauen.
Ich muss das mal genauer anschauen.
Dienstag, 24. Januar 2012
JUnit Matcher / Hamcrest
mit dem Matcher können komplexere Vergleiche mit "assertThat" getestet werden, hier ein einfaches Beispiel, welches testet, dass zwei Daten am gleichen Tag sind.
https://gist.github.com/2306009
https://gist.github.com/2306009
Siehe auch:
und:
Reflection Kleinzeugs
Zwei kleine Reflection-Gedankenstützen, nützlich für Quick-Hacks bei Testdatengenerierung:
Generiert aus den Feldern einer Klasse Headers für ein CSV-Testdatenfile:
Generiert aus den Feldern einer Klasse Headers für ein CSV-Testdatenfile:
public static void generiereCVSHeaders() {
String header = "br0047;";
Field[] fieldsInput = Testvektor.class.getDeclaredFields();
for (Field field : fieldsInput) {
header += field.getName() + ";";
}
System.out.println(header);
}
Holt als allen Feldern eines Testobjektes "destObject" die entprechenden Werte (d.h. die mit dem gleichen Namen wie das Feld) aus einem JDBC-ResulSet und setzt diesen Wert dann auch im entsprechenden Feld:
/**
* Holt für alle Attribute des destObjects die gleichnamigen Werte aus den Spalten des resultSets und füllt sie im
* destObject ab.
* @param resultSet
* Quelle der Daten
* @param destObject
* Ziel der Daten
* @throws SQLException
* wird u.a. geworfen, wenn das destObject Attribute hat, welche im resultSet nicht vorkommen.
* @throws IllegalAccessException
*/
private static void mapDBcolumsToFieldsOfObject(ResultSet
resultSet, Object destObject) throws SQLException,
IllegalAccessException {
Field[] fields =
destObject.getClass().getDeclaredFields();
for (Field field : fields) {
int column =
resultSet.findColumn(field.getName());
Class<?> type = field.getType();
field.setAccessible(true);
// kümmert
sich um "null" Werte...
if (resultSet.getString(column) != null && resultSet.getString(column).equals("null")) {
field.set(destObject, null);
} else if (type == Integer.class || type.getName() == "int") {
field.set(destObject,
resultSet.getInt(column));
} else if (type == String.class) {
field.set(destObject,
resultSet.getString(column));
} else if (type == Double.class) {
field.set(destObject,
resultSet.getDouble(column));
} else if (type == Date.class) {
field.set(destObject,
resultSet.getDate(column));
} else if (type == Short.class) {
field.set(destObject,
resultSet.getShort(column));
} else if (type == Boolean.class || type.getName() == "boolean") {
field.set(destObject,
resultSet.getBoolean(column));
} else {
throw new IllegalArgumentException("noch nicht unterstütztes Mapping: " + type.getCanonicalName());
}
}
}
Freitag, 20. Januar 2012
JUnit-Massentest mit Parameter aus CSV-File
Mit JUnit-Bordmitteln ist es möglich, JUnit-Tests zu parametrisieren und sie mit Testdaten abzufüllen. Die Testdaten kommen in diesem Beispiel aus einem CSV-File, das in einer H2-Datenbank zwischengespeichert wird.
Der Trick:
Der spezielle JUnit-Runner Parametrized, der mit @RunWith angekickt wird, durchläuft die Testklasse n mal. Dabei werden die Instanzvariablen, hier aInput, bInput, pErwartet, n mal neu abgefüllt.
Die Daten dazu kommen aus der Methode, die mit @Parametrized annotiert ist. Die Magie dabei ist, dass die Methode eine Collection von Object-Arrays zurückgibt, wobei der Object-Array genau den Argumenten des Construktors der JUnit-Testklasse entspricht.
https://gist.github.com/2577376
Testklasse:
So ist es leicht möglich, mal rasch ein paar Tausend JUnit-Tests zu machen... Nur: wer testet die Testdaten?
Der Trick:
Der spezielle JUnit-Runner Parametrized, der mit @RunWith angekickt wird, durchläuft die Testklasse n mal. Dabei werden die Instanzvariablen, hier aInput, bInput, pErwartet, n mal neu abgefüllt.
Die Daten dazu kommen aus der Methode, die mit @Parametrized annotiert ist. Die Magie dabei ist, dass die Methode eine Collection von Object-Arrays zurückgibt, wobei der Object-Array genau den Argumenten des Construktors der JUnit-Testklasse entspricht.
https://gist.github.com/2577376
Testklasse:
So ist es leicht möglich, mal rasch ein paar Tausend JUnit-Tests zu machen... Nur: wer testet die Testdaten?
Update JUnit 4.11
Benamste Parameter:
regex Search-and-Replace in eclipse
funktioniert analog:
n.B.: Groups: $0 bzw. \0 ist Platzhalter für den gesamten Match, $1 ... $n bzw. \1 ... \n für die Groups, die mit (...) definiert werden.
n.B.: Groups: $0 bzw. \0 ist Platzhalter für den gesamten Match, $1 ... $n bzw. \1 ... \n für die Groups, die mit (...) definiert werden.
jEdit regex search-and-replace
zwei Beispiele:
n.B.: Groups: _0 ist Platzhalter für den gesamten Match, _1 ... _n für die Groups, die mit (...) definiert werden.
Siehe auch:
http://www.jedit.org/users-guide/search-replace.html#id491278
und
http://www.jedit.org/users-guide/regexps.html
** Value-Tags machen ***************** Search for: name="(\S*)" Replace with: _0 + "value=\"%%VALUE " + _1 + "%%\" " ** Umwandeln nach Java-Namen ************************ Search for: _(\w) Replace with: _1.toUpperCase()
n.B.: Groups: _0 ist Platzhalter für den gesamten Match, _1 ... _n für die Groups, die mit (...) definiert werden.
Siehe auch:
http://www.jedit.org/users-guide/search-replace.html#id491278
und
http://www.jedit.org/users-guide/regexps.html
Experiment
dieses Blog wird ein Sammeltopf für kleinere und grössere technische Details, die ich irgendwo speichern und veröffentlichen will. Die Veröffentlichungen werden kein System verfolgen, haben keinen Anspruch auf Vollständigkeit und werden völlig zufällig gewählt sein.
jEdit Macro, regex und Zwischenablage
jEdit Macro zum Extrahieren von Attributen aus einem HTML-File und Generieren von Java-Code.
import java.util.regex.Pattern; generateGuiContants (){ StringBuffer outbuff = new StringBuffer(); //String regex = "name=\"(\\S*)\" "; String regex = "%%VALUE (\\S*)%%"; pattern = Pattern.compile(regex); for(int i = 0; i < buffer.getLineCount(); i++){ String line = buffer.getLineText(i); m = pattern.matcher(line); if(m.find()){ outbuff.append("private final static String FLD_").append(m.group(1).toUpperCase()).append(" = \"").append(m.group(1)).append("\";").append('\n'); //outbuff.append("private boolean").append(m.group(1)).append(";").append('\n'); } } //Zwischenablage Registers.setRegister('$',outbuff.toString()); } generateGuiContants ();
Siehe auch:
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
für Regex-Zeugs in Java/Bsh.
Abonnieren
Posts (Atom)