JUnit ist das neue main()

[gman]

Hallo zusammen,

in letzter Zeit haben wieder viele Java-Anfänger Probleme mit der main()-Methode und dem
Aufruf von eigenen (nicht statischen) Methoden gehabt.

Äh, ja. Und wo ist jetzt die Verbindung zum Thread-Titel?

Naja, man könnte den Anfängern ja mal raten den eigenen Code sofort mit JUnit zu testen.
Dann können sie erstmal die eigenen Klassen enwerfen und haben viel mehr Möglichkeiten
den eigenen Code zu testen.
Mir ist halt aufgefallen das bis jetzt noch niemand das aus dieser Richtung gesehen hat, oder
ich habe es nicht mitbekommen

Nachteile der main()-Methode:

- Java-Anfänger haben idR. genug mit OOP und Klassen zu tun, dann muss man sie nicht auch
noch mit diesem komischen static-Kram belästigen
- gerade die Sache mit static führt öfters mal zu komischen Programmen

Vorteile durch JUnit:

- Java-Anfänger können sich erstmal auf ihre Klassen konzentrieren
- Gewöhnen sich sofort an ihren Code zu testen (ich weiß, Wunschvorstellung)

Was haltet ihr von dieser Sichtweise/These/Wasauchimmer

 

[Landei]

Anfänger müssen verstehen, was "static" bedeutet - warum dann nicht bei main anfangen? Ohne "static" zu kennen, bleiben Aufrufe wie System.out.println, System.exit oder Arrays.toString unverständlich und mysteriös, und Dinge wie Enums können nicht einleuchtend erklärt werden. Auf der anderen Seite ist es nun nicht sooo schwer zu erklären, dass manche Sachen eben an der Klasse und nicht an der Instanz hängen.

 

[Noctarius]

Static gehört aber zum Klassen-Kram. Statische Methoden sind Klassenmethoden.
Zu deiner Idee: Bring einem Anfänger mal bei warum er eine Klasse ableiten muss um sie zu starten, bzw was Annotations sind Abgesehen davon muss man JUnit Tests auf Konsole ganz anders starten, dann muss man sich plötzlich schon mit Classpaths rumschlagen und hat noch nicht mal verstanden wie Java funktioniert.

Generell könnte man bestimmt eine Vereinfachung basteln, quasi ein Basisframework zum Starten von Klassen.
[c]java Start HelloWorld[/c]

Damit könnte z.B. automatisch die Klasse HelloWorld.class nachgeladen werden und dann einfach instanziert werden, aber ob ein Konstruktor einfacher ist als eine statische main-Methode. Ich glaube fast nicht.

 

[L-ectron-X]

Was haltet ihr von

..."Wasauchimmer"

 

[maki]

Was haltet ihr von dieser Sichtweise/These/Wasauchimmer

IMHO ist das Problem dass man dann einem Anfänger beibringen muss, eine Jar in den CP aufzunehmen, oder gar gleich noch Mockobjekte zu den Unittests nachlegen müsste, dass wäre etwas viel des guten.

 

[Empire Phoenix]

Frag mal meine mitstudenten ^^
Wir hatten da mal eine Aufgabe mit JUnit, die wir abgeben sollten.
(Und jetzt versuch mal JUnit über die console sauber zu starten)
In meiner not habe ich selber einen kleinen Hack in der main gehabt, der die JUnit sch... selber aufruft.

(Meiner meinung is JUnit ausserhalb von Algorithmen testen fehl am platze, zumal es auf lange Sicht ja doch ncihts bringt vor dem Problem wechzurennen)
Wenn du es ihenen einfacher Machen willst/ motiviren willst würde ich Greenfoot empfehlen dann sehen die wenigstens was. (Ausserdem können sie alle Methoden manuell aufrufen wenn nötig erstmal)

 

[maki]

Frag mal meine mitstudenten ^^
Wir hatten da mal eine Aufgabe mit JUnit, die wir abgeben sollten.
(Und jetzt versuch mal JUnit über die console sauber zu starten)
In meiner not habe ich selber einen kleinen Hack in der main gehabt, der die JUnit sch... selber aufruft.

.. was genau ist denn das Problem mit "JUnit von der Konsole" zu starten?
Classpath setzen?

 

[gman]

Danke für eure Kommentare, ich denke ich muss die Zielgruppe wohl mal anpassen:

Ich meinte eigentlich die Leute die Code ausprobieren wollen und sich dafür ne Klasse mit main()-Methode
anlegen, in der Klasse alle Methoden (statisch natürlich) reinschreiben und wenn alles läuft den Code
nochmal in eine "richtige" Klasse packen.
Oder eine andere Variante: Man hat eine Klasse mit einer main()-Methode und darin werden Methoden
aufgerufen die was bestimmtes Testen und die Tests/Methoden die nicht ausgeführt werden sollen werden
(in der main()-Methode) auskommentiert. So entsteht eine Klasse in der die verschiedensten Sachen
drin stehen von dem das meiste nicht benutzt wird. Ich gebe zu das ich in meiner Anfangszeit sowas
mal gemacht habe und relativ gut fand.

Mein Punkt war jetzt eigentlich nur: Man kann Leute viel besser von JUnit überzeugen wenn man ihnen
zeigt das man seinen Code damit ganz einfach testen kann. Für manche ist es ja eher so das sie es
benutzen "müssen". Der Titel war nur so großkotzig gewählt damit die Resonanz größer wird ;-)

 

[Landei]

Es gibt ja einen Grund, warum viele Leute Test-Frameworks nicht mögen: Sie sind zu starr, unintuitiv und schwer zu lesen. Um die Akzeptanz zu verbessern, muss noch einiges getan werden.

Der folgende Vergleich ist etwas unfair, da in Java die Möglichkeiten für DSLs ziemlich eingeschränkt sind (was sich mit Closures etwas bessern würde), aber ein Test-Framework, das wirklich Spaß macht, würde ich mir ähnlich wie ScalaTest vorstellen:

import org.scalatest.FlatSpec
import org.scalatest.matchers.ShouldMatchers

class StackSpec extends FlatSpec with ShouldMatchers {

  "A Stack" should "pop values in last-in-first-out order" in {
    val stack = new Stack[Int]
    stack.push(1)
    stack.push(2)
    stack.pop() should equal (2)
    stack.pop() should equal (1)
  }

  it should "throw NoSuchElementException if an empty stack is popped" in {
    val emptyStack = new Stack[String]
    evaluating { emptyStack.pop() } should produce [NoSuchElementException]
  }
}

 

[maki]

@gman

Das nennt sich "Learning Tests"

@Landei
Zu sagen dass Java Unittests schwer zu lesen sind und dann Scala als "gutes" Beispiel zu bringen ist irgendwie seltsam

 

[Tomate_Salat]

@Landei
Zu sagen dass Java Unittests schwer zu lesen sind und dann Scala als "gutes" Beispiel zu bringen ist irgendwie seltsam

Das Codebeispiel erinnert mich iwie an AppleScript und es hat beides nichts mit dem Thema zu tun :lol:

 

[Landei]

Entschuldigung, aber wie soll ich ein Beispiel für ein gutes Test-Framework in Java bringen, wenn es (meiner Meinung nach) keins gibt? Das Scala-Beispiel war halt das nächstbeste verfügbare (ich weiß z.B., dass Ruby etwas ganz ähnliches hat, aber da kenne ich mich eben nicht aus). Wenn ihr das nicht lesbarer und bequemer als JUnit mit seinen lustigen Annotations und assertEqualsSonstwies findet, kann ich das natürlich nicht ändern (wobei so ein kurzes Beispiel sowieso nur an der Oberfläche kratzt). Übrigens habe ich von einigen Firmen gehört, die zwar alles in Java programmieren, ihre Tests aber in Scala schreiben - warum wohl?

 

[SlaterB]

ungünstige Vorlage:
weil Scala eine Skriptsprache ist, genauso gut könnte man in Txt/ XML tausende Methodennamen + erwartere Werte auflisten,
das Framework, das das dann ausführt, sieht man nicht, ist besser in anderer Sprache programmiert
Skriptsprache ? Wikipedia

 

[roflno]

ungünstige Vorlage:
weil Scala eine Skriptsprache ist, genauso gut könnte man in Txt/ XML tausende Methodennamen + erwartere Werte auflisten,
das Framework, das das dann ausführt, sieht man nicht, ist besser in anderer Sprache programmiert
Skriptsprache ? Wikipedia

Scala ist keine Skriptsprache.

 

[SlaterB]

sicher sicher, nur die Tendenz und weil es so gut passte (Programm in Java, simple Tests in Scala)

 

[Landei]

weil Scala eine Skriptsprache ist
...
Skriptsprache ? Wikipedia

Dort steht:

Merkmale

Häufig vorhandene Merkmale sind:

* implizit deklarierte Variablen; dazu gehören auch dynamische Funktionsnamen

Nein.

* dynamische Typisierung

Nein.

* automatische Speicherverwaltung, vor allem automatische Speicherbereinigung

Ja, hat Java aber auch

* dynamische Klassenzugehörigkeit oder prototypenbasierte Vererbung

Nein.

* werden in der Regel ohne getrennte Übersetzungsphase ausgeführt (d. h. sie werden interpretiert)

Jain, wie Java auch

Bei einigen Skriptsprachen kann der Programmcode selbst, wie andere Daten auch, manipuliert werden, was die Sprache besonders flexibel macht.

Nein.

Dadurch dass man häufiger wiederholt, dass Scala eine Scriptsprache ist, wird es nicht wahrer.

 

[Tomate_Salat]

Leute, das ist Scala-Thread hier!

Die Posts #9, #10->#17 haben nichts mit dem Thema zu tun (und ob Scala eine Scriptsprache ist oder nicht, hat mal absolut garnichts mit dem Thema hier zu tun!!!). Also back to topic.