In 2010 Kent Beck, the inventor of Test-Driven Development, recorded a course in the “Pragmatic Screencasts” series.
After ten years, I had the chance to follow the four-set videos, finally! 🎺
In the 2-hours session, Kent develops a small Java client for Tyrant DB (a simple and very efficient key-value store).

While watching Kent’s screencasts, I took some notes and made a couple of reflections, that I want to share with you.

I tried to put every Kent sentence as a quote, to be more understandable.
Otherwise, I tried to express my understanding of his recommendations.

The test list ☑️

First step in TDD…


Stanchi di lunghe e infruttuose call di “brainstorming”? Provate il potere delle breakout rooms!

Quale voto date all’ultima retrospective alla quale avete partecipato? O all’ultima code review?

Quale voto date all’ultima retrospective alla quale avete partecipato? O all’ultima code review?
Quale voto date all’ultima retrospective alla quale avete partecipato? O all’ultima code review?
Photo by Magnet.me on Unsplash

Come technical coach, mi ritrovo spesso a partecipare a sessioni di brainstorming o planning (code review, sessioni architetturali, retrospectives, backlog refinement, etc) con tante persone, dev e non.
Una delle conseguenze che la pandemia di COVID-19 ha portato nel nostro lavoro è che tutte queste sessioni sono per forza di cose remote; siamo insomma diventati — volenti o nolenti — degli animali da videocall, e passiamo con nonchalance da una call Zoom/Teams/Google Meet/… all’altra.

Uno degli effetti più negativi che ho notato passando da sessioni co-localizzate a…


How many times did you fight to give a test a good name? After all, as Michael Feathers said, tests are another way of understanding our code.

Here’s a story of two programmers and their struggles with naming a test case. More importantly, it’s a story about how sometimes struggling with names can be a symptom of a very different problem.

co-written by Pietro Di Bello and Joe Bew

A Friend in Need (1903) — by Cassius Marcellus Coolidge

Over the last period, we are practicing together the Poker Hands Kata, using TDD and following a strong “slicing strategy” as explained here. In our “simplified” world, a poker hand is…


Add code coverage to a gradle project

In order to have code coverage measurement enabled on your gradle project, you have to just add the jacocoplugin to the build.gradle “plugin” section:

adding “jacoco” plugin to Gradle “build.file”

When you now run ./gradlew test or other test tasks, you’ll see that the build folder now contains a jacoco folder, with a *.exec type of file (e.g. test.exec).

This *.execfile contains a binary code coverage report of the test run.
Nothing you can really read by yourself :-D

Fear not, for gradle is with you, giving you a couple of shiny new tasks:

  • jacocoTestReport: the most important task…


“As part of learning, we read books, blogs, etc… What was the most influential book you read in your journey as scrum master, and what was the most significant lesson you took from that book?” — Vasco Duarte

“Lean Software Development: An Agile Toolkit” by Mary and Tom Poppendieck

This book taught me how deeply are related and interconnected all the values, principles and practices of XP and Scrum with Lean.

I learned that what I did every day using agile principles is something that has a reason beyond the world of software, that has roots in principles that can be valid in many contexts like organizing the work in an hospital, preparing dishes in a restaurant…

I learned what is a pull system, what is a value stream map and how is applicable even to map the flow of production of a can of coca cola.

I learned…

Pietro Di Bello

I’m an XP software engineer, an Agile Coach, a trainer and a speaker living in Trento, Italy.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store