Agile Software Development In Practice
Upcoming SlideShare
Loading in...5

Agile Software Development In Practice



These are the slides to my "Agile Software Development in Practice" lectures. They are intended especially for Software Development students but have also partially been used in inhouse Clean Code ...

These are the slides to my "Agile Software Development in Practice" lectures. They are intended especially for Software Development students but have also partially been used in inhouse Clean Code developer trainings.

The following topics are covered:
* most aspects of Agile Methodology from Pair Programming to Collective Code Ownership
* Clean Code based on Robert C. Martins work
* Test Driven Development
* advanced Unit Testing techniques like Mockito mocks and Hamcrest matchers

The deck is divided into 9 lectures which each consist of a theoretical part and a practical excercise for the students. Included are building a Mars Station from building blocks (using agile methods and SCRUM roles), Uncle Bobs famous Bowling Game Code Kata and a smallscale Code Retreat.

Accompanying source code and examples can be found on



Total Views
Views on SlideShare
Embed Views



8 Embeds 575 329 138 51 35 10 7 4 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Agile Software Development In Practice Agile Software Development In Practice Presentation Transcript

  • Agile Software Development in Practice v1.34 (10.09.2014) Björn KimminichörnKimminich
  • Björn Kimminich 2007+ Software Architect & Security Officer at Kuehne+Nagel Corporate Web Development 2011+ Part-time lector for Java & Agile Software Develoment at private UAS Nordakademie 2012+ Committer OWASP Zed Attack Proxy & Group Lead zaproxy-test sub- project
  • Lecture 1 Organizational Stuff Agile Software Development
  • Organizational Stuff Schedule •9 lectures •2/3 head-on presentation •1/3 excercises and demos Behavior •No other work/“work“ done during lectures •Questions & discussion immediately on topic •Breaks on demand 
  • Agenda I •Right & Duties •The Agile Manifesto •Agile Techniques •Scrum Agile Software Development •Building a Mars Station Excercise
  • Agenda II •Motivation •Names •Functions •Comments •Formatting Clean Code •Writing a clean Trading Card Game from scratch Excercise
  • Agenda III •Unit Tests •Junit 4 •Test Driven Development (TDD) •BDD Test Style •Matchers •Mocking Testing •Adding advanced rules to the Trading Card Game Excercises
  • Agenda IV •Code Kata Bowling Game •Code Retreat Game of Life Advanced Excercises
  • Icon Legend Goal Tool Quote
  • Source Code Examples
  • Agile Software Development Introduction
  • Targets of efficient Software Development Source:
  • Why classic devlopment methods often fail… Source:
  • Agile Software Development Agile Software Development takes into account the short innovation cycle Quick customer feedback Open discussion Integration of the customer into the project Lean and adaptable development process Early visible and deployable results Embrace the change
  • Rights and Duties – Customer Rights •Define release content •Receive agreed scope •Change requirements Duties •Express the requirements •Define acceptance criteria
  • Rights and Duties – Developer Rights •Independent effort estimation •Risk estimation •Define release scope Duties •Adhere to release plan •Adhere to quality criteria
  • Source:
  • Agile Development Techniques Iterative Process User Stories Transparent Estimation Process Test Driven Development Regression Tests Pair Programming Collective Code Ownership Continuous Integration Refactoring
  • Iterative Process An Iteration should not take longer than 2-4 weeks Each Iteration delivers new functionality with business value In each Iteration a fixed set of User Stories is defined and implemented The customer approves/declines all User Stories at the end of each Iteration The result of several Iterations will be deployed as a (production) Release Release 1 Release 2 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Iteration 7
  • User Stories Functionality that generates business value Brief description Estimated by developers Unit of Work
  • Task Board I
  • Task Board II Source:
  • Planning Poker I Consensus based estimation method Define estimation reference Pre-defined estimation values 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? 1.Discuss User Story 2.Hidden estimation 3.Reveal all estimations 4.Discuss outliers 5.Hidden re-vote
  • Planning Poker II Source:
  • Test Driven Development 1.Write a failing test 2.Write the (smallest) amount of code to pass the test 3.Refactor You are not allowed to write any production code unless it is to make a failing unit test pass You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
  • Regression Tests Test Suites contain all class Unit Tests Suites should be executed After every finished development task After every Refactoring Before committing into Version Control System At the end of the day all tests must pass Other types of automated tests (Integration, UI, …) should also be bundled into Test Suites
  • Pair Programming Two developers program on one computer One active programmer One observer reviewing each line of code considering the strategic direction of the task Roles are switched regularly Pairs are changed regularly Benefits Increased Software Quality Knowledge Management
  • Collective Code Ownership Abandons any notion of individual ownership of modules (“my code” vs. “your code”) Code base is owned by the entire team Anyone may make changes anywhere Common style guide and coding standard
  • Continuous Integration Build Server continuously checks out sourcecode from version control system Builds software and runs tests and static code analysis as often as possible Nightly Several times per day Every 15 min After every commit Feedback via eMail, RSS, IM, Monitor
  • Refactoring Disciplined technique for restructuring existing code Alters internal structure without changing external behavior Series of small behavior preserving transformations Sequence of small transformations can produce a significant restructuring System is kept fully working after each small refactoring
  • Scrum Source:
  • Scrum Roles Product owner responsible for the business value of the project ScrumMaster ensures that the team is functional and productive Team self-organizes to get the work done Source:
  • Scrum Ceremonies Sprint planning the team meets with the product owner to choose a set of work to deliver during a sprint Daily scrum the team meets each day to share struggles and progress Sprint reviews the team demonstrates to the product owner what it has completed during the sprint Sprint retrospectives the team looks for ways to improve the product and the process. Source:
  • Daily Scrum Source:
  • Sprint Retrospective Source:
  • Scrum Artifacts Product backlog ordered list of ideas for the product Sprint backlog set of work from the product backlog that the team agrees to complete in a sprint, broken into tasks Product Increment required result of every sprint. It is an integrated version of the product, kept at high enough quality to be shippable. Source:
  • Excercise 1 Building a Mars Station
  • Goal Build a Mars Station model with DDR building blocks using Agile Development techniques Iterative Process User Stories Product Backlog Transparent Estimation Sprint Backlog Pair Programming Collective Code Ownership Refactoring Product Increment Sprint Review Sprint Retrospective
  • Roles 1x Co-Founder & CTO Mars Tech Inc® 3x Product Owner 2x Scrum Master 6x Team nx Keen observers
  • Project Timeline Sprint 0 Preparation Release 1 Sprint 1 Sprint 2 (Sprint 3) Deployment of Mars Station Release 1 on the Red Planet
  • Sprint 0 CTO Mars Tech Inc® shares Vision of the project with the team Project is staffed Product Owner defines first set of User Stories from the overall Mars Station vison Team gets familiar with the Development Environment and defines an Estimation Reference
  • User Story Examples I As an astrophysicist I want a deep space observatory So that I can study the stars. As a communications engineer I want a radio tower So that I can stay in contact with the company’s personnel on Earth.
  • User Story Examples II As a CEO I want a luxurious apartment So that I have the same comfort on Mars that I have on Earth when visiting the station. As a security officer I want a security station in every sector So that I can better fend off invading demons if need be.
  • Sprint 1-3 Sprint Planning (15min) PO presents new User Stories Team estimates effort Team defines Sprint Backlog Sprint (15min) Team implements User Stories PO refines Product Backlog Sprint Review & Retrospective (10min) Team presents Product Increment to PO Team reflects on last Sprint and adjusts process
  • Clean Code Lectures 2-4 Source: Martin, R.C. (2008). Clean Code. Prentice Hall
  • Lecture 2 Motivation Names
  • Motivation Does Clean Code matter?!
  • Do you know this man?
  • Who is „Uncle Bob“? I’ve been a programmer for 42 years; and in that time—let me tell you—I’ve seen it all I’ve been fired. I’ve been lauded. I’ve been a team leader, a manager, a grunt, and even a CEO I’ve worked with brilliant programmers and I’ve worked with slugs I’ve programmed in COBOL, FORTRAN, BAL, PDP- 8, PDP-11, C, C++, Java, Ruby, Smalltalk, and a plethora of other languages and systems [Uncle Bob, The Clean Coder]
  • Mandatory Literature for Software Craftsmen Clean Code Robert C. Martin, 2008 The Clean Coder Robert C. Martin, 2011 Code-casts for Software Professionals
  • Measuring Code Quality Source:
  • The Architecture Analogy I Design Document Realization
  • The Architecture Analogy II Design Document Realization
  • Bad Code Wading through code Meet deadline now, clean up later Increasing slowdown over time Better a running mess than nothing Broken Window metaphor Lack of „Code-Sense“
  • The Grand Redesign I When the mess in the system gets overwhelming…
  • The Grand Redesign II …the development team will demand a „Grand Redesign“ of the system.
  • The Grand Redesign III The best and brightest developers will form a new „Tiger Team“…
  • The Grand Redesign IV …which endeavours to redesign the system as a new and shiny green field project.
  • The Grand Redesign V Unfortunately the „Tiger Team“ must wade through the old systems code to understand the requirements for the new system…
  • The Grand Redesign VI …while rest of the developers have to keep maintaining and add new features to the old system…
  • The Grand Redesign VII …forcing the Tiger Team to keep up with the old system‘s changes while building the new system from scratch.
  • The Grand Redesign VIII Years pass with this race going on. The original Tiger Team members have long quit on their employer…
  • The Grand Redesign IX …and the current members demand a redesign because the new system has become such a mess!
  • Who‘s to blame for Bad Code? Unclear Requirements Last-minute Change Requests Tight Project Schedules Stupid Managers Intolerant Customers
  • Who‘s to blame for Bad Code? Unclear Requirements Last-minute Change Requests Tight Project Schedules Stupid Managers Intolerant Customers We Programmers!
  • What is Clean Code? Can be read and enhanced by a developer other than its original author Has unit and acceptance tests Does one thing well Looks like it was written by someone who cares Never obscures the designer‘s intent Each routine you read turns out to be pretty much what you expected Reads like well written prose Provides a clear and minimal API Elegant & efficient Bjarne Stroustrup Ward Cunningham Michael Feathers Grady Booch
  • XP Simplicity Rules (by Kent Beck, Ron Jeffries Source:
  • Broken Window Theory
  • The Boy Scout Rule "Try and leave this world a little better than you found it." (Robert Stephenson Smyth Baden-Powell) "Always leave the campground cleaner than you found it." (The Boy Scout Rule) "Always check a module in cleaner than when you checked it out.”
  • A famous quote… You are not only responsible for what you do, but also for what you don’t do. [Laotse, 600B.C.]
  • Would you send an Email like this to your boss?
  • The Email Metaphor Committing code into a Version Control System is like sending an email to your boss… …with all your co-developers as CC recipients! Get it right before hitting or
  • Clean Code == Self Confidence++
  • Clean Code in a Nutshell WE CARE FOR OUR CODE Other developers can read understand maintain the code we write Changed and added code is safeguarded by Tests We clean up Legacy Code whenever we can The whole team is responsible for the whole code
  • What is Legacy Code? Legacy code. The phrase strikes disgust in the hearts of programmers. It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal. Although our first joy of programming may have been intense, the misery of dealing with legacy code is often sufficient to extinguish that flame [Uncle Bob, Working Effectively with Legacy Code] To me, legacy code is simply code without tests [Michael Feathers, Working Effectively with Legacy Code]
  • Dealing with our own Legacy Code Gradually clean up Legacy Code you are working on Include efforts for the following preliminary tasks into your project estimations Cleaning up existing code Creating Unit Tests Not breaking existing functionality is paramount A little cleanup is better than none at all
  • Let‘s wrap up the „Motivation“…
  • Names
  • Don‘t be just smart In general programmers are pretty smart people One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king Professionals use their power for good and write code that others can understand [Uncle Bob, Clean Code]
  • Another famous quote… With great power comes great responsibility [Uncle Ben, Spiderman]
  • Reveal your Intent Any Variable/Method/Class name should tell Why it exists What it does How it is used If you need a comment to explain the name, the name is probably ill chosen
  • Intent Guessing Exercise
  • What might these classes do?
  • Meaningful Names Source:
  • No Disinformation Do not leave false clues Do not obscure the meaning of code Entrenched vs. intended meaning Inconsistent spelling
  • Entrenched vs. intended meaning
  • No Language Mashups
  • Pronouncable Names class BaseDxoProcessMilestone7600LstBo class Dx2FltrShipmentCustPartyXDto class GyqfaChBppResDao class SegmentG041Data class KnlobiLocation class SwotService
  • l0O1 should be avoided
  • No Encodings No member prefixes int m_price; // member variable int g_count; // global variable int s_total; // static member … No Hungarian Notation boolean bBusy; boolean fBusy; //flag int cApples; // count of items float fpPrice; // floating point Student[] rgStudents; // range …
  • No Unnecessary Context
  • Interface vs. IInterface No „I“ in front of Interface names Sometimes encoding is necessary to avoid name clash with implementation class ShapeFactory implements IShapeFactory class ShapeFactoryImpl implements ShapeFactory class DefaultShapeFactory implements ShapeFactory
  • Consistent Lexicon Pick one word per concept findSomething() findsearchSomethingElse() findgetSomethingCompletelyDifferent() findlookOutForPirateShipsOnTheHorizon() findkeepAnEyeOutForAnythingElseSuspicious() Avoid using the same word for two purposes void addElement(List list, Object element) void addRestriction(List rules, Restriction rule) String concatenateaddStrings(String s1, String s2) void appendaddWord(String sentence, String word)
  • The Scope Rule Methods Methods that are called from far and wide should have short evocative names Methods in small scopes should have long and precise names You should not have to read the body of a method to know what it does - its name should tell you The more complex the behavior of a method, the more generic its name, and the more sub methods should be extracted from it
  • Long Method Scope = Short Name Component service interface  Public API  Long Scope create(NetsurveyRunDts netsurveyRun) updateContentEncoding(String encoding, Long netsurveyRunId)
  • Short Method Scope = Long Name
  • The Scope Rule Variables/Parameters Local variables of a short method or small block can have short names Global variables should have long and self- explaining names
  • Long Variable Scope = Long Name BTW: A class with 1755 LOC is a hideously long scope…
  • Short Variable Scope = Short Name Short names are allowed in a short scope… …which doesn‘t mean that long descriptive names are discouraged for a short scope! One-letter names can be tolerated for Counter variables of simple for loops Exception instances in catch blocks for (Cell c : gameBoard) would also be okay in this scope!
  • The Scope Rule Summary Methods Long scope = Short name Short scope = Long name Variables Long scope = Long name (Short scope = Short name)
  • Excercise 2
  • Ongoing Excercise Topic: Trading Card Game Problem domain should be new for most Starting clean on a „green field project“ Pair Programming is mandatory Use TDD only if both partners are used to it! Proven to work well in different languages Did it myself in Java, Groovy and Javascript
  • The Problem Domain A […] trading card game (TCG) […] is a card game that uses specially designed sets of playing cards […] mass-produced for trading or collectibility, and it must have rules for strategic game play. Acquiring these cards may be done by trading with other players or buying card packs. Source:
  • TCG Rules Visual explanation of the rules Complete textual rules description Click here if you like it… …or here if you don’t!
  • TCG Rules Preparation (I) Each player starts the game with 30 Health 0 Mana slots Each player starts with a deck of 20 Damage cards with the following Mana costs From the deck each player receives 3 random cards has his initial hand Source: 30 0/0 0 0 1 2 2 2 3 3 3 4 4 4 5 6 6 7 8 1 3 5 ? ? ?
  • TCG Rules Preparation (II) One player is randomly chosen to be the starting active player The other player draws a 4th card from his deck to compensate him for not playing the first turn Source: ? ? ? ? ? ? ? p=0,5
  • 1.The active player receives 1 Mana slot up to a maximum of 10 total slots 2.The active player's empty Mana slots are refilled ?/11 TCG Rules Basic Gameplay (I) Source: ?/0 ?/1 ?/2 ?/10 … ?/1 1/1 ?/2 2/2 ?/10 10/10 …
  • TCG Rules Basic Gameplay (II) 3.The active player draws a random card from his deck 4.The active player can play as many cards as he can afford. Any played card empties Mana slots and deals immediate damage to the opponent player equal to its Mana cost. Source: 29 -x x = ?
  • TCG Rules Basic Gameplay (III) 5.If the opponent player's Health drops to or below zero the active player wins the game 6.If the active player can't (by either having no cards left in his hand or lacking sufficient Mana to pay for any hand card) or simply doesn't want to play another card, the opponent player becomes active Source: 0 -1 …
  • 1 2 3 TCG Rules Special Rules Bleeding Out: If a player's card deck is empty before the game is over he receives 1 damage instead of drawing a card when it's his turn Overload: If a player draws a card that lets his hand size become >5 that card is discarded instead of being put into his hand Dud Card: The 0 Mana cards can be played for free but don't do any damage either. They are just annoyingly taking up space in your hand Source: 29 -1 0 4 5 6
  • Trading Card Game – Part 1 Create a two-player hotseat „TCG“ Concentrate on game logic, not on fancy GUI Do not implement any of the Advanced Variations Choose meaningful and adequate names for …packages …classes …methods …variables Only Pair Programming!
  • Lecture 3 Functions
  • Functions
  • Size Matters I
  • Size Matters II
  • Bjoern‘s Mousewheel Check™ If I have to scroll down to see the end of a method… …it‘s too long! If a single spin on my mouse wheel is not enough to see the end of a method… …it‘s far too long!! If I have to switch my mouse wheel from precision into speed mode and still can‘t reach the end of a method in one spin… …it‘s beyond fing hope!!!
  • Function Size Functions should be small Functions should hardly ever be >20 lines Blocks within if/else/while etc. should be 1 line Indentation level in a function should be 1-2 Small size makes sure a function is… …easily readable …easily understandable …doing only one thing!
  • Function Indentati n Level of 14 o
  • What‘s wrong with this method? It does not do one thing! It should be two methods! findSupplierByCipId(Long id) findSupplierBySctId(Long id)
  • Single Responsibility Principle Source:
  • SRP Violation at its best…
  • Side Effects Side effects are lies!!! A function that promises to do a thing should not do other hidden things
  • Command Query Separation A Function can do one of below but not both Change the state of an object Return some information about an object Asking a question should not change the answer!
  • Law of Demeter I A method should only call methods of its own class methods of its parameters methods of associated classes methods of objects created by itself
  • Law of Demeter II
  • Law of Demeter III For pure data structures LoD does not apply int leftMargin = config.layout.margins.left; List<Orderline> orderlines = this.getCustomer().getLatestOrder().getLines()
  • Compose Method Divide your program into methods that perform one identifiable task Keep all of the operations in a method at the same level of abstraction This will naturally result in programs with many small methods, each a few lines long Refactoring Use Extract Method refactorings… …until the rules above are met Original Method has become a Compose Method
  • What does this method do?
  • Legibility boost after Compose Method refactoring
  • Compose Methods are change friendly New!
  • Limitations of Compose Method Methods with many parameters local variables are hard to refactor into Compose Methods Sub-methods have too many parameters as well Code of sub-methods would not read well
  • Method Object Create a new class Add an instance variable for each local variable and each parameter of the original method plus the original receiver (if used) Add one method compute() whose body is the body of the original method Replace the original method with one that creates an instance of the new class, constructed with the parameters and receiver of the original method, and invokes compute() Refactor the new class
  • Demo Method Object Compose Method
  • Arguments  No input arguments  One input argument  Two input arguments  Three input arguments  Four or more input arguments  Boolean input arguments = obvious violation of SRP!  Enumeration input arguments = even more obvious SRP violation!!!
  • This should rarely happen…
  • …and this should never happen!
  • Parameter Object Replace a long parameter lists with a single object or structure Parameter Object has data members representing the original arguments to be passed in multiple constructors for different use cases
  • Output Arguments Harder to understand than input arguments Unexpected function behavior Input = Arguments Output = Return Value Often cause readers to do a double-take
  • Can you spot a Problem here?
  • Assigning method parameters is bad practice Intention is entirely unclear to the reader Param became obsolete at some point in time? Assignment was an accident? How to prevent this? Put final in front of every method parameter..? No Parameter Assignment
  • Final on Method Parameters I
  • Final on Method Parameters II Pro Con What about runtime optimizations on the pro side? Might be valid for embedded systems. In general, runtime optimization is not an issue!
  • Using Checkstyle over final Checkstyle „Parameter Assignment“ Check
  • Final on Local Variables I
  • Final on Local Variables II Pro Con But, for runtime optimization it might… No, it might not!
  • The Final Dillemma In Clean Code, final… …only hurts legibility a little bit …but is seldom needed to prevent bugs In Bad Code, final… …might help prevent some bugs …but severely hurts legibility
  • As a team agree on a common approach to either use or not use final in the code you own! In the long run you‘re probably better of agreeing not to use final! Final Conclusion
  • Specific Bean >> Generic Tuple Avoid generic tuple classes (Pair, Triple, …) in favor of use-case specific data structures
  • Collections & Maps
  • Wrapper Classes Wraps an unintuitive structure into an adapter class with a clear and expressive API
  • Error Handling Use Exceptions over error codes Can be handled immediately or be delegated Error handling separated from the „happy path“ Exceptions should be exceptional Use unchecked Exceptions for aborting errors Use Special Case Pattern for non-aborting error situations
  • Do not work with null Returning null from a method is bad! Instead… …return empty collection …consider throwing an Exception …consider using Special Case Pattern Passing null into methods is even worse! Code becomes cluttered with null checks Development team cannot trust its own code
  • Special Case Pattern = A subclass that provides special behavior for particular cases. Useful for… …non-aborting error situations …whenever it might be tempting to return null …other slight deviations from a default handling Customer MissingCustomer UnknownCustomer GlobalCustomer
  • Excercise 3
  • Trading Card Game – Part 2 Add a single player vs. computer game mode to your TCG The bot should play smart but doesn‘t have to be an AI Only Pair Programming but with different pairs than last time! One of each previous pair stays, the other will rotate to another partner!
  • Lecture 4 Comments Formatting
  • Comments
  • Comments I Comments are, at best, a necessary evil The proper use of comments is to compensate our failure to express ourself in code Inaccurate comments are far worse than no comments at all [Uncle Bob, Clean Code]
  • Comments II Comment bad code Clean up bad code Delete bad comments /*Highlighting*/ comments in Eclipse makes them easier to spot and remove if appropriate
  • HTML in Javadoc I Uncle Bob considers HTML in Javadoc a bad comment because he likes to have it readable in the code… …and there the HTML tags are quite ugly
  • HTML in Javadoc II On the other hand… …Eclipse has a Javadoc View …exported and frequently read Javadoc from Frameworks or Libraries should probably use HTML formatting
  • Good Comments Legal Comments Public API Javadoc Informative Comments Explanation of Intent Clarification Warning of Consequences TODO Comments
  • Legal Comments
  • Public API Javadoc
  • Informative Comments I Wait, shouldn‘t we prefer expressive names over a comment? Yes, but in this case one comment prevents duplication in six names!
  • Informative Comments II
  • Explanation of Intent
  • Clarification
  • Warning of Consequences
  • TODO Comments
  • Bad Comments Mumbling Redundant Comments Misleading Comments Mandated Comments Journal Comments Noise Comments Scary Noise Position Markers Closing Brace Comments Attributions and Bylines Commented-Out-Code Nonlocal Comments Too much Information Inobvious Connection Function Headers Javadoc in nonpublic Code
  • Mumbling I
  • Mumbling II
  • Redundant Comments
  • Misleading Comments
  • Mandated Comments
  • Journal Comments
  • Noise Comments
  • Scary Noise Copy & Paste Error? Redundant Field? …?
  • Position Markers
  • Closing Brace Comments
  • Attributions and Bylines
  • Commented-Out-Code
  • Nonlocal Information
  • Too much information
  • Inobvious Connection
  • Function Headers
  • Javadoc in nonpublic Code
  • Demo Comments
  • Anti-Pattern: UnCamelCasing Splitting class/method names into Javadoc… Providing zero additional information There are different skill levels of this art
  • Anti-Tool: JAutodoc Well-meant but ill- conceived Eclipse plugin Automates UnCamelCasing in perfection Do not use this or anything like it!
  • Formatting
  • Vertical Formatting How long should a source file be? Typical file size ~200 LOC Upper limit ~500 LOC Vertical Openness Blank lines act as visual cues and separate concepts Vertical Density Tightly related lines of code should stick together Vertical Distance Closely related concepts should be vertically close to each other Reader should not have to „tail-chase“ through the code
  • Some *really* big (non-generated) Class
  • Horizontal Formatting How long should a line of code be? Upper limit 128 characters „Never scroll to the right“-rule doesn‘t work any more due to ongoing increase of display resolutions One Line = One Statement No Inner Assignments Horizontal Alignment Do not use // to force line breaks 80x25 char 5760x2160 px
  • One Line = One Statement
  • No Inner Assignments
  • //=:-(*)
  • Do not overuse Method Chaining
  • Braces For better legibility use braces even for single- line statements
  • Inline Conditionals Use ?: operator for simple statements only Do not nest ?: statements
  • Team Rules Every programmer has his own favorite formatting rules, but if he works on a team, then the team rules [Uncle Bob, Clean Code]
  • Excercise 4
  • Trading Card Game – Part 3 Same students as last time should pair up… …but work on the code of another pair!!! Cleanup time! Rename! Refactor! Reformat! Remove redundancy! Present your results to the original code owners
  • Clean Code Cheat Sheet Names •Intent •Pronouncable •Lexicon •Scope Rule •Disinformation •Encodings •Prefixes Functions •Small •<20 LOC •<4 Arguments •SRP •CQS •Side Effects •final •Error Codes •Output Arguments •Parameter Assignment •null Comments •Good •Bad Formatting •1LOC = <120 char •1Class = <500LOC •1 line per statement •{…} •// Line Breaks •:? •Inner Assignments Tests •Unit Tests •TDD •100% Coverage •Robustness •Stability •Senseless Tests
  • Lecture 5 Testing Unit Tests JUnit4
  • Testing
  • Good reasons to test Source:
  • Testing Levels Unit Tests Testing individual components (i.e. classes) w/o dependencies Integration Tests Testing the interfaces between different components or subsystems System Tests Testing the completely integrated system in a close-to-production environment Acceptance Tests Source:
  • Unit Tests
  • Why create unit tests?
  • The F.I.R.S.T rule of unit tests F ast I solated R epeatable S elf validating T imely
  • Fast Unit tests give immediate feedback about the quality of implemented changes
  • Isolated I Unit tests do not require configuration Simply selecting “Run as…” in your IDE
  • Isolated II Unit tests have no dependencies on a runtime environment No databases, no web services, no file systems, no ...
  • Repeatable Unit tests must be automated and repeatable anytime
  • Self validating Unit tests have a boolean outcome If the specification is violated, they fail
  • Timely Unit tests are written in a timely manner Ideally before the production code
  • Separation of Concerns Separate your unit and integration tests
  • Test Quality Treat your tests as first class citizens Don’t treat them worse than production code Clean Code rules also apply to tests
  • JUnit 4
  • Hello World Unit Test
  • JUnit A programmer-oriented testing framework for Java Originally created by Kent Beck and Erich Gamma on a flight from Atlanta to Zürich Most commonly used implementation of the xUnit architecture
  • Adding Junit to an Eclipse project
  • Annotations I = Syntactic metadata available since Java 5.0
  • Annotations II Execution order of similar annotated methods is not guaranteed!
  • Boolean Assertions Best practice: Use just one logical assertion per test!
  • Comparison Assertions The expected result always comes first! This is a little bit counter-intuitive.
  • Messages in Assertions
  • Demo JUnit
  • Exception and Border Cases Do not only test the „happy path“ but also Paths where exceptions are expected to occur Border cases of the functionality
  • Excercise 5
  • Testing TCG Create unit tests for various classes of your TCG implementation Concentrate on testing logic like Game rules (e.g. does bleedout and mana cap work?) AI (e.g. does it pick the smartest card combos?) Why is it harder/impossible to test the UI?
  • Lecture 6 TDD Code Kata „Bowling Game“
  • TDD Test Driven Development
  • Test Driven Development Agile Projects embrace change Changing code bears the risk to break existing functionality Clean Code is a lot about refactoring code „I won‘t touch that code!“ TDD will severly reduce the „fear of change“ Test Driven Development by Example Kent Beck, 2002
  • Red, Green, Refactor RED: Write a failing unit test GREEN: Write production code to make test pass REFACTOR: Remove duplication and improve design* * Tests must still pass after Refactoring!
  • Green Bar Patterns Fake it ('til you make it) „Do the simplest thing that could possibly work”. This is a baby (tiny) steps approach. Obvious implementation You know what to write. The implementation is obvious. Triangulation Writing more tests to prove the need for further generalization. Searching for an implementation. One to Many When implementing something that works with collections, implement it without collections first.
  • The Magic TDD Principle As the tests get more specific, the code gets more generic [Uncle Bob] Source:
  • Code Coverage I Code Coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. What is a realistic goal for our Code Coverage? Source:
  • Code Coverage II
  • Code Coverage III 100%?!?! OMG!!! WTF?!
  • Let‘s hear what Uncle Bob has to say about Code Coverage… Source:
  • What is the purpose of this Test?
  • Behaviour Driven Testing Wrong: Getting obsessed with code coverage Right: Think about behaviour you want to test Code coverage will be automatically satisfactory
  • Code Coverage Goals Code Coverage is not a managers goal… …it must be our goal! Absolute Code Coverage is not the best KPI Code Coverage progression over time serves as a better indicator Relation of Line Coverage and LOC added must not decrease Overall Block Coverage must approach 100% asymptotically not decrease
  • Test Quality Tests must be robust and stable Tests must make sense No-op tests Happy path tests only Tests w/o (reasonable) assertions
  • Single Assert Rule Each test should only do one logical assertion One phyisical assert is perfect Multiple physical asserts make up one logical assert Mixing assertTrue() and assertFalse() can be confusing! Two different patterns are tested so these are multiple logical asserts!
  • Code Kata Bowling Game
  • Bowling Game Kata Bowling Game Kata Object Mentor, Inc. Copyright  2005 by Object Mentor, Inc All copies must retain this page unchanged. Source:
  • Excercise 6 Adding some advanced rules to our TCG
  • Trading Card Game – Part 4 Randori Kata Style Source: Two people begin solving the exercise live on the digital projector Pilot = Driving the exercise on the keyboard Co-pilot = Keeping rules and quality in view TDD is mandatory! After 7min Timebox… …the pilot goes back into the audience …the co-pilot is promoted to pilot …someone from audience becomes co-pilot
  • Advanced Rule Healing When playing a card the active player can choose to… …use it to cause damage (Basic Rules) …use it to heal himself Players cannot heal up above 30 health 29 -x x = = +x 31 32 … Source:
  • Preliminary Design Session How do we plan to integrate this rule? What is a good test to get the TDD loop started? Which classes will we have to change? Are there existing tests that will probably change?
  • Lecture 7 BDD Test Style Matchers Mocking
  • BDD Test Style Creating readable, explanative tests
  • Don’t test APIs, test behavior Source:
  • Don’t say test, say should
  • Think in terms of scenarios Scenario: Refunded items should be returned to stock given a customer previously bought a black sweater from me and I currently have three black sweaters left in stock when he returns the black sweater for a refund then I should have four black sweaters in stock
  • Structure your tests consistently public void shouldReturnRefundedItems() { // given // when // then } Define test data and behavior of mocks here. Call the code under test here. Verify the expected behavior here.
  • BDD Test Style Example
  • Things you don‘t care about You want to prevent specifying things you don‘t care about in your current test… …but sometimes you are still forced to do so We don‘t care how Store internally keeps its stock We don‘t care about the store manager
  • Test Data Builders Let you create test data conveniently Declare sensible defaults for mandatory fields Syntactic sugar improves legibility
  • Internals of a Test Data Builder Data can be conveniently specified... Sensible default values Syntactical sugar build() creates actual object …by chaining with-methods
  • Matchers assertThat(audience, is(paying(attention));
  • What is Hamcrest? According to project homepage: Provides a library of matcher objects (also known as constraints or predicates) allowing 'match' rules to be defined declaratively, to be used in other frameworks. Typical scenarios include testing frameworks, mocking libraries and UI validation rules. Hamcrest it is not a testing library: it just happens that matchers are very useful for testing. Source:
  • Typical usage example Wait! Why don‘t we just stick with good old assertEquals() here? Looks equally fine, aye?
  • Assertions on Collections Wouldn‘t you prefer this?
  • Descriptive Error Messages With Hamcrest this will change into:
  • Combining Matchers
  • Custom Matchers Hide or combine complex matching logic Improve overall legibility of test & error log
  • Mocking given(oxygen.isAvailable()).willReturn(true); verify(oxygen, atLeastOnce()).isAvailable();
  • Why Mocking? Control dependencies to test classes in isolation Create fake implementations of classes or interfaces Define behavior of fake implementations Verify expected behavior of units under test
  • Control Dependencies
  • Control Dependencies
  • Inject Dependencies Inject dependencies into classes via constructor or setter Avoid constructing dependencies inside a dependent class via new operator Avoid directly referencing static methods from utility and helper classes! Static things can not easily be mocked Requires additional libraries like PowerMock Will perform magic tricks with Java classloading… …and have severe performance impact on your tests!
  • Dependency Control Example We depend on this… …but there‘s no implementation yet! And: We only want to test this unit!
  • Setting up a Test with Mockito Runner takes care of initializing all mocks Unit under test… Mocked Dependency …gets initialized normally
  • Defining and using the @Mock The behavior of the mock is defined within the //given block of the test All undefined methods of a mock do nothing (for void return parameters) return null (in all other cases)
  • Verifying @Mock behavior Mocks remember all interaction You can verify how often and in which order mocked methods have been called Failed verifications work just like failed assertions Beware: Verifications should not be overused! Concentrate on the unit under test, not its mocks
  • Excercise 7
  • Add Hamcrest and Mockito to your classpath Move both above JUnit to avoid strange phenomenons…
  • Add Favorites for static imports
  • Trading Card Game – Part 5 Back to Pair Programming Choose your favorite partner  TDD / BDD is mandatory! Use Hamcrest matchers and Builders! Mock if you feel the need for it! Common code baseline to start with
  • Getting Ready to Code Get the source code or Import project into any IDE (with Gradle support) automatically from or import sources in tcg-java and setup manually JDK 1.8 with compiler compliance/language level 8.0 JUnit 4, Mockito 1.9, Hamcrest 1.3, System Rules 1.4 Got an implementation in a cool and/or exotic language?
  • Advanced Rule Minions (I) Let players choose to play cards either as immediate damage Attacks (as in Basic Gameplay) as Minions that are put on the board instead Minions will use the mana cost of their card as Health and Damage value. Health has to be tracked when they receive damage 29 -x x = = x x Source:
  • Advanced Rule Minions (II) Each player can have a maximum of 3 Minions on the board at any given time A Minion will sleep in the turn it was put on the board In any subsequent turn each Minion can be used once to deal damage to the opponent player or an opponent Minion 29 -x x x x 29 -x x x Zzz Zzzz Source:
  • Advanced Rule Minions (III) A Minion fighting another Minion will result in them dealing their damage value to each other simultaneously Sleeping Minions will defend themselves in the same way when attacked by another Minion x x y y -x -y x x y y -x -y Zzz Zzzz Source:
  • Advanced Rule Minions (IV) Players can choose to play an Attack against a Minion. The attacked Minion will not defend itself in this case, thus the attacking player receives no damage from it When a Minions health drops to or below zero it is removed from the board y y -x x x 0 -1 … Source:
  • Lecture 8 Code Retreat „Game of Life“
  • The Musician Metaphor
  • The Superhero Metaphor
  • Code Retreat A day-long, intensive practice event, focusing on fundamentals of software development and design Provides developers the opportunity to take part in focused practice, away from the pressures of 'getting things done’ Highly effective means of skill improvement Practicing the basic principles of modular and object- oriented design, developers can improve their ability to write code that minimizes the cost of change over time Source:
  • Structure of a Code Retreat (formalized by Corey Haines) Problem: Conway's Game of Life Length of Session: 45 minutes Duration: 8.30am to 5 or 6pm Pair-programming is necessary, as the knowledge transfer contained in that activity is essential to the practice Prefer using Test-Driven Development (TDD) After each session, pairs should be swapped After each session, code must be deleted, not put in a branch, not stashed, just deleted with no trace left Source:
  • Typical Code Retreat Day Outline 8 - 8.45am : arrival, coffee/breakfast 8.45 - 9am : welcome, introductions, explanation of the problem 9 - 9.45am : Session #1 9.45 - 10am : retrospective, break 10 - 10.45am : Session #2 10.45 - 11am : retrospective, break 11 - 11.45am : Session #3 11.45 - 12pm : retrospective, break 12 - 1.30pm : lunch, socializing 1.30 - 2.15pm : Session #4 2.15 - 2.30pm : retrospective, break 2.30 - 3.15pm : Session #5 3.15 - 3.30pm : retrospective, break 3.30 - 4.15pm : Session #6 4.15 - 4.30pm : retrospective, break 4.30 - 5pm : Closing circle Source:
  • (Mini-)Code Retreat Agenda 2-3 sessions 45 min developing TDD Pair Programming Clean Code Delete the code 15 min retrospective 15 min break
  • Conway‘s Game of Life Cellular automaton Invented by mathematician John Conway in 1970 Zero-Player Game Evolution is determined only by the initial state Two-dimensional grid of square cells Each cell can be either alive or dead Each cell interacts with ist 8 neighbors Four rules determine the games evolution All cells evolve simultaneously from one generation to the next Source:
  • Rule 1: Underpopulation Any live cell with fewer than two live neighbours dies, as if caused by under- population
  • Rule 1: Underpopulation Any live cell with fewer than two live neighbours dies, as if caused by under- population
  • Rule 2: Living On Any live cell with two or three live neighbours lives on to the next generation.
  • Rule 2: Living On Any live cell with two or three live neighbours lives on to the next generation.
  • Rule 3: Overcrowding Any live cell with more than three live neighbours dies, as if by overcrowding
  • Rule 4: Reproduction Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction
  • Example: Glider
  • Game of Life Examples Blinker Glider Lightweight spaceship (LWSS) Pulsar Glider Gun Source:
  • Border Behavior: Wall of Death
  • Border Behavior: Pacman Universe
  • Spicing up the excercise Shuffling Pairs before every round Using different programming languages Different styles of Pair Programming Different rules from the Object Calisthenics
  • Time Boxing Developer 1 writes test + code for X minutes. Developer 2 writes test + code for X minutes.
  • Ping Pong Developer 1 writes new test that fails. Developer 2 writes the code needed to pass the test. Developer 2 writes next test that fails. Developer 1 writes the code needed to pass the test.
  • Driver & Navigator Driver writes test + code. Navigator reviews each line and considers the strategic direction of work. Switch roles.
  • Object Calisthenics No if statements No loops Small methods (< 5 lines, 1 line?) No primitive types TDD as if you meant it Top-Down Design Bottom-Up Design Without mouse Tell don't ask – no getters and setters Functional, no state One level of indentation No else One dot per line No abbreviations Everything is small No classes with more than two instance variables Use of first-class collections No talking Source:
  • Session One Pair Programming Style Time Boxing Object Calisthenics Everything is small 45min programming Code must be deleted afterwards
  • Session Two Pair Programming Style Ping Pong Object Calisthenics No loops One dot per line 45min programming Code must be deleted afterwards
  • Session Three Pair Programming Style Ping Pong Object Calisthenics No talking 45min programming Code must be deleted afterwards
  • Lecture 9 Code Quality Measurement Feedback
  • Code Quality Measurement
  • Code Quality Measurement Tools Static Code Analysis FindBugs CheckStyle PMD Code Coverage EMMA Cobertura Quality Management Platform Sonar All below offer Eclipse Plugins!
  • Static Code Analysis Rule based detection of code smells potential bugs coding standard violations Do not rely solely on these tools! False positives are an annoying issue Rules can often be „cheated“ on „Soft factors“ can not be validated expressiveness of names quality of comments
  • Fix the problem, not the issue! Issue Problem Issue Problem
  • Excercise 9 The Final Excercise
  • Surprise, surprise: Game of Life Develop a complete implementation of Conway‘s Game of Life Create a brief up-front technical design in UML Define a behavior for the universe borders Border of dead cells? Pacman-style infinity? …? Implement the UI in your favorite Rich Client API Swing, SWT, RCP, … Do TDD or at least write good tests along the way
  • Feedback Follow the Doodle link in your invitation email Please provide at least a star-rating Additional feedback is highly appreciated What did you like best about the workshop? What could have been better? What didn‘t you like at all?
  • The End Thank you for your attention!
  • Credits Robert C. Martin, @unclebobmartin (Clean Code, TDD, Bowling Code Kata) Prof. Dr. Frank Zimmermann (Agile Software Development) Sascha Krüger (Unit Testing, Hamcrest, Mockito) Lukas Hinsch (Unit Testing, Hamcrest, Mockito) Sebastian Bergandy, @SebastianBergan (Clean Code, Code Retreat) Gunnar Morling, (Code Retreat) Oliver Widder, @geekandpoke (Geek & Poke Cartoons, Blizzard Entertainment (Kata TCG, Permission of use requested for images) Hearthstone: Heroes of Warcraft® is a trademark or registered trademark of Blizzard Entertainment, Inc., in the U.S. and/or other countries.