JUnit für JFileChooser

[bob_sheknowdas]

Hi,
ich habe eine Methode die einen JFileChooser nutzt und möchte dafür gerne einen jUNit test schreiben.
Ich hab allerdings keine Idee wie ich den manuellen JFileChooser im Test automatisiert bedienen kann.
Hier mal besagte Methode (chooser ist der JFileChooser):

public static int readFileAndReturnErrorCode() {
		chooser.showOpenDialog(null);
		File file = chooser.getSelectedFile();
		int errorCode = ErrorCodes.Filechoosing_Was_Aborted;
		if (file != null) {
			try {
				errorCode = FileValidator.validateAndReturnErrorCode(file);
				if (errorCode == ErrorCodes.No_Error) {
					readFile(file);
				}
			} catch (IOException e) {
				e.printStackTrace();
				errorCode = ErrorCodes.Exception_While_File_Readed;
			}
		}
		return errorCode;
	}

 

[eRaaaa]

Die Frage ist, ob der JFileChooser da überhaupt etwas zu suchen hat. Die Hauptaufgabe der Methode ist doch eine ganz andere oder? Was ist beispielsweise wenn du die Methode ohne GUI nutzen möchtest?
Ich würde eher die Abhängigkeiten der Methode übergeben, in diesem Fall also ein File-Objekt? Dann ist deine Methode auch testbar, das Testen des Filechooser ist nicht erforderlich, das haben (hoffentlich) andere übernommen

 

[bob_sheknowdas]

Die Frage ist, ob der JFileChooser da überhaupt etwas zu suchen hat. Die Hauptaufgabe der Methode ist doch eine ganz andere oder? Was ist beispielsweise wenn du die Methode ohne GUI nutzen möchtest?
Ich würde eher die Abhängigkeiten der Methode übergeben, in diesem Fall also ein File-Objekt? Dann ist deine Methode auch testbar, das Testen des Filechooser ist nicht erforderlich, das haben (hoffentlich) andere übernommen

Wenn ich JUnit richtig verstanden habe ist doch das Ziel jede public-Methode zu testen.
Das bedeutet egal ob ich den JFileChooser nun in dieser Methode oder in einer anderen erzeuge, früher oder später wird er im Test aufgerufen.
Die Frage ist wie ich damit umgehen kann...

 

[eRaaaa]

Wenn ich JUnit richtig verstanden habe ist doch das Ziel jede public-Methode zu testen.
Das bedeutet egal ob ich den JFileChooser nun in dieser Methode oder in einer anderen erzeuge, früher oder später wird er im Test aufgerufen.

Wer sagt denn dass man den FileChooser überhaupt in einer public-Methode aufruft?

Die Frage ist wie ich damit umgehen kann...

Wenn du mich fragst gar nicht, die Methode ist nicht testbar und der Chooser gehört für mich da nicht rein. Dass du deine Methode/Aufgabe mit JUnit nicht testen kannst, zeigt ja eig. schon dass hier irgend etwas nicht passt, ich würde der Methode ein File-Objekt übergeben und dann ist das auch mit einem JUnit Fall testbar, sauberer getrennt und vor allem für die Zukunft auch evtl. anderweitig einsetzbar (Konsolenprogramm, Server, etc.)

 

[bob_sheknowdas]

Wer sagt denn dass man den FileChooser überhaupt in einer public-Methode aufruft?

Wenn du mich fragst gar nicht, die Methode ist nicht testbar und der Chooser gehört für mich da nicht rein. Dass du deine Methode/Aufgabe mit JUnit nicht testen kannst, zeigt ja eig. schon dass hier irgend etwas nicht passt, ich würde der Methode ein File-Objekt übergeben und dann ist das auch mit einem JUnit Fall testbar, sauberer getrennt und vor allem für die Zukunft auch evtl. anderweitig einsetzbar (Konsolenprogramm, Server, etc.)

Hmm...
Ok, ich poste hier mal die gesammte Klasse. Vllt kannst du mir helfen die so umzustrukturieren, dass die Funktionalität erhalten bleibt und ich JUnit-Tests aufrufen kann.
Ich habe nämlich wirklich keine Idee wie das aussehen könnte... :bahnhof:

public abstract class FileLoader {

	private static FileReader fileReader;
	private static BufferedReader bufferedReader;
	private static JFileChooser chooser = new JFileChooser();
	private static int[][] cells = null;

	public static int readFileAndReturnErrorCode() {
		chooser.showOpenDialog(null);
		File file = chooser.getSelectedFile();
		int errorCode = ErrorCodes.Filechoosing_Was_Aborted;
		if (file != null) {
			try {
				errorCode = FileValidator.validateAndReturnErrorCode(file);
				if (errorCode == ErrorCodes.No_Error) {
					readFile(file);
				}
			} catch (IOException e) {
				e.printStackTrace();
				errorCode = ErrorCodes.Exception_While_File_Readed;
			}
		}
		return errorCode;
	}

	private static void readFile(File file) throws IOException {
		int lineNumber = countLines(file);
		fileReader = new FileReader(file);
		bufferedReader = new BufferedReader(fileReader);
		String line = bufferedReader.readLine();
		int charactersPerLine = line.length();
		cells = new int[lineNumber][charactersPerLine];
		for (int currentLineNumber = 0; currentLineNumber < lineNumber; currentLineNumber++) {
			for (int currentCharNumber = 0; currentCharNumber < charactersPerLine; currentCharNumber++) {
				char currentChar = line.charAt(currentCharNumber);
				cells[currentLineNumber][currentCharNumber] = Character
						.getNumericValue(currentChar);
			}
			line = bufferedReader.readLine();
		}
		bufferedReader.close();
	}

	private static int countLines(File file) throws IOException {
		fileReader = new FileReader(file);
		bufferedReader = new BufferedReader(fileReader);
		String line = bufferedReader.readLine();
		int lineNumber = 0;
		while (line != null) {
			lineNumber++;
			line = bufferedReader.readLine();
		}
		return lineNumber;
	}

	public static int[][] getCells() {
		return cells;
	}
}

 

[eRaaaa]

Zeilen 5,9 und 10 löschen und

public static int readFileAndReturnErrorCode(File file)

verwenden?
In einem Testfall kannst du jetzt einmal die Methode mit einem korrekten File-Objekt aufrufen (oder mehrere Testfälle mit unterschiedlichen Fileobjekte, je nachdem was deine Methoden da eig. machen) und einmal mit null, was simulieren würde dass der User den "Abbrechen" Button klicken würde im FileChooser.

 

[bob_sheknowdas]

Ich glaube ich versteh langsam worauf du hinaus willst und werd das erstmal so umsetzen.
Ich denke aber das verscheibt das Problem nur. Denn so kann ich zwar diese Methode testen, habe aber in meiner GUI-Klasse dann Methoden mit dem FileChooser, die nicht testbar sind...