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

Öredev Torsdag

x Driven Design

Rebecca Wirfs-Brock talked about the various -DD:s out there. Coming from Smalltalk she's been writing several books on object orientation design, RDD being her baby.

RDD - Responsability Driven Design

• Roles
• Responsability
• Collaborations

informed tools and techniques

localize responsability

CRC - Candidate Responsabilities Collaborations

FDD - Feature Driven Design

Feature lists --> Feature by feature:

1. Domain walktrough
2. Design
3. Design inspect
4. Code
5. Code inspect

Design first week, code second.

TDD - Test Driven Development

1. Write simplest test
2. Run test and fail
3. Write simplest code that will pass
4. Run the test and pass

"Design between the keystrokes"

BDD - Behavioural Driven Development

Given context

When event occurs

Then outcome

DDD - Domain Driven Design

CDD - Contract Driven Development

Making the sausage

Intresting walkthrough on the work of BDD-framework in Clojure. BDD and Clojure is interesting in itself, but also interesting how they worked out their ideas.

NoSQL

ACID doesn't scale out. Problems:

• Data size
• Connectivity
• Semi structure (modeling and sparse data)

4 types of new types

• Key value
• Big table
• Document
• GraphDB

DYNAMO-paper by amazon very influential.

BASE

• Basically Available
• Soft state
• Eventually consistent

Examples:

• Voldemort - key-value store
• Cassandra - BigTable
• Google Bigtable
• Apache Hadoop HBase - Bigtable
• Couch DB - Document (REST)
• Mongo DB - Document
• RIAK - Document (REST with DYNAMO scaleout)
• Neo4j - Graph
• Allegiograph - Graph

The Productive programmer: Mechanics

Kul session om hur man blir effektivare på det personliga planet. NealFord.com.
[slides]

Acceleration

clcl Clipboard enhancement

mousefeed Eclipse-plugin to help learn keyboard shortcuts

Focus

Flow takes 20-30 minutes to reestablish.

TweakUI To turn off windows balloon tips

jedi concentrate Screen dimmer

Turn off notifications like email, phone, etc

Office "quiet time" for example 9-11, 13-15.

Google desktop to find things efficiently, plugin for indexing any filetype.

Out of the frying pan into the fire

Fun scrum-lover sharing real life anectodes.

Öredev Onsdag

Accomplishing more by doing less

Alltid kul med mjuka inslag, det är en av anledningarna att jag gillar Öredev. Började med några övningar: Tyst minut och 2 minuter att svara på tre frågor medans grannen tyst skulle lyssna: Vad skulle du vilja undvika att göra på jobbet? Hur kan du åstadkomma det? Körde övningen med en cool äldre kille från Oslo som visade sig vara Trygve Reenskaug.

Ytterligare frågor: Vad vill du åstadkomma här på jorden? Hur kan du åstadkomma det?