Embed Size (px)
DESCRIPTION
Doing Code Katas alone or in a Dojo can help sharpen our elementary skills as software developers. Practicing IDE shortcuts and TDD mini-step cycles is very useful for the daily business, yet I find some existing Code Katas too far away from real-life programming situations. That’s why I came up with the Trading Card Game Kata – which is (very loosely) based on Blizzard Entertainment’s free-to-play online-game “Hearthstone – Heroes of Warcraft”. This Kata is focused on practicing TDD in a slightly more complex (but not complicated) situation where you might have to think about rules like Single Responsibility Principle or Command Query Separation and might even feel the urge to use a Mocking framework at some point. The rules are kept very simple to begin with but can be extended easily to make the Kata more challenging or concentrate on specific aspects of software development. In this talk I will first introduce the ideas of Katas in general and explain the TCG Kata rules to you. Then I will present some real-life best practices for writing good developer tests, using my TCG Kata sample solutions as a showcase. This will include: * Picking the right Test Double * Test Data Builders * Behavior Tests with BDDMockito * Prose-like Assertions with Hamcrest * Readability Sugar * Custom Matchers against Test Diabetes The full Kata ruleset and sample solutions in Java 8 (JUnit4, Mockito, Hamcrest) and Groovy (Spock) can be found on https://github.com/bkimminich/kata-tcg. A recording of this talk at „Agile Saturday X“ in Tallinn, Estonia can be found on https://vimeo.com/92886146.
Citation preview
Practicing AdvancedUnit Testing
v2.3.2 (13.04.2023)
with the«Trading Card Game»
Kata
Battlecry: Draw a slide.Deathrattle: Transformaudience into 1/1 sheep.
Speaker
Kata
Kata ( 型 or 形 literally: "form”) is a Japanese word describing detailed
choreographed patterns of movements practiced either solo or in pairs.
Trading Card Game (TCG)
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.
Why invent another Kata?
Bro, why U not use
?????
Rules not extensible
Not TDD-friendly
Too easy
Hearthstone: Heroes of Warcraft®
Kata Trading Card Game
Player Setup
0 0 1 2 2 2 3 3
3 4 4 4 5 6 6 7 8
30 0/0
Health ManaD
eck
1 3
5
Hand
2
7
Active Player
1 3 5
8
0/11/1
Gameplay
2
30 300/0
3Play Card 1
29
Cause 1
Damage
0/0
Draw Card
-1
Receive +1
Mana Slot
Replenish
ManaPay 1
Mana
Game Table
Draw extra Card
2 4
0/1
Forced Turn Skip
25 8
30 1/1
23
29
3
No affordable Cards
2/2
7
29
4
0/2
Ongoing Gameplay
25 8
30 1/1
23
27
3 4
2
2
-2
2/2
7
12
4
8/8
Overload Rule
75 8
18 7/7
8016
2
Discard Card when Hand
already holds 5 Cards 7
410/10
Mana Cap
5
8 10/10
166 Mana is capped at 10 Slots
410/10
Bleedout Rule
5
8 10/10
166Drawing
from empty Deck
7-1
Cause 1
Damage
410/10
Game End
5
10/10
166
7 -2-6
Winner! Loser!
4/10
Kata TCG Rules & Variations
https://github.com/bkimminich/kata-tcg
Detailed rules descriptionAdvanced Variations
Healing cardsUse cards as MinionsDifferent cost & damageCard drawer cardsDeck customization
Kata TCG Sample Solution in Java
https://github.com/bkimminich/kata-tcg
Java 8Lambdas & Stream API
JunitMockito
For handling dependencies of tested objects
HamcrestMatchers for better legibility in assertions
System RulesJUnit @Rules for substituting java.lang.System
Other Sample Solutions
https://github.com/bkimminich/kata-tcg
GroovySpock
JavaScriptKarmaJasminePhantomJS
Advanced Unit TestingExamples
Skip No-Brainers
…
Compile Error as Red Test
Red
Green
Refactor
Obvious Implementation
Simplest possible
step
Simplest useful step
Specify the Object under Test
Irrelevant Details
Setter introduced for
testing
Implementation Detail
Assuming Hidden Default
Define the Object under Test
Another unwanted
setter
Hidden default problem solved
Builder Pattern
Reads like natural
language
Explicitly listed Expectations
No unnecessary details
…?
Builder Internals
Sensible Default Values
Package visible full Constructor
needed
Fluent API
Setting properties via
fluent API
Mocking Behavior
Interface has no implementation
yet
Mock Behavior for
this Test
Trashcan RefactoringCardPicker turned
out to be overengineered
Mocking
Mocking BDD Style
Can beconfused withGiven-When-
Then part
Can beconfused withGiven-When-Then part
Mocking BDD Style
Sugar coating for BDD syntax
Matches its meaning inGiven-When-Then
structure
Avoid Redundancy
Redundant & spoiled with Implementation
Details
Another slight redundancy
Avoid Constants
Disturbs the reading flow
Syntactic Sugar
Improves Legibility and
removes Redundancy
More Syntactic Sugar
Magic Number
sDifferent Level of Abstraction
Syntactic Artificial Sweetener
No-Op SyntacticSugar for Legibility
Syntactic Sugar
reduces Redundancy
Test DiabetesToo much Sugar is bad for your
Test
Customer Matchers can medicate this
Custom MatcherEncapsulation of
Expectation
Produces helpful Error
Messages
Even better with just a little bit of
Sugar
Demo | Q&A
Demo: Test Execution
All tests passPretty fast
Demo: Code Coverage
Ugly UIUgly Retro UI
Demo: Human vs. AI Game
Player Inputvia System.in
AI beats me! Again!
Thank you for your attention!
Recording of this talk at „Agile Saturday X“ in Tallinn, Estoniahttps://vimeo.com/92886146
https://twitter.com/bkimminichhttps://linkedin.com/in/bkimminichhttps://google.com/+BjörnKimminichhttp://slideshare.net/BjrnKimminich/
Credits
Background Image: Demonplay (Permission of
use granted)
Other Images:Blizzard Entertainment (Permission of use requested)
Wikipedia, Github, Agile EstoniaAllmystery.de, Gueball.de, Natekohl.net,
Scenicreflections.com
Hearthstone: Heroes of Warcraft® is a trademark or registered trademark of Blizzard Entertainment, Inc., in the U.S. and/or other countries.
