Tag: tdd

Tests – Silver Bullets?

A colleague wrote:

I have a client who needs to convince their old-school management that unit testing has value. I know. I know.

and he got some good material to work off. I myself recalled a very interesting session on CITCON in Budapest where a person playing the role as CTO asked us all to convince him that they needed pre-production tests (such as unit tests). Their (the company’s) experience was that they were doing absolutely fine without it, since they had close collaboration with the customer throughout the development process and lots of eye balls looking at hourly reports on how their web site(s) performed in terms of business.

In the rare cases where a bug went through and caused “damage”, the sales and support people had turned the unfortunate events (such as selling some Gucci or Versace type of bags for 1£ each, instead of 1000£ because of an unexpected comma (thousands delimiter) in the in-data file) to something positive and a marketing “event” kind of thing. These kinds of things, bugs/errors, didn’t happen very often at all and their customer base were actually mostly positive about when it did happen as they saw a company that in very short time responded to customer feedback, were open and honest about what they did to correct the situation etc. They had lots of in-production metrics/monitoring in place and people that closely monitored their systems. From a tech point of view, they seemed to have 0 issues. Business was happy with time-to-market etc.

The session was titled Do_we_need_tests_on_planet_retail? but no-one seems to have taken notes (or at least post them). Essentially, in this case we concluded that the only valid reasons to spend time writing pre-production tests were:

a) if the developers wanted to, then they should,
b) if the organization wanted to attract developers that wanted to write pre-production tests, then this could be encouraged by the organization as means of helping the recruitment of such individuals
c) if they started to get quality problems that they couldn’t sort out with whatever other means of quality improving measures they’d try (more code reviews, code analytics tools, …), then this is one route/option they could try out to see if it would help them fix that problem (but as of that day, they didn’t really have a quality problem)

We tried to pursue the argument that “tests/regression test suites” documents expected behavior of the system and helps people new to the code base not break features. Being strict with pair programming and not touching new areas without pairing with an “old timer” would ideally solve that too (and they didn’t have problems retaining their personnel). Risk obviously is a factor, “X people gets hit by a bus”-scenarios and such.

Teams of about 20 people in total doing development and ops. More people on community facing activities and sales. I understood they bought assets from companies that had gone bankrupt, and sold the stuff on-line. They’d been doing that for several years and were very profitable. Most of the work seemed to setup web sites and/or campaigns targeting certain audiences (high profile/expensive jewelery, football fans, 2013 Olympics Gadgets, …) and get statistics out of that to see how profitable the bought set of assets turned out to be. As such they monitored, from a businesses point of view, the system closely to see how the market responded to various on- and off-line activites and events.

I wouldn’t personally want to have my evenings with the kids depend on on that (systems with zero pre-production tests) but if/when what what you’re doing is mostly routine (similar things had been done many times) the value of writing the same tests over decreases as they become assertions of not typing the wrong thing. Good pair programming should save you from most of that.

TDD:ing in order to design the code, perhaps differently from previous iterations, is another subject. But in short – since the business was happy with what they were getting, and the developers lead happy lives too, it was hard to find reasons for them to have to change.

Agila Sverige 2013

Sitter på tåget på väg hem från Agila Sverige 2013. Det har varit två underbara och uttröttande dagar, med mängder med trevligt, kompetent folk, bra blixttal och öppna, givande diskussioner och dialoger.

Egna insatsen

Fredrik Wendt: Coding Dojos för företag
Jag var först ut, hade inte presentatörsanteckningarna framför mig vilket var tvärtemot vad jag fick mail om dagen innan, men bortsett att det blev lite mindre fokuserat och tydlig röd tråd så tror jag att det viktigaste sades.

Open space-session på temat “Hur lär man ut TDD?”

(Kallas också rundabords-diskussioner, ofta utan bord.) Jag deltog i ett par open space (kallades open X)-sessioner men förde bara anteckningar från en där frågeställningen var Hur lär man ut TDD? Det var inte jag som som föreslog ämnet men deltog och försökte erbjuda så konkreta tips på idéer till den/de som sökte svar och inspiration eller bara nya (eller gamla) tankar.

  • + training, education
  • ? how do I get colleagues to see the benefit of it?
  • ! forced for a short period where you see the end of the period, one sprint/2 weeks
  • ! re-allocate some of the devs to a team where TDD is heavily used
  • ! move away from too simplistic katas, people have a too hard time transfering what they’ve seen/learned to production (Emily: this was NOT me saying this, brought up by someone else based on experiences from other teams and devs! :-)
  • ? hard to start when what you’re starting your journey from/off of/on/what you have is untestable legacy code
  • ! book: M Feather’s Working With Legacy Code
  • ? more on what’s the benefit of TDD in your view?
    I answered that almost everyone agree that pre-production tests, such as a unit test suite, is of great value.
    If you use TDD as means to get more readable, usable, understandable, maintainable code – then that’s your benefit. But it’s not the only way to get there, TDD is not the silver bullet solution to everything.
  • ? what are the arguments against TDD?
    Can’t use it blindly, might be hard transition/initially. Should/may not be used for spikes.
  • ! book: Kent Beck’s Test-Driven Development by Example

Övriga personliga diverse anteckningar och doodles

Ann-Louise Ulfsparre och Fredrik Josliden: Kommunikation mellan team, javisst! Men, hur då?
Story points samma mellan team? Grooming utan O? Slå ip team fungerade bra. Skall prövas!

Johan Dewe: Så fick vi alla att räcka upp handen
Om att rulla ut agil utvecklingsprocess utan att kalla den agil. “Roll your own vs try what’s been known to work”?
Rubrik “att få alla att räcka upp handen”, efter en egen introduktionskurs (liknande CSM dag 1, PSF, …) med folk från blandade verksamhetsfunktioner så fick alla frågan “Vilka håller på med systemutveckling?”. (Alla förstod sin del och att det var en del av det hela.)

Jonas Hermansson: Acceptanstest är töntigt
Acceptanstestare är ofta för välbekanta med testobjektet – fundera över vem som gör acceptanstestet och konsekvenser av det. Mycket humor, kul presenterat! En klar topp 3 för mig.

Kajsa Goffrich: RTFM – varför är vi så snåla med kunskap?
Vi håller inne med kunskap som Joakim von Anka håller sina pengar i sin pengabinge, varför? Agil metodik leder till att vi jobbar öppet och talar ut om “jag har kört fast, tar tid, har problem”, men hur bemöts det? Vilken inställningar har vi till detta? “Jag har blockering – skall givetvis ses som att det teamet som har en blockering, inte en individ”. “Jag är inte korkad, jag har bara inte lärt mig det än”.

Inga-Lill Holmqvist: Servant Leadership – passar bra ihop med Agile och Lean?
Att tänka “du är viktigare än jag”, som chef. Mät: “Växer personen som jag servar?”
Aktivt lyssnande; Empati; Läkande; Awareness (self, organizational); Bygga konsesus vs auktoritativ beslutsfattande; Foresight; Stewardship (översattes till förvaltarskap :-P); Bygga gemenskap (community).
(Ja, allt detta passar mycket bra ihop med Lean och Agile.)

Matti Klasson: DevOps – ett sätt att samverka inte en jobbtitel!
Mixade team, praktisera i annan roll. Automatisering och verktyg är inte lösningen – lösningen är samverkande människor.

Annica Söder och Anna Forss: Hur vi undvek att bygga Dödsstjärnan
Jämförde Star wars- och Star Trek-stil, dvs magi, hjältar och ikoner med vetenskapliga teorier, samverkan och team.
10000 stormtroopers vs teamet “on the bridge”; Yoda vs Spock (mer vetenskapligt); dödsstjärnan vs enterprise (doable scope); mötet där Darth nästan stryper en amiral vs star trek-öl i restaurangen på skeppet (refletion meetings)
Seldon plan.

Thomas Nilsson: 13 steg mot Kanban Kaizen
Kändes lite för basic, men passade säkert många andra. Bra take away: se till att välja ord – det är lättare att “genomföra ett litet experiment under 2 veckor” vs “nu skall vi förändra våra arbetsmetoder”.

Annika Widmark: Om att lösa komplexa problem med enkla bilder
Storytelling, visualisera förändringsarbetet. Gather facts, group facts, imagine goal, show/visualize/draw. En av flera presentationer som tycker att tre kugghjul visar på något som snurrar (tre kugghjul som rör varandra kan aldrig snurra).
Glömde fråga om de foldrar som tagits fram hos Arbetsförmedlingen om erfarenheter om bra metoder/framgångar från projekt har lämnats ut publikt (tillbaka till skattebetalarna).
Bok: Back of the napkin, Dan Roam

Daniel Fröding: Continuous Delivery – On the road to a true agile company
itrevolution.com. Bra budskap. Använde karaktären Mr Business som gav beståeende men/intryck ;-)

Labbet – Continuous Delivery Pipeline

Andra halvan av dag ett var open X och jag valde att spendera tid i “labbet” med bl a Mattias Karlsson, Mikael Sennerholm och Johan Elmström från Avega Group (Enzo). De hade med ett par saker in, dvs förberett ett par saker såsom CI-, test- och prod-VM:ar, (Jenkins, Tomcat, Puppet, GitHub) men framför allt härlig öppenhet och vilja att lyckas utan att ta för mycket fula genvägar.

I korthet så fick vi något som fungerade, men ingen av oss helt “färdiga” (uppstädning) och ej heller helt nöjda med teknikstacken. Jag skall kanske inte tala för de andra men Jenkins och sina plugins (jag läste källkod också för att fixa en bugg) lyste inte direkt upp tillvaron, erhöll glada tillrop eller större uppskattning. Inte direkt någon överraskning för någon av oss, men nu är det iaf gjort en gång så det kommer från erfarenhet! :-)

Dag 2

Andra dagen förde jag inte anteckningar då jag hoppade fram och tillbaka mellan blixttal och labbet där vi fick den enkla Continuous Delivery-pipeline att snurra (Spring Petclinic, Puppet, Fabric, Razor, VMware, Python/bash, Jenkins). Bamboo, Go och Team City plus en mindre hög andra saker att kika på eller göra bättre fanns på ena kylskåpsdörren (bra yta för statisk plast = mobil whiteboard).

Gabriel Falkenberg: Jakrakning på rätt sätt
Mycket underhållande och träffsäkert. Om du skall raka jak, raka rätt jak, raka den rätt, … Klart topp 3 även denna.

Adam Killander: Fundamentalistisk förvaltning
Bra teatralisk berättandestil om förvirringen kring nyproduktion vs förvaltning. (Nyproduktion kanske finns första sprinten på ett nytt projekt, men inte efter det.)

Någon gång under dagarna gjordes en jämförelse mellan Legacy inom och utanför mjukvaruvärlden – i det ena en tillgång med värde, i det andra ses det mer som en belastning och kostnad.

Återkoppling från en Coding Dojo

Det är otroligt kul och inspirerande att se Coding Dojos tas emot så väl ute bland de företag jag besöker. Att det är väl mottaget bland utvecklare är uppenbart och kan bl a förklaras med “Code wins arguments”. I “gamla” inkörda team där diskussioner gått i stå och nötts länge kan helt plötsligt helt ny dynamik uppstå. De “gamla” argumenten som gått fram och tillbaka men bara varit abstrakta och teoretiska skall helt plötsligt omsättas i kod, med/inför kollegorna och “helt plötsligt” går det från abstrakt till konkret och inte bara fåtalet engagerar sig och har en uppfattning, utan flertalet.

De Coding Dojos jag driver hos kunder är just detta – praktiska övningar med ett mål eller en poäng. Ingen föreläsningsserie man sitter och nickar igenom och sedan släpper vind för våg. Med riktiga övningar, där alla deltar och skriver kod själva ökar deltagandet, engagemanget och det kritiska granskandet.

Eftersom det ofta uppstår diskussioner med uttryck som “jag brukar göra såhär”, “oj, så har jag aldrig gjort, eller tänkt” så är det viktigt att det inte finns lönesättande chef(er) på plats. Om deltagarna är rädda för att säga fel och börjar väga sin ord så försvinner en stor poäng med dojon. Jag försöker få alla att vara spontana med hur de tänker, att exponera hur de jobbar utanför dojon så att de kan få konstruktiv feedback på sitt arbetssätt. Lönesättande chef och/eller beställer behöver givetvis återkoppling också. Här följer ett exempel från förra veckan.

Hej Kund!

Efter lite hackiga, trevande steg med första övningen tyckte jag mig se en enorm skillnad till tillfälle två. Det märks att flera utvecklare försökt sig på det vi övade i vardagen! Jag tror mig se att så gott som alla utvecklare har fått en ny infallsvinkel till hur de ser på sin kodskrivning och den synen utvecklade vi med en mer realistisk övning ihop med mockning. Det var mycket bra frågor som dök upp, vilket tyder på att de är engagerade, intresserade, verkligen försöker anamma en annan kodordning och har en sund kritisk inställning till vad de gör själva (det är ju inte jag som skriver koden under övningen – jag bara guidar och ger tips)!

Övning 1:

Vi tog en enkel basövning (String calculator).
Vi introducerade red-green-refactor, Arrange/Act/Assert, bottom-up.
Vi tog baby steps bokstavligen med 1 minut som tidkrav att gå från röd till grön.
Vi såg triangulering som ett sätt att driva fram funktionalitet.
Grå zon: “täcker testen all funktionalitet? om inte, har vi använt test-driven utveckling?”

Övning 2:

Vi tog in en ny, ganska stor uppgift som är mycket mer realistisk (tagen från produktionskod).
Vi lade på ett nytt moment/tanke i form av en “testbacklog”. (Verkade vara en ny idé – diskuterade VAB-scenariot och vikten av att kunna dela kod ofta.)
Vi lade på mockning med Mockito. (En del var redan bekanta med Mockito.)
Grå zon: “ett par antydningar till att ändra kod utan att testen uttrycker den funktionella ändringen i koden”.
Vi refaktorerade kod lite oortodoxt (utan test, utan undo/bortkommentering).

Det var mycket motiverande för min del att se utvecklingen i teamet, det var en helt annan “mognad” i TDD-tänket och ett bra driv/bra dialoger. Parprogrammeringen såg bitvis fullständigt klanderfri ut – mycket kul att se! Nästan all kod drevs fram från test (två, tre tillfällen fanns antydan till att skriva kod som inte var testdriven/täckt av test).

Utvärderingen i slutet bjöd mer på kod- och designdiskussioner (jag vill aldrig avbryta sådant) så vi hann inte “utvärdera” så mycket, men på tavlan skrev jag upp:

+ bra frågor
+ bra övning
! refactoring gjorde koden mycket mer läsbar
! smidigt med @Mock
? Använda TestNG nästa gång

Mitt förslag är att vi nästa gång utvecklar i flera par parallellt (en dator per par med Eclipse är vad som behövs), lägger på Clean Code-aspekter och använder samma uppgift och ser hur vi kan få koden att se ut på olika sätt.

Presentation om testdriven JavaScript-utveckling

Igår talade jag på JavaForum om tre verktyg (JsTestDriver, JsHamcrest, JsMockito) som möjliggör en godkänt komfortabel miljö för testdriven utveckling av JavaScript-kod. Jag har slangat upp presentationen på SlideShare och koden som det refereras till finns på GitHub.

Jag skulle kanske tryckt lite mer på att det i min mening inte lämpar sig för end-to-end-tester, typ ATDD eller BDD – där är fortfarande något som har Selenium i botten kung (om man gör det rätt).

Js Test Driver, JsHamcrest, JsMockito

Kata: Authentication Filter in Java EE

This is an exercise I’ve used to demonstrate how awkward unit testing can be if you can’t use a mocking framework. It’s an almost real work life situation (disclaimer: you should perhaps use container based authentication and JAAS) where we’re using API:s in a Java EE Server, adding two collaborators and then writing the logic combining it all.

No group has (yet) completed the entire task within 90 minutes – you might want to start/focus on using one collaborator only (I suggest the LDAP collaborator).

Originally posted on codingdojo.org.

When cleaning up a folder at work, I found this old document – it’s some form of a logical flow chart of the filter to write.

Here we go …

Background

In this Kata, your a programmer at ABC Corp and you’re making a new web app from scratch. After the head architect started working on this, it’s now up to you to make sure these tasks are completed:

  • allow authentication using request parameters
  • all authentication/login attempts should be verified agains LDAP
  • successful logins should be recorded in the single sign on registry

However, you’re not the only programmer (team) adressing this web app, so the LDAP is written by another team and what you have right now is this interface:

 public interface LdapAuthenticationGateway {
   boolean credentialsAreValid(String userName, String password);
 }

and the single sign on registry is also written by another team, leaving you with this interface:

 public interface SingleSignOnRegistry {
   boolean tokenIsValid(String token);
   String registerNewSession(String userName);
   void endSession(String token);
 }

Your job basically is to write one or more javax.servlet.Filter that handles incoming requests and act according to whether there’s a cookie with a SSO token, username+password parameters etc.

It’s assumed that there’s some form of DependencyInjection framework in place – to get a handle to the SingleSignOnRegistry or the LdapAuthenticationGateway, you’ll simply have to provide something like:

 public void setSingleSignOnRegistry(SingleSignOnRegistry registry) {
   ...
 }

About this kata

This “real life” scenario has been used to demonstrate how mocking (using Mockito) can be useful. We’ve combined it with BDD and JDojo@Gbg will try to practice TDD using this kata (without mocking) next time around.

(“Real life” is quoted – proper JEE authentication should be tied into the container etc etc … The point with this exercise is that it’s fairly easy to explain how it should work and what needs to be done here with “real” Java EE API:s, and then focus on the “How to develop” aspect (TDD), but also to show/talk about the difference between mocking and stubbing.)

JsTestDriver

Most of my code writing time last week writing was spent in JavaScript land (or ECMAScript, wonder it the most commonly used name will ever change). I was to write a small templating package and had to write some new stuff and set out to use JsTestDriver and after a few minutes I was up and running in Eclipse.

The idea is OK I guess – run tests and production code in the same environment it will run in when deployed. There are a couple of cons to JsTestDriver (used through Eclipse) though:

  1. if you’re configuration file doesn’t include the test file you’re trying to execute, there’s no clue to what you’ve done wrong – the panel in Eclipse will just show the green bar and 0/0 tests run.
  2. if you have syntax (or construct like) errors in your unit under test, you’ll get the same behavior as above
  3. sometimes you’re served a cached version of (some of) the JS source files – hence there’s a button to “refresh browsers” and it’s sad that it has to be there and that you actually have to use it
  4. sometimes the engine gets into some strange state where it dryRuns the tests instead of actually executing them

Apart from that, its behavior is quite predictable. Minor issues:

  1. running a test complete locks Eclipse’s UI thread
  2. a Rerun quick command option would be great (Ctrl+3)

JsHamcrest

Another minor issue is that the “index” of JsHamcrest matchers is really hard to get an overview of. Whenever I wanted to use a certain type of matcher, it was really hard to quickly tell from the documentation if it was there or not. Go see for yourself and look for a matcher that mathes any object for instance.

JsHamcrest.Integration.JsTestDriver();
# get a list of matchers:
curl "http://jshamcrest.destaquenet.com/modules/matchers.html" | grep "dt id" |cut -d '"' -f 2 |cut -d '.' -f 3

JsMockito

JsMockito works really nice. The only thing that could’ve been better is the integration with JsTestDriver: when a verify step fails, you’ll get a good error message but you don’t get the typical feedback as from which line the verify/assert that failed was on. Not a big deal since you see which test that failed.

JsMockito.Integration.JsTestDriver();

Böcker om Scrum mm

Jag brukar ta med mig ett par böcker när jag håller workshops eller predikar om ett ämne jag håller nära hjärtat. Eftersom det ofta är svårt att hinna svara alla frågor eller gå på djupet på alla ämnen så brukar det uppskattas att jag lämnar referenser till böcker (eller bloggar) där man kan gräva sig djupare. Efter fredagens “Agile Injection” fick jag frågan om att skicka över listan med böcker jag hade med mig då. Här är den. :)

Följande utmärkta böcker rekomenderas varmt

Agile Project Managemeng with Scrum, Ken Schwaber
9780735619937
Appendix A är Scrum i ett nötskal (~10 sidor). “A book of case studies about Scrum”. Som Knibergs bok, fast mer polerad och mindre detaljrik.

Scrum and XP from the Trenches, Henrik Kniberg
9781430322641
125 sidor med erfarenheter: how we do testing, how we do sprint backlog, how we arrange the team room, how we do daily scrums, … Man bör kunna grunderna (helst prövat på) för att fullt uppskatta boken.

Clean Code, Robert C. Martin
9780132350884
Utmärkt genomgång av hur man renskriver kod, och varför. Ögonöppnare för många.

Working Effectively with Legacy Code, Michael C. Feathers
9780131177055
Utmärkt bok om “refactoring” – hur skall man attackera legacy code (dvs kod som inte täcks av automattest).

Mycket bra är också

The Pragmatic Programmer, Andrew Hunt, David Thomas
9780201616224
Insiktsfullt om kärnan av systemutveckling – hur jobbar en “bra” utvecklare (eller hur blir man).

Följande böcker har inte samma nivå, men är fortfarande bra.

Extreme Programming Explained, Second Ed, Kent Beck, Cynthia Andres
0321278658
Kent Beck försöker förklara Extreme Programming. Lyckas sådär.

Test-Driven Development, Kent Beck
9780321146533
Kent Beck visar upp TDD i praktiken med riktig kod i tre kapitel. En bra praktisk genomgång.

Andra har uppskattat

User Stories Applied, Mike Cohn
Agile Estimating and Planning, Mike Cohn
Agile Software Development with Scrum, Schwaber, Beedle

och lite utanför ämnet

The Mythical Man-Month, Frederick P. Brooks, JR
9780201835953
Insikter kring mjukvaruutvecklingen från 1975, med uppdatering tjugo år senare. Intressant om man tycker utveckling av systemutveckling över tiden är intressant.

Ämnen för Java-TDD

Tittar på att gå ett steg längre med TDD-workshops och lämna de grundläggande ämnena. Följande har efterfrågats:

  • testning med/av legacy code
  • vad är bra respektive dåliga test
  • funktionell eller acceptansdriven testning (ATDD)
  • beteende driven utveckling (BDD)

Egna saker jag själv skulle vilja gräva lite mer i och ägna ett par timmar åt:

  • hamcrest (matchers)
  • dotmesh (methods)
  • making EasyMock suck less
  • making Mockito suck
  • easyB
  • Fitnesse

I allmänhet så saknar jag en diskussion om hur lättredigerade test (wiki?) versionshanteras ihop med koden de testar eller är skrivna mot. Detta är ju högst intressant när man går in och gör en hot-fix för en produkt som rört sig mycket under ett år, och en kund som har produkten i drift sedan ett drygt år tillbaka vill sin fix. Hur kör man samma testsvit som man hade för ett år sedan på ett enkelt sätt? Hur är egentligen inte svårt. Jag har bara inte sett många bra lösningar, ännu. TextTest, xUseCase och liknande plain text-ramverk är en bra lösning. Frågan är bara om testen är tillräckligt tillgängliga för ATDD – hur får man kunden att känna att det är hans/hennes test?