fredag 19 mars 2010

TDD Beyond Basics dag 2

5 minute rule for arguments, longer argument than that then let go à doesn’t matter!

Även denna dag började varje pass med teorier som
  • Maxwells theory – all is waves
  • Galileo - Speed is relavite to any frame of reference
  • Equivalence principle
  • Einsteins General relativity

Katas

TDD

Unit Tests must comply with FIRST:

FIRST

Fast
Isolated (Independent)
Repeatable
Self verifying
Timely

Fast

Tests need to be fast to be run.
Do not use production data, it contains too much clutter. Construct your data!
Discussion on Golden Copy vs Approval Testing.

Isolated

One fault should make only one test fail

Repeatable

Able to run anywhere repeatably with same result; plain, train, work, home, etc.

Self Verifying

Pass or Fail! Nothing in between or demanding human intervention (like reading logfiles)

Timely

Written first. The test is the specification.
1 code change = 1 test

Given when then

What about METHOD_WHEN_THEN, for a stack the test methods could be:
Push_empty_sizeIsOne
Pop_empty_throwUnderFlow
Push_full_throwOverFlow
Pop_sizeone_empty

Principles

#1                  Don’t test private or protected methods.
#2                  Testing trumps privacy
·        Make private methods package protected
·        Or extract into own class
#3                  Testing privates implies a design error

Put tests in same package

Preferably in same directory, but deploying without tests is tricky.

Fragile tests

xUnit Patterns à The fragile test “problem”

Interface Sensivity

Do not depend directly on UI-components
Open/Closed Principle (Bertrand Meyer), a class should be open for extension but closed for modification.
The best anticipation of change is change that already happened.

Behaviour Sensitivity

Avoid complex setup and tardown scenarios
Access the tested feature as directly as possibly

Data Sensitivity

Failure because of changed test data. Control your test data!

Context Sensitivity

-         Data/time
-         Available Memory
-         Network Services
-         Hardware
Mock out context dependencies. Mock out clock!

Overspecification

Failure because of change in system test should not care about. (The scope of test is too wide).

Sensitive Equality

Failure caused by an over-constrained comparison
-         Floating point, whitespace
-         Avoid it! J

Preserving tests

FIRST!
Failures are “stop the presses” events. Keep test code clean!

FitNesse

Put fixtures in same project as code under test. Test your fixtures.

Put under source control!

Check in all txt and xml-files under FitNesseRoot.

Same tests, different setup

Use symbolic links
Product
  Test One
  Test two
Dev
  Setup
  Symlink à Product
Prod
  Setup
  Symlink à Product

Special pages

PageHeader   Siblings gets page header
Setup            
TearDown

Variables

!define NAME {BOB}
The variable NAME is ${NAME}
Can define java definition and environment variables as well.

Old style (ColumnFixture)

  • Should be several small tests
  • States what to do, not what to test

New style

Misc

måndag 15 mars 2010

Kurs: TDD Beyond Basics med Uncle Bob

Måndag
Kursen startade lustigt nog med att Bob gick igenom grunderna för partikelfysik, foton, boson, fermions, etc. Började sedan varje delpass med mer partikelfysik. Ett intressant grepp som det ska bli kul att se poängen på.

Resistance and professionals

Vi gick sen igenom vilka problem som TDD-utövare kunde stöta på. Bob angrep passionerat ”organisational resistance”:
As programmers we are professionals. Like doctors, architecs we must ignore organisational pressure. Pressure is put on us for a good reason; to see if we really believe what we are saying. As professionals we know the best way to write code, noone else can tell us that. And as professionals we now the best way is to do test first.
As professionals we also do not want to deliver crap, we want to be proud. And we know that to be fast we need high quality. You are more likely to clean tested code!

Pairing

Bobs råd var att paira ca 50% av tiden, bump it up. Code review kan inte ersätta pairing när det gäller kodkvalitet, men är ett bra komplement för att lära ut sunda principer. Se dock till att det sker på ett sätt där alla är engagerade.

TDD basics


Några lösryckta yttranden som fastnade:
  • 30 seconds cycle time usually, about 1 hour when doing UI.
  • Tidsvinst: Less debug time
  • Trust in the test suite is essential à true maintainability
  • Code coverage bör ligga över 90%, helst 100%! (Vi gjorde ett antal övningar där målet var att nå 100%).
  • To be testable means modularized, able to isolate behaviour which leads to good design.
  • About 33% of code is usually tests, i.e. a 2:1 ratio between production code and tests.
  • I want to be proud of my code

Test Driven Documentation

TDD can stand for
  • Test Driven Development
  • Test Driven Design
  • Test Driven Documentation
“My documentation is formal, it compiles! How about your documentation?”

TDD – några regler

Do one thing

Varje metod/funktion ska bara göra en sak. Det har man uppnått ”when you cannot extract a method à extract till you drop”.
A method that does one thing is testable with one logical assert

Test one thing

Use one logical assert (notice the circular tendency to Do one thing).

Clean test – några mönster

Composed Assert
Composed test result

TDD och GUI

GUI-tests are fragile! Test “under” the GUI, to be continued…

Övningar dag 1

  • HuntTheWumpus. Bump up to 100%. Introduktion med syfte att visa hur enkelt det är att förstå välskriven kod.
  • Environmentalcontroller. Bump up to 100%. What’s good, what’s bad? Många intressanta diskussioner om felaktigheter.
  • Coding DOJO: word wrap. På en timme hann vi tre test J http://codingdojo.org/cgi-bin/wiki.pl?WhatIsCodingDojo

Verktyg

Git, msysgit för windows, http://code.google.com/p/msysgit/
git clone git://github.com/unclebob/HTW.git
git clone git://github.com/unclebob/fitnesse.git
git clone git://github.com/unclebob/environmentcontroller.git