Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.java > #13017

Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle

Show key headers only | View raw

Responding to Wanja Gayk:
> In article <nlp8pd$js5$1@newsreader4.netcologne.de>, Patrick Roemer 
> (sangamon@netcologne.de) says...
>> 
>> Responding to Wanja Gayk:
> 
>> > Manchmal programmiert man ohne klares Ziel, weil das noch nicht in Sicht 
>> > ist und man sich langsam voran tastet, bzw. baut man wärend der 
>> > Implementation sehr oft noch sehr viel um, refactored eine Menge und man 
>> > will dafür nicht immer die Tests komplett umbauen, weil sich die API 
>> > ändert (weil man auf halbem Wege merkt, dass sie doch nicht so elegant 
>> > war, wie man dachte und einem was besseres einfällt). 
>> 
>> Aber wie merkt man das denn ohne Tests (oder sonstigen Code der mit dem
>> API arbeitet)? :)
> 
> Nicht jede Methode ist Teil einer öffentlichen API, sondern das meiste 
> Zeug ist private (bzw. package private) oder Teil einer groben Idee.

Package private ist ja schon wieder API für andere Klassen im selben
Package.

> List<Something> getSomethings(){...}
[...]
> <T extends Collection<? super Something>> T getSomethings(T target){...}

List<Something> getSomethings() {
  return getSomethings(new ArrayList<>());
}

Inlinen, und alle bestehenden Aufrufer sind zufrieden.

> <T extends Collection<? super Something>> T getSomethings(T target){
>  return getSomethings(target, Function.identity());
> }
> <U, T extends Collection<? super U>> T getSomethingsFunction<? super 
> Something, U> mapper, T target){...}

Und hier ändert sich dank des Overloads für bestehende Aufrufer eh nichts.

> Und der Code oben wird zu:
> Set<OtherThings> otherThings = getSomethings(myClass::toOtherThing, new 
> HashSet<OtherThings>());
> 
> Hätte ich diese Entwicklung "test first" geschrieben, also mit allen 
> Corner cases, hätte ich jeden der Tests für diese Methode (und das kann 
> ein ganzer Batzen sein) zweimal umschreiben müssen.

Von test-first mit allen corner cases war ja eh nicht die Rede. Aber
wenn ich irgendwann Testcases hierfür geschrieben habe, dann, weil ich
mir aus irgendeinem Grund speziell über diese Methode Gedanken gemacht
habe. Ganz so trivial wird die dann nicht sein; dann schadet es nichts,
wenn es weiterhin Aufrufer gibt, die die neue Version durchexerzieren,
wenn auch nicht in allen möglichen Variationen. Tests dafür kann ich
hinzufügen, wenn und wann ich es für nötig halte, oder eben nicht. Das
Abschreckungspotential des "Umschreibens" halte ich in diesem konkreten
Beispiel jedenfalls für überschaubar.

> Meine Entwicklung sieht in der Regel so aus:
> 1.Hack
> 2.Refine
> do{
>  3.Write Test
>  4.Fix Bugs
> }while (bugs detected || tests incomplete)

Ich finde, dass das Schreiben von Tests beim "Refine" ungemein hilfreich
sein kann.

> Mit anderen Worten wird erstmal explorativ 
> drauflos gehackt und geschaut, wie sich das verhält und ob man das so 
> nehmen kann, oder ob was anderes besser wäre, etc. und der einzige 
> "Test" bis dahin hat die Qualität einer hingerotzen Main-Methode, nur um 
> das Zeug auf dem höchsten Level auszulösen. Keine Corner cases, etc.
> Und wenn ich dann ein Gefühl dafür habe, wohin die Reise geht, was ich 
> will und dass die Idee, die ich da ausformuliert habe gut ist, sodass 
> jetzt der Feinschliff kommen kann, dann fange ich an top down die Tests 
> zu schreiben, um a) die API zu fixieren, b) vergessene corner cases zu 
> entdecken und c) sicher zu gehen, dass ein späterer Bugfix kein anderes, 
> erwartetes Verhalten bricht.

Das impliziert irgendwie, dass Corner Cases keinen Einfluss auf das
Design haben. Und wenn ich Code dafür schreibe, will ich den auch
irgendwie triggern.

Wenn ich mit einer main anfange, sammelt sich da peu a peu aller
möglicher auskommentierter und toter Code von Variationen dieses
High-Level-Szenarios an. Da spendiere ich lieber noch ein paar
Assertions und packe die Varianten in Testcases.

> Ich war 
> überrascht, dass der Abschnitt von Minute 15 bis Minute 28 "Spike and 
> Stabilize" meiner Art Software zu entwickeln sehr nahe kommt:
> https://www.youtube.com/watch?v=USc-yLHXNUg

Have you written lots and lots of TDD code? ;)

Was er im Prinzip sagt, ist doch: Wenn (und nur wenn!) man hinreichend
viel konsequent mit agilen Prozessen gearbeitet hat, weiss man ja,
worauf es ankommt. Dann kann man die Regeln ruhig Regeln sein lassen
(das wichtige davon hat man ja eh internalisiert), den Code hinballern
und hinterher aufräumen. Das mag für ihn und für Dich funktionieren,
aber das als Entwicklungsprozess zu verticken, finde ich schon mutig.
Und mir fehlt da eben der Aspekt des Test-Driven *Design*.

Viele Grüße,
Patrick

Back to de.comp.lang.java | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-07 21:19 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Peter <peter@localhost.com> - 2016-07-07 22:37 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Michael Paap <feunews@mpaap.de> - 2016-07-07 23:21 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:09 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:10 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:17 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-18 00:33 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-18 01:01 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-19 10:58 +0200
            Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-21 00:07 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 14:09 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-08 00:28 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:13 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 16:05 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:35 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:01 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 00:40 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:25 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 00:12 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 21:57 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 01:13 +0200

csiph-web