Planering

Det här är en sida om varför och hur man planerar.

Först ut: En sammanfattande video efter maildiskussion på Agile Sweden som kommer fram till att planera gör man i första hand för att bygga lagkänsla och man gör det så enkelt som möjligt.

http://www.youtube.com/watch?v=7JrJL7hHDmI

java-ee-spike-kata

Johannes Brodwall har bloggat om en java-ee-spike-kata:
http://johannesbrodwall.com/2010/05/02/six-ideas-that-improve-your-software-design/

Hela java-ee-spike-kata i "obruten form" finns här: http://jhannes.blip.tv/file/3487566/

Tips:

•  pom:en behövs för att komma igång (från github, länk ovan), importera i eclipse och sätt igång.
• log4j.properties under test/resources behövs för att få ut exceptions från jetty m.fl.
• Ha org.mockito.Mockito, org.fest.assertions.Assertions som Type favorite i eclipse, se Preferences->Java->Editor->Content assist->Favorites->New Type.

log4j.rootLogger=warn, A


log4j.appender.A=org.apache.log4j.ConsoleAppender
log4j.appender.A.layout=org.apache.log4j.PatternLayout
log4j.appender.A.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

Agila länkar

Har lite svårt att hitta något bra sätt att komma ihåg olika länkar som kan vara kul att återkomma till, så det får bli såhär tills vidare:

Om AI Retrospective: Always look at the bright side of life...
http://ellnestam.wordpress.com/2009/11/12/an-ai-retrospective/

TDD Beyond Basics Dag 3

Under construction

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

http://katas.softwarecraftsmanship.org/?p=139

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)

http://localhost:8080/FitNesse.SuiteAcceptanceTests.SuiteWidgetTests.TestLinkAlias

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

New style

http://localhost:8080/FitNesse.SuiteAcceptanceTests.SuiteWidgetTests.SimpleWidgets

Misc

• Gesture – tool that changes production code to see if tests fail
• Humble Dialog Box, http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf
• JSP-compiler, creates a servlet basically
• AST – Abstract Syntax Tree
• Velocity – web framework
• jTest – generate unit tests

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

(Bild från http://agileinaflash.blogspot.com/2009/03/unclebobs-three-rules-of-tdd.html)

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

Emma, http://emma.sourceforge.net/

20 top programming lessons

Mycket läsvärd kort artikel om 20 regler angående programmering

http://www.dcs-media.com/Archive/20-20-top-20-programming-lessons-ive-learned-in-20-years-FH