Joan León If tests are a fundamental part of your structural pattern in software development, it’s most likely that whoever works on the project will continue adding tests. We’re experts at copying, pasting and modifying. Let’s take advantage of this thing we know how to do so well. - Carlos Blé
Test-Driven Development
I continue deepening my learning and internalizing the foundations of software development to be able to feel comfortable1 when I face a new challenge, whether in a new project or an existing project. As developers we improve in every project we participate in, we learn new techniques, new functionalities from new language versions, new patterns. I’m the first person to put my hands on my head when I remember how I’ve programmed some solutions in past development.
When we start to be interested in learning from the most relevant people in software development and best practices, we encounter acronyms (by the way, I love deciphering the meaning of acronyms) like SOLID, XP, TDD, BDD or concepts like Clean Code.
Today I want to talk to you about what’s hidden in the TDD acronym, it means Test-Driven Development. Well, I don’t have the level to talk to you about TDD, since I’m in the learning process, but I do want to talk to you about a book that has helped me a lot to understand the foundations or what’s more important, to know the advantages of developing with this methodology. Yes, it’s a methodology, it’s not a solution to solve any scenario we encounter.
Agile Design with TDD
The book I want to recommend is Diseño Ágil con TDD (Agile Design with TDD) by Carlos Blé. This is the text Carlos chose to define the book:
Test-Driven Development is one of the most relevant practices of the XP (eXtreme Programming) method developed mainly by Kent Beck and Ward Cunningham in the late 90s. This book presents a modern, practical and updated approach to TDD with different programming languages, suitable for anyone who develops software, whatever type it may be.
But I’d like to share what else I found in the reading.
Disclaimer
I know Carlos in person, I’ve attended some of his talks, he attended one of my talks and gave me valuable feedback, I had him as a teacher in training, he’s been my tour guide in Tenerife (thanks Carlos for that day), I’ve eaten with him and I’ve even witnessed his fight against animal abuse. I say all this because I believe knowing him in person has greatly conditioned my reading. In each paragraph I seemed to hear him with his calm and peaceful voice.
My Opinion
The book starts with a definition of what Test-Driven Development is, and I liked that from the first chapter we can see code examples to familiarize ourselves with TDD implementation.
I’m a frontend developer, so when I see code snippets in languages like Kotlin it’s hard for me to internalize the examples, but the description we can find helps a lot with comprehension. And it’s been very helpful to see that in later chapters there are implementation examples with JavaScript.
It’s been a surprise, and an example of humility, to read how someone who’s a reference in the Agile and Crafter community makes use of StackOverflow to search for a regular expression that would help him improve a test.
The text is full of references to books and reference people in the Crafter community. This and the ease of expressing complex concepts in a simple way, reveal Carlos’s years of experience on the subject.
It helps a lot that he explains how he solves problems, sometimes beyond the development of the program he’s working on. Reading the following text has opened my mind to the method of how to approach problems.
Sometimes I write tests just to get quick feedback, as a REPL (read-eval-print loop), to resolve doubts that arise about the language, library, framework or integration of various system artifacts. As soon as I dispel doubts and learn about the system, I delete those tests. That is, not all the tests I write remain as part of the test suites that provide code coverage, sometimes I use them to get feedback and destroy them when I get it.
I’ve underlined many phrases, even paragraphs like the previous one, that in some way or another have marked me. I loved the chapter Styles and Errors, where he collects various styles and helps us detect common errors and how to solve them.
Continuing to learn and resolve doubts about TDD goes beyond the book’s pages, as it gives us the option to participate in a support group, which is growing little by little.
Giving an opinion or recommending a technical article, book or talk is, I think, the same as recommending a (non-technical) book, movie or series. Not everyone will like it, most likely many of the people who follow your recommendation won’t end up seeing what you saw. In this case, this book has helped me a lot to understand concepts I was applying with the “copy & paste” practice without really understanding what I was doing. And that’s why I wanted to share my opinion about it.
What’s become clear to me is that to have an opinion on any topic, you have to document yourself, whether through reading, videos, podcasts, etc… and you have to do it consciously. Having the vision of several people will help us draw our own conclusions.
So, I already have the next book ready to continue diving into the world of testing, Frontend Testing by Iago Lastra.
References
- 1 Perhaps someday I’ll write about these words.