Java Programm fuer Bewerbung



  • Hallo,

    ich muss ein Java Programm fuer ein Bewerbungsgespraech schreiben. Hab die Aufgabe uebers Wochenende von der Firma bekommen.

    Ich soll das Spiel Schere, Stein, Papier umsetzen. So nun meine Fragen.

    1. Wuerdet ihr Konsole oder Grafik machen ? ( steht nicht dabei)
    2. Der Code soll hohe Testabdeckung vorweisen. Was bedeutet das ?
    3. Herangehensweise: Testgetrieben ( Was bedeutet das)
    4. Test in einer JVM Sprache deiner Wahl
    5. Ich soll local GIT verwenden. Was heisst das. Git das in Eclipse
    intregriert (EGit) ist oder normal Git ?
    (initial ein 'git init' im Projekt Verzeichnis, so dass wir ein bisschen
    deiner Arbeitsmethoden sehen)



  • 1. Wenn nichts von GUI steht, dann in der Konsole. GUI ist für Programmierkenntnisse unbedeutend.
    2. Du sollst Testcode schreiben, der den Spiele-Algorithmus prüfen soll. Man muss dafür keine Frameworks benutzen, aber es ist gängig dafür JUnit zu benutzen.
    3. Schau mal nach Test Driven Development (TDD).
    4. Die meinen, das es nicht unbedingt in Java gemacht werden muss, kann auch in z.B. Scala, JRuby oder so sein. Fang keine Experimente an, mach es in Java, das du ja kannst.
    5. Du sollst dein Spielprojekt in ein lokales GIT-Repository auf deiner Festplatte entwickeln. Also nicht bei Sourceforge oder Github. 😉 Und sie wollen sehen, wann du Kommits machst. Wenn du das nur einmal machst, wenn das Spiel und Testcode fertig ist, dürfte das der schlechteste Fall sein. 😃 Dann musst du denen das lokale Repository zur Verfügung stellen.



  • Bis auf "testgetrieben" versteh ich das meiste. Anhand meiner commits sehen die wahrscheinlich ob ich testgetrieben entwickelt habe oder.
    Ich schreib zuerst die Tests und dann das Programm. Richtig ?
    Was den Algorithmus angeht ob Stein,Schere oder Papier ausgewaehlt wird, reicht es da schon wenn man ein randomize(3) verwendet.
    Oder welchen Algorithmus erwarten die da wohl ?



  • Also mit Algorithmus ist die Spiellogik gemeint. Das was das eigentliche Spiel ausmacht. Random kannst du aus der Standard-Library benutzen. Das musst du nicht testen (hat schon SUN/Oracle für dich gemacht) und nicht implementieren (Wiederverwendung ist vorbildlich).

    Es geht um den Spiele-Algo, also Spiele-Logik. Grob gesagt: alles was nicht Tastatur-Abfrage und Bild-Ausgabe ist, bleibt irgendwo der Spiele-Algorithmus übrig, den du ja implementieren und testbar haben musst.

    Du siehst also worauf es hinausläuft: fange die Unit-Tests an, die den Spiele-Algo testen und den du dann implementieren musst. Der Spiele-Algo ist dann eine testbare Einheit (modular), ohne Interaktion des Spielers.

    Wenn du den Algo fertig hast, machst du die Konsolen-Ausgaben und -Eingaben, die das Modul benutzen. Die Interaktion mit dem SPieler musst du nicht testen, das wäre eine andere Test-Abdeckung und ist auch für die Aufgabe blödsinnig.
    Fertig ist das Spiel.

    Wenn du erst mit den Konsolen-In&Output anfängst, wird es sehr schwierig testbaren code zu schreiben.

    Und an den Kommits wird man es natürlich sehen.



  • Artchi schrieb:

    1. Wenn nichts von GUI steht, dann in der Konsole. GUI ist für Programmierkenntnisse unbedeutend.

    Das Auge guckt mit.
    Ne GUI kann man erwarten, da ein guter Progger so etwas schnell runtertippen kann.
    Nimm aber nicht Swing, wie im anderen Thread empfohlen, sondern gleich JavaFX. Das ist wesentlich moderner als der alte Müll.

    4. Die meinen, das es nicht unbedingt in Java gemacht werden muss, kann auch in z.B. Scala, JRuby oder so sein. Fang keine Experimente an, mach es in Java, das du ja kannst.

    JVM steht für Java Virtual Machine. Das darf also kein Scala, JRuby und Co sein, sondern das bedeutet nur, dass man eine JVM seiner Wahl nehmen kann.
    Also z.b. die Originale von Oracle oder auch z.b. die OpenJVM oder eine ganz andere JVM, z.b. von IBM oder so.
    Eventuell dürfte auch die JVM von Android darunter fallen.



  • ich hab mir gerade JUnit runtergeladen und ins plugin Verzeichnis von eclipse gelegt. Aber wenn ich es einbinden will erkennt er es nicht. Nur wenn ich es uber external classpath mache gehts.

    Wo legt man die jars die man z.B. aus dem Internet downloaded am besten ab. Ich hab mir jetzt mal im Projekt selber einen libs folder angelegt und dort die junit.jar rein



  • Testgetrieben bedeutet in etwa. Ich mach mir vom Algorithmus ein Grundgeruest. Also Methoden mit Signatur in einer Klasse X. Dann leg ich mir nen separaten Test folder an und legt dort eine Klasse Tests an. Dort binde ich die Klasse X ein und schreibe fuer die Methoden die Tests. Natuerlich kann man die Tests erst ausfuehren wenn die Klasse X fertig ist.



  • computernerds schrieb:

    1. Wuerdet ihr Konsole oder Grafik machen ? ( steht nicht dabei)

    Ohne VR und KI geht heute gar nichts, brauchst gar nicht erst probieren.



  • computernerds schrieb:

    ich hab mir gerade JUnit runtergeladen und ins plugin Verzeichnis von eclipse gelegt. Aber wenn ich es einbinden will erkennt er es nicht. Nur wenn ich es uber external classpath mache gehts.

    Wo legt man die jars die man z.B. aus dem Internet downloaded am besten ab. Ich hab mir jetzt mal im Projekt selber einen libs folder angelegt und dort die junit.jar rein

    Ich hasse Eclipse*, aber ich denke auch Eclipse kann sich automatisch über eine pom.xml das JUnit von Maven Central ziehen.

    --> https://mvnrepository.com/artifact/junit/junit/4.8.1

    <!-- https://mvnrepository.com/artifact/junit/junit -->
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.8.1</version>
        <scope>test</scope>
    </dependency>
    

    *)Nomen es omen: Sonnenfinsternis!



  • Bei der Frage ob man Stein, Schere oder Papier auswaehlt , hat sich der Iocaine Powder Algorithmus bewaehrt. Hab mir grad den Code in Git angeschaut.
    Er hat 300 Zeilen .
    Ist ein machine learning algorithmus. Ich weiss leider nicht was die Firma da genau erwartet. Ich persoelich haette ja nur ein einfaches random(3) gemacht. Haha.



  • Die verlangen von mir "High Test Coverage" bei dem Spiel.

    Das einzige was mir zum Testen einfaellt ist meine Funktion whoWins. Der uebergeb ich die Wahl des Spielers also Stein, Papier oder Schere und die liefert mir den Gewinner zurueck.
    Da der Computer immer Stein auswaehlen soll, sind in meiner Testklasse genau 3 Testfunktionen. Ich weiss wirklich nicht was die mit "High Test Coverage" meinen. Hm...
    Ausserdem kann man ja nur Funktionen testen die Parameter entgegennehmen. Das ist ja auch wieder so eine Sache..



  • computernerds schrieb:

    Die verlangen von mir "High Test Coverage" bei dem Spiel.

    Das einzige was mir zum Testen einfaellt ist meine Funktion whoWins. Der uebergeb ich die Wahl des Spielers also Stein, Papier oder Schere und die liefert mir den Gewinner zurueck. Da der Computer immer Stein auswaehlen soll, sind in meiner Testklasse genau 3 Testfunktionen. Ich weiss wirklich nicht was die mit "High Test Coverage" meinen. Hm...

    Dass du möglichst viele deiner Funktionen testest, vor allem im Grenzbereich.
    Eine Funktion die einen String als Argument bekommt, sollte z.B umgehen können mit:

    - leeren Strings
    - Nullpointern
    - Strings der Länge 1
    - Übergroßen Strings
    - Strings mit falscher Codierung (z.B. UTF-16 statt UTF-8)

    ^^ jetzt haste schon 5 Testfunktionen für eine Funktion die nur einen String haben will. 🙂



  • computernerds schrieb:

    Bis auf "testgetrieben" versteh ich das meiste. Anhand meiner commits sehen die wahrscheinlich ob ich testgetrieben entwickelt habe oder.
    Ich schreib zuerst die Tests und dann das Programm. Richtig ?

    Nicht ganz:
    - Ja, Tests werden vor Code geschrieben
    - Nein, nicht alle Tests werden geschrieben bevor man das Programm anfangt umzusetzen.

    Vereinfacht:
    1. TDD setzt auf den sogenannten Red-Green-Refactor-Zyklus. Man schreibt einen Test (Dieser sollte "rot" ergeben, da der Code noch nicht existiert bzw. ausreicht), dann soviel Code das dieser erfüllt wird (anschließend sollte der Test "grün" ergeben) und räumt nach jeden Schritt auf (sofern nötig). Dieser "Mikroschritt" wird solange wiederholt bis der Code das macht was er soll.
    2. Üblicherweise sollte ein Test niemals Implementierungsdetails kennen, Abhängigkeiten sind soweit zu isolieren das sie den Test nicht behindern (z.B. extrahieren eines Zufallszahlengenerators um diesen im Test mit Routinen austauschen zu können, die eine feste Zahl liefern - damit du das Ergebnis auch sinnvoll testen kannst und nicht vom Zufall abhängig bist).



  • so ich hab heute eine Rueckmeldung bzgl meinem Programmcode erhalten.
    Sie beschweren sich unter anderem dass meine Controller Klasse ueberhaupt nicht durch Testcode abgedeckt ist. Ich hab ehrlich gesagt null Ahnung wie ich das in JUnit Tests testen sollte.

    Hier meine Controller Klasse:

    package application;
    
    import java.io.File;
    import java.io.IOException;
    import application.Model.Result;
    import application.Model.Selection;
    import javafx.event.ActionEvent;
    import javafx.fxml.FXML;
    import javafx.scene.control.Label;
    import javafx.scene.image.Image;
    import javafx.scene.image.ImageView;
    
    public class Controller {
    
    	int scorePlayer, scoreComputer, scoreDraw;
    	Image imgRock, imgPaper, imgScissors;
    	Model model;
    
    	@FXML
    	Label lblScorePlayer;
    
    	@FXML
    	Label lblScoreComputer;
    
    	@FXML
    	Label lblScoreDraw;
    
    	@FXML
    	ImageView imgPlayer;
    
    	@FXML
    	ImageView imgComputer;
    
    	public Controller() throws IOException {
    		this.scorePlayer = 0;
    		this.scoreComputer = 0;
    		this.scoreDraw = 0;
    
    		model = new Model();
    
    		File fileRock = new File("img/rock.jpg");
    		imgRock = new Image(fileRock.toURI().toString());
    
    		File filePaper = new File("img/paper.jpg");
    		imgPaper = new Image(filePaper.toURI().toString());
    
    		File fileScissors = new File("img/scissors.jpg");
    		imgScissors = new Image(fileScissors.toURI().toString());
    	}
    
    	@FXML
            //Hier der Button Klick fuer die UI
    	private void startClicked(ActionEvent event) throws InterruptedException {
    
    		this.playGame();
    	}
    
    	public void playGame() {
    		for (int i = 0; i < 100; i++) {
    
    			this.imgComputer.setImage(this.imgRock);
    
    			Selection choicePlayer = model.selectShape();
    
    			switch (choicePlayer) {
    			case ROCK:
    				this.imgPlayer.setImage(this.imgRock);
    				break;
    			case PAPER:
    				this.imgPlayer.setImage(this.imgPaper);
    				break;
    			case SCISSORS:
    				this.imgPlayer.setImage(this.imgScissors);
    				break;
    			}
    
    			Result result = model.whoWins(choicePlayer);
    
    			switch (result) {
    			case WIN:
    				scorePlayer++;
    				break;
    			case LOSE:
    				scoreComputer++;
    				break;
    			case DRAW:
    				scoreDraw++;
    				break;
    			}
    
    		}
    
    		scorePlayer = 0;
    		scoreComputer = 0;
    		scoreDraw = 0;
    	}
    
    }
    

    Zudem kritisiert er die vielen Switch Statements , die haette er gerne mehr objektorientiert. Weiss meint er wohl damit.
    In dem Buch Clean Code wird ja auch erwaehnt dass man wenn moeglich keine switch verwenden sollte.

    Wie koennte man das z.B. objektorientiert formulieren.

    switch (result) {
    			case WIN:
    				scorePlayer++;
    				break;
    			case LOSE:
    				scoreComputer++;
    				break;
    			case DRAW:
    				scoreDraw++;
    				break;
    			}
    

Anmelden zum Antworten