Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
How to practice TDD without shooting yourself in the footDennis Doomen
It's 2016, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven't really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks. And even if you believe you are well versed in the testing realm, join me anyway. Maybe we can learn some tips & tricks from the audience as well. Looking forward to it!
Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen.
Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.
How to practice TDD without shooting yourself in the footDennis Doomen
It's 2016, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven't really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks. And even if you believe you are well versed in the testing realm, join me anyway. Maybe we can learn some tips & tricks from the audience as well. Looking forward to it!