Wie sinnvolle unit tests schreiben

Y

yfons123

Gast
Java:
public class Data{
    public int xyz;
    public void resetTo(Data other){
        xyz = other.xyz;
    }  
}
public class DataTest{
    void Test(){
        Data data = new Data();
        data.xyz = 3;
        Data data2 = new Data();
        data2.xyz = 10;
        data.resetTo(data);
        Assert.AreEqual(data.xyz,data2.xyz);
        Assert.AreEqual(data.xyz,10);
    }

}
ich hab jetzt zb das da

mein prof hat gesagt dass lucky tests also tests wo ich weis dass das richtige raus kommt vermeiden sollte

bringt mir der test überhaupt was? ich habe ein paar andere tests geschrieben die in eine ähnliche richtung laufen und auch nur mit daten klassen zu tun haben und da war es jedesmal das gleiche dass die tests genauso fragwürdig waren von der sinnhaftigkeit

ich weis nicht wie ich denken soll wenn ich einen unit test schreiben soll dass es mir auch was bringt

dann stellt sicch noch die Frage was test ich denn überhaupt alles? .. alles?

wie macht man test driven developement? man sollte da glaub icch einen test schreiben bevor man überhaupt die klasse ansich schreibt
aber dann unterstreicht die IDE ja alles rot :D
die methoden gibts ja nicht , ist das so gedacht oder hab ich da was falsch verestanden ?


dann wenn ich die klasse um ein weiteres attribut erweitere dann ist ja der test falsch dh ich muss den nach "justieren" ... aber das vergisst man ja schnell
 
Y

yfons123

Gast
ich werd mal schauen ob ich was finde in der richtung online, ich hab in meinem leben 1 buch gelesen und das hatte 12 seiten 😂
 

Robert Zenz

Top Contributor
mein prof hat gesagt dass lucky tests also tests wo ich weis dass das richtige raus kommt vermeiden sollte
Ich glaube das hast du falsch verstanden. Natuerlich brauchst du auch Tests die den Gut-Fall testen, du brauchst aber auch Tests welche den Negativ-Fall testen.

bringt mir der test überhaupt was?
Ja, getestet wird der Positiv-Fall. Du weiszt also das es funktioniert.

Ich persoenlich mag es die Werte in solchen Tests fix zu haben. Also:

Java:
public class DataTests{
    void testResetTo() {
        Data data = new Data();
        data.xyz = 3;

        Data data2 = new Data();
        data2.xyz = 10;

        data.resetTo(data2);

        Assertions.assertEquals(10, data.xyz);
    }
}

Damit tesest du naemlich nicht direkt dass data.xyz data2.xyz entspricht, sondern die Erwartung dass nach dem Aufruf data.xyz "10" entspricht.

dann stellt sicch noch die Frage was test ich denn überhaupt alles? .. alles?
Gar nicht. Also zunaechst ist eine 100% Testabdeckung meiner Meinung nach reines Zahlenmasturbieren. Was nuetzt es dir fuer Getter und Setter die keine Logik haben zu testen ob diese wirklich die Werte richtig uebernehmen? Nicht viel. Und dann kannst du auch nicht 100% der Moeglichkeiten testen. Ansonsten muesstest du alle moeglichen Werte von int testen mit deinen Tests. Das ist auch etwas sinnbefreit bis unmoeglich bei komplexeren Objekten.

Du musst hier einen bestimmten Zwischenweg gehen und die notwendigen und wahrscheinlichsten Faelle testen. Also zum Beispiel fuer deine Methode:

1. Gut-Fall (Wert wird uebernommen, dein Test oben)
2. other ist null
3. other ist nicht initiliasiert (xyz hat keinen Wert erhalten)

Das war's in dem Fall.

Wenn du jetzt ein if hast, musst du natuerlich einen Test haben fuer wenn die Bedingung zutrifft, und einen fuer wenn nicht. Du musst schon alle Logik-Zweige testen.

wie macht man test driven developement? man sollte da glaub icch einen test schreiben bevor man überhaupt die klasse ansich schreibt
aber dann unterstreicht die IDE ja alles rot :D
die methoden gibts ja nicht , ist das so gedacht oder hab ich da was falsch verestanden ?
Technisch und theoretisch ist dem so, ja. Also die Aussage ist, man schreibt zuerst alle Tests, und implementiert erst dann die Logik. Dadurch hat man quasi die Spezifikation geschrieben und implementiert wirklich nur noch die Logik. In der Praxis ist dies meistens aber nicht moeglich aus dem ein oder anderen Grund. Wenn du die Moeglichkeit hast solltest du etwas implementieren, und dies dann direkt mit einem Test verifizieren, in so vielen Varianten wie moeglich oder sinnhaft. Dazu gehoert auch dass du Fehlerverhalten in einem Test festhaeltst (zum Beispiel wenn der Parameter null ist).

dann wenn ich die klasse um ein weiteres attribut erweitere dann ist ja der test falsch dh ich muss den nach "justieren" ... aber das vergisst man ja schnell
Ja, aber den Test kannst du nur sehr schwer so bauen dass dem nicht der Fall ist. Da waere es dann wichtig dass du einen Ueberblick hast ueber alle Tests (auch weil diese korrekt benannt sind), damit man diese einfach erweitern kann ohne einen zu uebersehen.
 

KonradN

Super-Moderator
Mitarbeiter
Bezüglich TDD kann man sich als Einstieg auch einmal diese zwei Threads ansehen:

Da sieht man dann den Ablauf recht schön.

Ansonsten ist meiner Meinung nach das Standard Werk noch immer von Kent Beck: Test driven development by example.
 

Robert Zenz

Top Contributor
Das in der Praxis, also im Berufsleben, diese, ich sage mal "akademische Meinung" auf die harte Realitaet trifft. Und in der Realitaet gibt es auch Projekte wo der Kunde nicht fuer die Zeit von Tests zahlt, oder man nicht genuegend Zeit hat zum implementieren. Zum Beispiel wenn Feature X in einer Woche fertig sein muss, dann kannst du nicht 4 Arbeitstage damit verschieszen ausufernde und allumfassende Tests zu schreiben, und dich dann hinzustellen und sagen "ja, ich brauche aber noch mindestens 3 Tage fuer das implementieren". Das spielt sich nicht. Eventuell landet man auch in einem Projekt das so gebaut ist dass es extrem schwierig ist Tests zu schreiben, sei es nun aufgrund der Technologie und Sprache oder weil das halt einfach jemand an die Wand gefahren hat. Auch kann es passieren dass man waehrend dem implementieren der Logik erst feststellt dass sich das so gar nicht spielt, oder es einen Denkfehler enthaelt, was beim schreiben der Tests nicht unbedingt auffaellt.

Die Realitaet ist, man muss machen was geht und so das es geht. Und meistens ist "was geht" abgedeckt durch einen Kostenvoranschlag und gedeckelt durch eine Zeitspanne, und daher ist "zuerst Tests vollstaendig schreiben" einfach nicht drinnen. Ein paralleles arbeiten, also Logik schreiben und direkt einen Test dazu, ist meiner Meinung nach etwas das sehr gut funktioniert, auch in der Realitaet.
 
Y

yfons123

Gast
das projekt das es betrifft ist mein spiel und meine javafx bibliothek also gibts keinen nervigen kunden :D
ich bin da ja auch alleine aber vllt in zukufnt nicht mehr

ich werds mal versuchen das parallelisierend durchzuführen erscheint auch logisch
 

KonradN

Super-Moderator
Mitarbeiter
Man muss nur gut aufpassen - Unit Tests verlangsamen nicht wirklich. Ohne Tests schreibst Du die eine Woche Code und hast am Ende zwar was abgeliefert, aber das funktioniert womöglich nicht richtig, ist nicht oder schwer wartbar ... Für ein kleines Feature kann man ggf. mal "schludern", aber das führt sehr schnell zu einem Stand, der jede weitere Bearbeitung extrem verlangsamt wenn nicht gar unmöglich macht.
 

KonradN

Super-Moderator
Mitarbeiter
mir wurde es so gezeigt dass sich unit tests im nachhienein auszahlen aber im "hin hauen" von code zahlen sie sich nicht aus

was ist deine erfahrung mit dem ?
Wenn Du etwas programmierst, dann willst Du es doch auch austesten. Das ist doch auch ganz am Anfang so: Du erstellst das JFrame, packst da irgendwas rein und dann startest Du es immer wieder und klickst in der Applikation rum.

Ich kann mir nicht vorstellen, irgend etwas an Code zu schreiben, zu übersetzen und überhaupt nicht zu testen. Irgend welche Tests wird es also immer geben. Nur wenn Du diese Tests manuell machst, dann kostet das viel Zeit, ist nicht wiederholbar, ...

Also kommen Unit Tests. Es geht nicht darum, 100% Abdeckung zu haben. Es geht auch nicht um TDD. Es geht aber um gewisse Tests. Also das, was Du in #1 etwas zeigst. Dass bei null eine NPE fliegt, das muss ich nicht testen wenn ich entwickle. (Und auch im TDD kommt dieser Test nicht, so dies nicht als ein Feature formuliert wurde.)

Somit ist die Fragestellung: manueller Test vs automatischer Test etwas behandelt.

Wenn man aber nun automatische Tests haben will, dann kann ich mir überlegen: Was kann ich wie testen?
Ich kann eine große Einheit testen. Da muss ich mir aber erst einmal überlegen, was für Testfälle ich brauche. Das ist dann nicht mehr trivial zu überblicken. Da ist dann also das erste Problem, dass ich die notwendigen Testcases nicht sehen kann. (Das führt dann dazu, dass ich deutlich schlechter Änderungen durchführen kann. Ich weiss nicht, ob ich was kaputt mache, da die Tests zu wenig abdecken und zumindest das Vertrauen fehlt!)
Das zweite Problem kommt, wenn ein Fehler auftritt. Das Ergebnis ist nicht das erwartete - dann such mal! Du hast jetzt ein komplexes Gebilde und gehst dann mit dem Debugger ran oder wertest Logs aus. Das ist - so wie manuelle Tests - weggeschmissene Zeit. Diese Zeit ist einfach verbrannt ohne wirkliches Ergebnis.

Daher kann ich nur sagen: Ganz ohne Unit-Tests würde ich nie entwickeln wollen. Aber ich habe auch schon zu oft Code vorgesetzt bekommen, der keine Tests hatte und war auch schon oft genug in der Situation, dass ich dem Management sagen musste: Toll, was da von irgendwem gebaut wurde - aber das gehört eigentlich nur in die Tonne. (Wobei da nicht nur fehlende Unit Tests der Grund war. Da waren dann auch noch andere Dinge ganz daneben. Aber alles gehört mit in das große Feld "Clean Code" - viele Ignorieren da dann gleich alles. (Disposable Pattern war da z.B. ein Thema. Als C# Entwickler wirst du das hoffentlich auch kennen, auch wenn Unity da wohl andere Wege gegangen ist... )
 

mihe7

Top Contributor
ich werds mal versuchen das parallelisierend durchzuführen erscheint auch logisch
Je nachdem, wie man es sieht :)

Zuerst muss man festhalten, dass immer getestet wird. Du schreibt Code, führst ihn aus und schaust, ob er tut, was er tun soll. Dann nimmst Du Änderungen vor, führst den Code aus und schaust wieder, ob er tut, was er tun soll.

Das funktioniert natürlich, wird mit der Zeit aber immer aufwendiger und früher oder später bekommst Du auch das Problem, dass Code nicht nur lokal Auswirkungen hat. Das überblickst Du aber nicht mehr, was Du alles testen müsstest.

Da sowieso getestet wird und jeder Test mehrfach durchgeführt wird, bietet es sich doch an, den Vorgang zu automatisieren.

Jetzt ist die Frage, wann man wofür einen Test schreiben soll.

Das Wann ist eine Art Glaubensfrage. Grundsätzlich ist es aber so, dass Du im Vorfeld schon weißt, was Du implementieren willst. Insofern spricht nichts dagegen, zuerst den Test zu schreiben. Das hat einen entscheidenden Vorteil: Du machst Dir auf einer ganz anderen Ebene Gedanken. Zumindest stelle ich das bei mir fest.

Wenn ich zuerst die Implementierung schreibe, bin ich auf den "happy path" fokussiert. Klar, Erfahrung macht klug und natürlich mache ich mir automatisch schon weitere Gedanken. Trotzdem reichen die meist nicht so weit, wie wenn ich mich im Vorfeld um den Test kümmere. Man nimmt einfach eine andere Perspektive ein, das ist schwer zu beschreiben. Wenn ich dagegen im Anschluss einen Test schreibe, bin ich a) von meiner Implementierung beeinflusst und b) ist der Code in der Regel schon getestet, so dass das Schreiben des Tests eher zu einer langweiligen Pflichtübung wird. Nebenbei, der Punkt a) dürfte das sein, was Dein Prof. meinte: Du weißt, wie Dein Code funktioniert und schreibst entsprechende Tests, die das bestätigen.

Hinzu kommt noch etwas ganz anderes: Code, den man vor dem Test schreibt, tendiert dazu, nicht aufs Testen ausgelegt zu sein. Das verkompliziert ggf. das Schreiben eines Tests.

Kommen wir zum Was: auch hier lässt sich trefflich diskutieren. Wer Getter/Setter testet, hat m. E. schon verloren, dann bist Du nur noch am Tests schreiben und ändern. Wir beschränken uns in der Regel auf die reine Funktionalität/Logik. Selbstverständlich könnte man noch vieles mehr automatisieren, aber da muss man dann auch das Verhältnis vom Nutzen zum Aufwand im Auge behalten.
 

Robert Zenz

Top Contributor
An dieser Stelle muss ich mal kurz klarstellen weil ich glaube wir mischen hier gerade in der Diskussion: Ich sprach immer von "automatisierten" Tests. Also wirklich Tests die man dann alle automatisiert ausfuehren kann, die klassischen Unit Tests zum Beispiel.

Das es Tests geben muss, ist hoffentlich allen klar, auch wenn diese "nur manuell" in der Test-Umgebung sind. Testen muss man die Sache natuerlich immer, aber den "Luxus" von Unit-Tests, oder umfangreichen automatischen Tests, hat man nicht immer (und kann man nicht immer haben). Die "manuellen" Tests gibt es meiner Erfahrung nach immer, egal ob man Unit-Tests geschrieben hat oder nicht, daher kommen Projekte auch ohne automatisierte Tests durch.
 

KonradN

Super-Moderator
Mitarbeiter
was meinst du damit ?

dass ich bei einem input stream zb

habe?

also falls das gemeint war da hat unity ein eigenes system, da es scriptable objects gibt also objekte die vorbereitet da liegen somit man sich nicht auf input streams verlassen muss
Ja genau, das ist ein Teil davon. Das Problem kann sein, dass dein Managed Code auch Unmanaged Elemente enthält. Diese müssen freigegeben werden. Aber wenn close nicht aufgerufen wird, dann wird es nicht freigegeben. Prinzipiell kommt dann noch der Destruktor ins spiel, der dann auch unmanaged Ressourcen noch freigeben könnte, aber das kann problembehaftet sein.

So hatten wir schon Applikationen, bei denen es Memory Leaks gab.
 
Y

yfons123

Gast
Ja genau, das ist ein Teil davon. Das Problem kann sein, dass dein Managed Code auch Unmanaged Elemente enthält. Diese müssen freigegeben werden. Aber wenn close nicht aufgerufen wird, dann wird es nicht freigegeben. Prinzipiell kommt dann noch der Destruktor ins spiel, der dann auch unmanaged Ressourcen noch freigeben könnte, aber das kann problembehaftet sein.

So hatten wir schon Applikationen, bei denen es Memory Leaks gab.
achso


das übernimmt unitys serialisoerung durch die Vorbereitung von Objekten

da kann man sich nicht so dämlich anstellen 😜
 

KonradN

Super-Moderator
Mitarbeiter
Wie kommt es dann des öfteren vor dass einfach gar nix in der Richtung gemacht wird?
Das bezieht sich jetzt wieder auf die Unit Tests? Aus meiner Sicht kommt das einfach durch Uneinsichtigkeit und zu geringe Übung.

Wenn Du keine Übung hast, Unit Tests zu schreiben, dann brauchst Du länger. Dann brauchst Du mehr Zeit. Wenn noch viel schlimmer: Du schreibst Code, der gar nicht testbar ist! (Daher mein Tipp: Beschäftige Dich mit TDD - musst Du nicht anwenden später, aber dann lernst Du, Code so zu schreiben, dass er testbar ist)

Und das Problem hat die Wirtschaft dann auch regelmäßig: Produkte sind nicht oder nur sehr schwer wartbar.
 
Y

yfons123

Gast
Beschäftige Dich mit TDD - musst Du nicht anwenden später, a
wie soll ich das jetzt wieder vesrtehen :D
wieso lernen wenn ich es dann nicht anwende?

ich habe im moment bei meinem spiel nur logik also UI ist erstmal ausseen vor
da ich halt in der arbeit viel mmit powershell gemacht hab und sich das vorgehen als gut erwiesen hat dass ich ansich zuerst eine pure konsolen anwendung baue
die die einzelnen methoden aufruft und dann noch eine GUI drauf pflanze im nachhinein

da ich keinerlei ahnung von unit tests in powershell hab hab ich es da auch nicht gemacht

aber in unity ist das ziemlich enifach geregelt und schön automatiesiert mit git pushes zusätzlich
da msus ich mich um nix kümmern also dachte ich halt ich probiers mal aus

ich könnte in 1er stunde mal das aktuelle bringen da ich die ganze zeit in der uni bin und das projekt auf meinem pc hab ( .. internet war gestern tod :( )

da das beispiel eine abgespeckte version von dem was ich wirklcih habe vllt könnte man da nochmal ausholen auf die "sinnhaftigkeit"
 

LimDul

Top Contributor
wie soll ich das jetzt wieder vesrtehen :D
wieso lernen wenn ich es dann nicht anwende?
TDD ist eine Vorgehen, dass die hilft bessere Tests zu schreiben. Das heißt es hilft immens ein Verständnis aufzubauen, wie man testbare APIs baut, wie man einen Schnitt von Methoden und Objekten macht, so dass man hinterher Tests schreiben kann.

Deswegen muss man später nicht TDD anwenden - aber testbare APIs sollte man trotzdem schreiben
 

KonradN

Super-Moderator
Mitarbeiter
wie soll ich das jetzt wieder vesrtehen :D
wieso lernen wenn ich es dann nicht anwende?
Das Problem ist, dass Du keine Erfahrung mit Unit Tests hast. Wenn Du jetzt Deinen Code testen sollst, dann testest Du Code, der dafür nie gedacht war. Du brichst Dir also dabei einen ab.

Wenn Du aber nun Test First vorgehst, dann schreibst Du nur Code, der (einfach!!) testbar ist. Klar, der Test existiert ja auch schon!

Die Idee ist also, jetzt zu erkennen, wie Code bei TDD aussieht. Dann kannst Du den auch ohne "Test First" direkt so schreiben. Und schon sind Unit Tests trivial und schnell zu schreiben.

Man könnte auch reine "Best Practices" erstellen und sagen: Da nimm und friss. Du kriegst also Regeln, wie Dein Code aussehen soll und wie nicht. Das geht auch. Das ist wie in der Hundeerziehung eine einfache Prägung. Aber du wirst nicht verstehen, wieso etwas so ist, wie es ist.
Und was soll ich mich mit Dir rumschlagen? Was soll ich Dir Leckerli geben, wenn Du Code so geschrieben hast, wie ich es gut finde? Was soll ich Dich bestrafen, wenn Du es anders machst? Du kannst es selbst ausprobieren und dann schreibst Du evtl. Code so, weil es Dir so besser gefällt. Damit Dir der Code auf eine bestimmte Art und Weise gefällt, musst Du aber geprägt werden. Leckerli / Bestrafung. Und das hast Du (hoffentlich) selbst beim ausprobieren: Leckerlie ist: Heya, ist der Unit Test schnell fertig. Bestrafung iszt das "Ich bin schon 30 min am Code und der Test steht immer noch nicht."

In der Realität ist es leider so, dass viele Entwickler TDD nicht praktizieren. Es gibt viele Vorurteile gegenüber Tests. Wir hatten hier schon viele Diskussionen bei denen dann teilweise selbst erfahrene Entwickler meinten: Unit Tests brauche ich nicht.

Ich sage es regelmäßig: Ich bin nur einer, der nachplappert. Ich habe mir Clean Code nicht ausgedacht und ich bin nicht der Messias oder so. Ich habe aber Erfahrungen gesammelt und da war meine Bewertung eindeutig. Also kann ich nur sagen: Dieses und jenes sagen Andere (Uncle Bob, Kent Beck, ...) und du kannst es auch mal ausprobieren ... wenn Du dann Erfahrungen gesammelt hast, kannst DU sagen, wie Du es siehst. Bilde Dir Deine Meinung!
 
Y

yfons123

Gast
(Uncle Bob, Kent Beck, ...)
als psaß nebenbei erinnert mich an berry böhm der vieles in software engineering gemacht hat und eig jedes mal verkackt hat :D

Wenn Du jetzt Deinen Code testen sollst, dann testest Du Code, der dafür nie gedacht war. Du brichst Dir also dabei einen ab.
mein erstes spiel ist fertig, das spiel wird noch den weg zum papierkorb gehen und sonst nichts mehr :D

das aktuelle projekt was ich jetzt mache und bis jetzt 3 klassen hat und 3 tests die auch dafür zumindest verscuht waren geschrieben zu werden
ist halt aktuell die aufgabe

das erste projekt war halt "erstmal in die scheiße rein reiten udn dann mal umschauen wies so ausschaut" also ich muss ja erstmal sehen warum dieses und jenes blöd ist

da hab ich auch ganz dämliche sachen gemacht die ich mir nochmal angekuckt hab... zb keine generics benutzt wo welche hin hätten sollen.. usw usw

testbarkeit hatte ich auch nichts, gering halten von scripts zb hatte ich 6 enums die zusammen gehören udn die hab ich jetzt in eine klasse gepackt die die enums hatte eg

Attribute.Nature
oder
Attribute.Environment
oder
Attribute.Type
ja ich weis man könnte sie in den gleichen namespace packen, aber mal schauen vllt stellt sich namespace als besser raus... manchmal muss man erst auf die fresse fliegen :D
 
Y

yfons123

Gast
C#:
 public class EntityDataTest
    {
        // A Test behaves as an ordinary method
        [Test]
        public void EntityDataTestSimplePasses()
        {
            Assert.False(EqualsOnNull());
            Assert.False(EqualsOnNonEquality());
            Assert.True(EqualsOnEquality());
            Assert.True(EqualsAfterResetTo());
            Assert.True(EqualValuesAfterResetTo());
        }

        private bool EqualValuesAfterResetTo()
        {
            var data1 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 101234,
                Breakthrough = 101515,
                Armor = 120123,
                Health = 400135,
                Nature = Attribute.Nature.BEAST
            };
            var data2 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            data1.ResetTo(data2);

            Assert.AreEqual(data1.Attack, 10);
            Assert.AreEqual(data1.Environment, Attribute.Environment.MOUNTAIN);
            Assert.AreEqual(data1.Breakthrough, 10);
            Assert.AreEqual(data1.Armor, 120);
            Assert.AreEqual(data1.Health, 400);
            Assert.AreEqual(data1.Nature, Attribute.Nature.GOBLIN);
            return data1.Environment == data2.Environment
                   && data1.Attack == data2.Attack
                   && data1.Breakthrough == data2.Breakthrough
                   && data1.Armor == data2.Armor
                   && data1.Health == data2.Health;
        }

        private bool EqualsOnEquality()
        {
            var data1 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            var data2 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            return data1.Equals(data2);
        }

        private bool EqualsAfterResetTo()
        {
            var data1 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            var data2 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10234,
                Breakthrough = 1054,
                Armor = 1,
                Health = 12,
                Nature = Attribute.Nature.HUMAN
            };
            data1.ResetTo(data2);

            return data1.Equals(data2);
        }

        private bool EqualsOnNonEquality()
        {
            var data1 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            var data2 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10234,
                Breakthrough = 1054,
                Armor = 1,
                Health = 12,
                Nature = Attribute.Nature.HUMAN
            };
            return data1.Equals(data2);
        }

        private bool EqualsOnNull()
        {
            var data1 = new EntityData
            {
                Environment = Attribute.Environment.MOUNTAIN,
                Attack = 10,
                Breakthrough = 10,
                Armor = 120,
                Health = 400,
                Nature = Attribute.Nature.GOBLIN
            };
            return data1.Equals(null);
        }
    }
C#:
    [System.Serializable]
    public class EntityData : CoreData<EntityData>
    {
        [field: SerializeField] public Attribute.Nature Nature { get; set; }
        [field: SerializeField] public int Attack { get; set; }
        [field: SerializeField] public int Breakthrough { get; set; }
        [field: SerializeField] public int Armor { get; set; }
        [field: SerializeField] public int Health { get; set; }


        public override void ResetTo(EntityData data)
        {
            base.ResetTo(data);
            Attack = data.Attack;
            Breakthrough = data.Breakthrough;
            Armor = data.Armor;
            Health = data.Health;
            Nature = data.Nature;
        }

        public bool Equals(EntityData other) =>
            base.Equals(other)
            && Attack == other.Attack
            && Breakthrough == other.Breakthrough
            && Armor == other.Armor
            && Health == other.Health;
    }
das wäre der test den ich gestern geschrieben hatte mit meinem ersten versuch test code zu schreiben, vllt wird die sinnhaftigkeit da genauer gezeigt warum ich die hinterfrag

hab sogar noch den fall vergessen wenn alle werte == 0 sind dann muss der test ausgeben dass es invalide daten sind
 

Robert Zenz

Top Contributor
Fuer gewoehnlich hat man die Tests auch als einzelne Tests, und nicht als Aufrufe in einem Test.

Java:
public class LogicTests {
    @Test
    public void testDoAction() { /* ... */ }
    
    @Test
    public void testDoActionWithNullParameter() { /* ... */ }
    
    @Test
    public void testDoActionWithFaultyParameter() { /* ... */ }
    
    @Test
    public void testDoSomethingDifferent() { /* ... */ }
    
    @Test
    public void testDoSomethingDifferentWithParameterA() { /* ... */ }
    
    @Test
    public void testDoSomethingDifferentWithParameterB() { /* ... */ }
}

Das hat zum einen den Vorteil dass die Tests alle schoen strukturiert sind, und zum anderen erwartet *jedes* Tool so einen Aufbau.
 
Y

yfons123

Gast
werd ich machen ,ergibt sinn

EDIT:
also untiy erkennt es dann auch so, mal gucken wie das dann bei javaffx aussieht


Unbenannt.PNG
 
Zuletzt bearbeitet von einem Moderator:

Hansen_07

Bekanntes Mitglied
Zum Thema TDD wurde ja schon allerhand hier geschrieben. Vielleicht kann ich dennoch noch das ein oder andere anmerken.

Mir hat am Anfang sehr geholfen dem Begriff Test weniger Bedeutung beizumessen als dem Driven Design. Natürlich geht es beim TDD auch ums testen aber meinem Verständnis nach, ist TDD eher einer Methodik oder ein Paradigma, Software zu entwerfen (Clean Code Prinzipien). Natürlich mit dem super "Effekt", am Ende automatisierte Tests für die Software zu haben. Nebenbei dokumentieren dieses Tests auch sehr genau, was die Anforderungen an eine Unit (Methode, Klasse) sind. Tests bilden quasi die Spezifikation der verschiedenen Anwendungsbestandteile.

Bücher sind nicht so ganz dein Ding, habe ich hier raus gelesen. Dennoch würde ich gerne ein paar Titel in den Raum werfen.. vielleicht ist ja ein passender Schreiber für dich dabei?

Kent Beck - Test driven development by example (wurde ja auch schon genannt)
Tomek Kaczanowski - Practical Unit Testing und bad Tests good Tests

Interessanten Lesestoff online gibt es auch z.b. hier http://codemanship.co.uk/ (ein guter Start wäre vielleicht: TDD) oder auch hier Continuous Delivery. Für absolute Lesemuffel bieten die beiden letztgenannten auch sehr interessante Kanäle auf Youtube an.

Du erwähntest auch noch javafx. Um User Interaktionen zu testen, gibt es http://testfx.github.io/TestFX/. Das muss wohl sowas wie Selenium sein, nur eben für jafafx (habe ich allerdings selber gar nichts mit am Hut bisher).

Was ich bei mir festgestellt habe: nicht nur coden muss man üben sondern eben auch das Testen bzw. TDD. Da gibt es nette Kata Seiten, von denen man z.b. täglich eine Aufgabe per TDD lösen kann, einfach um in diese Art des Denkens und Methodik reinzukommen. Hat (und tut es noch immer) mir enorm geholfen. Beispielhaft diese zwei Seiten: https://codingdojo.org/kata/, https://ccd-school.de/coding-dojo/.

Vielleicht war da jetzt ja noch was brauchbares für dich dabei.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
Z MVC Pattern - sinnvolle Integration Allgemeine Java-Themen 6
V Sinnvolle "Lernreihenfolge" Allgemeine Java-Themen 2
H Frage sinnvolle Datenspeicherung und -verarbeitung Allgemeine Java-Themen 3
J Sinnvolle Dateigroesse fuer PDAS-Transfer Allgemeine Java-Themen 2
G Daten von Excel kopieren - sinnvolle Datenstruktur? Allgemeine Java-Themen 3
W Checkliste Unit Test Allgemeine Java-Themen 17
Y Wieso krieg ich die Unit Tests nicht hin Allgemeine Java-Themen 55
sascha-sphw Erste Schritte Unit und Integration-Tests im Java Modul System Allgemeine Java-Themen 10
B Frage zu Unit-Tests Allgemeine Java-Themen 6
J Alle Unit Tests in Maven Modul Projekt ausführen Allgemeine Java-Themen 7
looparda Unit Test - Abgänigkeit zur Datenbank isolieren Allgemeine Java-Themen 3
R Unit Test Allgemeine Java-Themen 1
M Für was schreibt man Unit-Tests? Allgemeine Java-Themen 55
P J-Unit vergleich von 2 Objekten merkwürdig Allgemeine Java-Themen 7
G ThreadLocal in Muster "Unit of Work" Allgemeine Java-Themen 7
K Unit Test consolen ein-/ausgaben. Allgemeine Java-Themen 7
M Html Unit Whitespace-Problem Allgemeine Java-Themen 4
fastjack Unit-Testen mit Mocks Allgemeine Java-Themen 6
Jay_030 Guice: Frage im Umgang mit Unit-Tests Allgemeine Java-Themen 4
B FileWriter / FileReader testen / Mock-Objekt für Unit Tests? Allgemeine Java-Themen 6
S Unit Testing mit JMock Allgemeine Java-Themen 11
alexpetri unit tests für pdfs Allgemeine Java-Themen 4
B J-Unit Tests. Alle Tests eines Package einsammen. Allgemeine Java-Themen 4
tfa Unit-Tests für private Methoden Allgemeine Java-Themen 25
W Unit Tests im "Hauptprojekt" oder in Modulen Allgemeine Java-Themen 3
M Eine Frage über Unit-Tests mit Java Allgemeine Java-Themen 2
N Ausgaben (System.out) umlenken und in Unit-Tests überprüfen? Allgemeine Java-Themen 2
Zrebna Wieso sind eigentlich JUnit-Tests in src/test/java platziert - nur Konvention? Allgemeine Java-Themen 7
Robert Zenz Ich brauche bitte mal kurz einen Sanity/Reality-Check betreffend Tests. Allgemeine Java-Themen 9
harrytut Java Input/Output Tests Junit Allgemeine Java-Themen 3
M mockito Tests Allgemeine Java-Themen 9
P No JUnit tests found Allgemeine Java-Themen 5
hello_autumn Statistische/dynamische Tests Allgemeine Java-Themen 10
S Parametrisierte jUnit 5-Tests mit eigenen Datentypen/Klassen-Objekten als Test-Parameter Allgemeine Java-Themen 0
AssELAss Junit-Tests für SQL-Veribindung sowie SQL-Queries? Allgemeine Java-Themen 3
M Selenium JUnit Tests (Auswahl von Testmethoden auswerten) Allgemeine Java-Themen 5
A Performance/Speicherplatz-Nutzung bei Tests Allgemeine Java-Themen 6
M Junit Tests durchführen Allgemeine Java-Themen 18
M JUnit Tests vs. DBUnit Tests Allgemeine Java-Themen 3
J JUnit-Tests Zeichensatzproblem ? Allgemeine Java-Themen 2
F Tests mit dynamischem Datum Allgemeine Java-Themen 2
T Junit-Tests in Java Klasse ausführen Allgemeine Java-Themen 26
C JUnit Tests Allgemeine Java-Themen 4
A Seltsames Verhalten von JUnit-Tests im Zusammenspiel mit Ant Allgemeine Java-Themen 6
G JUnit Tests Allgemeine Java-Themen 7
S JUnit Tests für GUI / Oberflächen Allgemeine Java-Themen 2
M JUnit und dynamische Tests Allgemeine Java-Themen 11
K JUnit: Tests über ant aufrufen Allgemeine Java-Themen 2
D Tests für Java Allgemeine Java-Themen 3

Ähnliche Java Themen

Neue Themen


Oben