Chemaclass - tdd

bashunit

2024-10-30T00:00:00+00:00

bashunit is a lightweight, easy-to-use testing framework for Bash. Features like parallel and snapshot testing, test doubles, data providers, and tons of built-in assertions.

Backed by clear docs and an active community, it’s become a favorite for reliable Bash testing. What started as a simple dev frustration has grown into an open-source tool that makes testing in Bash a lot easier and fun.

The story behind bashunit
Why create another testing library?
How is it nowadays?
Core features
Lightning tech talk

The story behind bashunit #

The journey to create bashunit started from a simple frustration: I worked with a team where each commit had to start with the ticket name. Since I like working in small steps with quick, iterative commits, adding the ticket key and number to every single commit became a major hurdle, slowing down my development flow with unnecessary friction.

After a few days of this, I decided to automate it. Git has a helpful hook, prepare-commit-msg, which allows you to alter commit messages before they’re finalized. I created a Bash (script) that automatically fetches the ticket key and number from the branch name and inserts it into the commit message, making my process smoother and more efficient.

As someone who values continuous improvement, I began adding more features to this script. However, it became clear that maintaining and testing these changes manually was taking too long and was prone to error. To make development safer and more efficient, I created an assert(link) function, enabling automated tests that verified the expected behavior based on script output.

The assert function allowed me to define multiple assertions in a separate file, making it easy to validate that any refactoring of the original hook maintained the expected behavior. If a change inadvertently broke existing functionality, it would instantly flag the issue, letting me know right away that something needed fixing. This setup provided immediate feedback and helped ensure that any updates to the script didn’t disrupt its intended logic. For example:

In the example above, you’ll notice that I execute the actual “SCRIPT” as the second argument in the assert function, comparing its output to the expected value provided as the first argument. Here, we have two test cases, each exporting TEST_BRANCH to simulate how the commit message would vary based on the branch name. This setup emulates real behavior, allowing us to test how different branch names affect the commit message formatting. More examples here.

I decided to separate the assert function from the test cases, as shown here, to keep things modular and reusable. Then, I created a runner to execute each test case independently, reducing test interference and improving reliability. You can see that setup here. This structure made automated testing easier and refactoring safer.

This was a great improvement because it made it easier to separate test cases from the logic of the test runner itself. This clear structure has simplified both creating and managing tests.

Now the tests were organized and I got an idea:

## Follow-up idea
Separate the testing logic into another repo, 
so it could be reused anywhere.

And so it began. At the time, I didn’t know much about Bash or the best ways to use a Bash project as a dependency. But I knew I could start by using a Git submodule, even though I’m not a huge fan of them.

On September 4, 2023, I launched version 0.1, which featured a working runner and a single assertion function: assertEquals. Later, version 0.2 was released, allowing ./bashunit to be a standalone executable, runnable from any folder. Here’s how it looked back then:

I shared the project with a few friends who quickly jumped in to help with documentation, the website, additional assertions, snapshot testing, and key decisions. To emphasize its open-source spirit and community ownership, I moved it to an organization we created specifically for sharing OSS projects, making it a truly collaborative project rather than an individual one.

Why create another testing library? #

I know now that other Bash testing libraries exist. But when I started with bashunit, I wasn’t aware of them, and frankly, I’m still no Bash expert. By the time I learned about these alternatives, it was already too late, bashunit had gained enough momentum and excitement to keep going strong.

While those other libraries may serve specific use cases, use modern Bash, or be developed by more seasoned Bash developers, bashunit aims to set itself apart by offering a great developer experience, shaped by years of working with various testing frameworks.

I was asked about the differences on September 7, 2023, and here’s my response: Question: Difference to pgrange/bash_unit.

How is it nowadays? #

Today, you can install bashunit via curl, Homebrew, MacPorts, by downloading the latest GitHub release from GitHub, or even by building it yourself from source. Completely open-source.

The project is written in Bash 3.2 (from 2007) since that’s the default version on macOS, even now, in 2024. This compatibility means bashunit runs smoothly on that version, and I plan to maintain support for it.

To ensure quality, we test each feature with unit, functional, and acceptance tests, making bashunit its own “first user” of every new feature. We also have several CI workflows using GitHub actions that run tests on different platforms to check compatibility and confirm everything works as promised.

In June 2024, bashunit was integrated in PHPStan for their end-to-end tests, enabling the use of bashunit’s assertions independently of its runner. This flexibility turned out to be very useful.

Last summer, I was invited to speak about bashunit at the International PHP Conference in Berlin, alongside Manu, another contributor. This project has opened doors and led to a lot of gratitude from users who appreciate the work we’ve put into it.

Core features #

bashunit includes classic lifecycle functions like set_up, tear_down, set_up_before_script, and tear_down_after_script.

It also supports a wide range of command-line parameters and configuration values. Some of my favorites include:

--parallel
--filter
--stop-on-failure
--verbose

We also provide data providers for running the same test cases with different inputs.

For test doubles, bashunit offers mocks and spies. These work within the same process as the test, but currently, they don’t work across processes, an area for improvement.

Powerful snapshot testing is included, making it easy to verify command or script outputs over time.

bashunit offers a large set of native assertions for test cases, including:

assert_same
assert_equals
assert_contains
assert_matches
assert_string_starts_with
assert_array_contains
assert_successful_code
assert_general_error
assert_file_exists
assert_file_contains
assert_match_snapshot

You can even create your own custom asserts to extend bashunit’s capabilities.

With over 25 contributors and more than 325 stars on GitHub within just a year of spare-time development, I’m genuinely proud of what this project has become.

Lightning tech talk #

Recently, I presented a lightning tech talk at a hackers’ meetup, demoing bashunit to an audience of over 100 people. It was an incredible experience to share this tool with such an engaged crowd!

bashunit original logo designed by Antonio.

Effective Pair Programming

2024-03-28T00:00:00+00:00

What is pair programming? Two people working together on the same problem, at the same time.

It is not about one person showing off their skills in front of another, nor one person afraid of making mistakes due to an impostor syndrome.

Each person will have a role:

Navigator: he will pay attention to the bigger picture; eg: architecture, relation between collaborators, object design, etc.
Driver: she will pay attention to the small details; eg: naming, code conventions, writing syntax, object design, etc.

The pair could, and should, switch roles occasionally; eg: every X commits pushed, every 10 mins, … up to them.

Pair programming should not be considered a practice only for “seniors” to juniors, but regardless of the team members’ experience level.

It is about the collaboration flow, the quality communication, the absence of feeling judged, and the idea of welcoming vulnerability with your peers, knowing they will support and help you.

It is about constantly challenging each other, seeking the most pragmatic solution while keeping it simple. Always looking for quick feedback when speaking to each other, but also on the solution you agreed to implement and its direction.

It is about the short, quick, and immediate feedback loop while talking to your partner, who reviews your code on the fly. You can guide as a navigator or help the driver validate their ideas in a broader picture.

It is about the constant sharing of knowledge atmosphere by default, reducing bus-factors and silo-knowledge areas to the maximum. Increasing the focus by having two minds working on the same task simultaneously.

It is about team cohesion and sharpening the feeling that we belong. When we understand each other’s strengths and weaknesses, we will realize how much we can help each other grow.

How can you practice pair programming? #

Pair programming can be done in different ways:

You can start and finish a task with pairing. You can time-box it to 30, 60, 90 minutes. Either way, it is recommended to have pauses in the middle - Pomodoro.
You can start the task together and stop when one of your peers feels confident enough to continue alone.

It is up to the team, and the task in context, to decide when and how to apply pairing to get the best out of it.

This does not mean you must constantly work “no matter what” in pair. This is not about creating rules; on the contrary, it is about embracing this practice to the point you feel confident to choose when and how to use it to get the best out of it.

Pair programming might become one of the best tools in your team toolbox for daily interactions. Not because you read it somewhere but because of the benefits you and your team will find.

Common Patterns #

Different strategies for effective pairing #

Driver-Navigator: One person is driving the code (with the keyboard), focusing on the detail aspect of the task itself. The other is a navigator (no keyboard), having a more abstract picture of the task in mind.
Ping-Pong: Frequent switching driver-navigator roles in small interactions, e.g., every N minutes, every N commits, etc.
Backseat driver: The navigator engages actively with the driver.
Tourist guide: The navigator passively learns with the driver.

Anti-patterns while pairing #

The silent partner: The navigator is not participating, and they are being silent.
The solo act: The driver ignores all inputs from the navigator.
Distracted pair: The pair does not focus on the problem to solve.
The Dictator: One person is telling what to do, ignoring the input from the other.
Philosophical pair: The pair is bikeshedding into irrelevant topics.
The code war: The pair does not reach an agreement and starts an unnecessary war, which wastes time and effort.

Want more? Check this out: Learning Through KATAS

The takeaway #

Pairing is not a rule to enforce, it is a tool to reach for. Use it when the task is complex, the knowledge is siloed, or the stakes are high. Skip it when the work is trivial. The goal is never “always pair”, it is better software and a stronger team. Pick one real task this week, pair on it, and switch roles often. The benefits show up faster than you expect.

How to Test Private Methods?

2023-10-20T00:00:00+00:00

This is a question that I have encountered with some frequency for a long time. So I thought I would put together my thoughts on the subject here.

Short answer #

Never.

Long answer #

Never ever.

What if…? #

If you really want to test a private method, consider extracting that private method logic into a separate class, and write a unit test for that class’ behavior.

For this one, I was inspired by Fran Iglesias’ original post.

Dedicated QA Teams in Software?

2023-05-17T00:00:00+00:00

This will be controversial, but let’s talk about the QA position. The hidden truth behind the lack of software quality and why this should concern you if you write software.

QA is a role, not a position #

As a software developer, when you write software, you are responsible for the quality of whatever you’re writing. A third person acting like QA could find that your solution doesn’t work like expected, but how come? You might argue they might catch edge cases, but how could that be possible if the software was already tested previously?

A software team’s final goal is to make the QA position useless because they should find nothing but well-working software. But how do you get to that point? How can we ensure that the software we write is working as expected and there is no need for a QA person in our team?

The hidden truth behind the lack of software quality #

Unfortunately, in our software industry, the demand for “fast, quick and dirty” projects ended up in poorly developed MVPs by simply applying patches and code over code with just manual testing checking happy paths, sometimes even ignoring edge cases.

“The deadline is in one week, so you better finish it on time!”

We don’t learn the importance of what automated testing can bring to our daily job, so we don’t take it seriously, and therefore, we don’t practice it enough. And, for that exact reason, because we don’t practice it, we don’t know how to perform it properly. Yes, I am talking about writing automated tests that prove the behavior of your software!

Our inability to write testable code results in software that is hard to test, and thus we delegate testing to other third parties shifting the responsibility for the overall end quality of the product or service we write.

Practice makes the master #

You must learn and apply proper testing techniques when they make sense. How and when effectively use test doubles, prepare solitary or sociable tests, which compromises and reasons backup your mind when choosing one or other paths toward your testing strategies?

You are the latest and main responsible person in charge of your knowledge, so you better invest in yourself because no one else will do it for you.

Look at everything you do as an opportunity for learning. Practice and get better by default at everything you do.

If you don’t know how to start, here is my favourite tip: you can always practice and improve your testing skills using code-katas. Read more about this topic here.

Nice theory, but… why bother? #

Manual testing is, of course, necessary. It is another testing strategy that I am not blaming or attacking. We might still need a dedicated person in charge of discovering what new features we want to build to satisfy our clients. But this blog-post is not about that position.

It is all about shortening the feedback loop. If you can write software to work in specific ways, can’t you write automated tests to prove that the software you wrote behaves the way you expect?

If you have covered with automated tests the behavior of your software at any level that makes sense, what’s left for a dedicated QA person?

Next time you think about “We need a QA person to test this,” try the exercise of thinking instead, “How can I write an automated test that verifies what I would expect if a QA person were checking this?”

And that’s how you change the “full-time QA position” into a “role mentality for everyone that writes software.”

Code never lies and never forgets; once it’s written and automated in your pipeline, you can run it anytime at zero cost.

Interview About XP and Agile

2023-01-09T00:00:00+00:00

My interview with devm.io regarding Agile and Extreme Programming.

devm.io: We talked to Chema, a software developer and an Extreme Programming expert, about his favourite topic and his upcoming live event Update Your Team To Be More Extreme.

Could you tell us a little about yourself, who you are, and what you do? #

Chema: My name is Jose Maria Valera Reales, but everyone calls me Chema. I’m originally from Spain but have lived in Berlin since 2015. I’ve been working as a software developer since 2013. In recent years, I have focused on achieving excellence and figuring out how to help my peers and, with them, the entire software community to improve in our profession.

I am currently a Tech Lead at Lautsprecher Teufel GmbH, where I work with the e-commerce webshop team. I also enjoy open-source software, so I enjoy creating pull requests for other repositories, and I also love when I receive pull requests from others.

How would you describe Extreme Programming? What makes it so “extreme?” #

Extreme Programming is the most straightforward and pragmatic approach to embracing Agile in your software team. It incorporates solutions based on values, principles, and practices. You don’t have to use or do everything, but rather whatever fits you and your team in your context. However, these are helpful general solutions that work better when combined.

From my experience, the word “extreme” can be misleading, but I see it as an opportunity to emphasise the difficulty of the fundamentals behind it. The critical point is realising that our “common sense” is not as “common” as we tend to think, nor the best practices for practical teamwork. Therefore, this is about pushing ourselves to extreme effectiveness, collaboration, and satisfaction while working with others.

You will host a live event on devm.io on the topic on January 19th. Could you give us a sneak peek of what your audience can expect? #

We will explore how a software team works nowadays, the common issues we encounter, and what solutions we could apply to improve our team routines. We will look for the real meaning of Agile, focusing on Extreme Programming ideas.

In addition, I will share some ideas to help your team create learning opportunities with concrete examples that any team can incorporate into their current work.

During the event, you will also tell us something about Katas. What exactly are Katas? #

The term “kata” comes from the repetitive movements done in karate that help you improve your fighting skills.

Why “code katas?” Because as a group, we need to practice more. Most of our learning takes place on the job, so most of our mistakes are also made there. And because we want to keep PROD, we’re reluctant to try new things.

Katas exist to help developers get the same benefits you would get from practice in any other profession. These simple, simulation exercises let you experiment and learn without the pressure of PROD. There are no right or wrong answers in any software kata: the benefit comes from the process, not the result.

There are katas to help you improve your refactoring skills (such as Gilded Rose Refactoring Kata by Emily Bache) or your testing skills (easy ones like Fizz Buzz or Roman Numerals, or more advanced ones like the Bank Kata by Sandro Mancuso). They’re also great for building confidence when programming with others, watching and practising different roles collaboratively, fostering team cohesion, etc.

What role do Agile methods play in software development for you? #

The very first question here is to define what Agile methods are. In the end, everyone communicates somehow, provides feedback to others, and simplifies to some level. Sometimes people have the courage to speak their minds and sometimes they do not, and usually, they try to respect their peers. So, for me, Agile is more about “how” you do certain things rather than “what” things you do.

Agile is a highly collaborative working process at any level, which might have a challenging learning curve at the beginning, but it pays off sooner than you might expect.

Which topic in the area of agile should receive more attention? #

Team building and embracing agility, starting with asking “why?” We need to challenge the status quo more often and ask ourselves why we work the way we do and how and what we could do differently to keep improving and never stop learning.

You can also read the interview from the original link: https://devm.io/agile/extreme-programming-agile.

Clean Craftsmanship

2022-07-11T00:00:00+00:00

The book is divided into three parts: the disciplines, the standards, and the ethics.

The 1st part is the most technical one. It guides you with TDD examples, showing how testing can help you to design your code.

The 2nd part is about productivity, quality, and courage.

The 3rd part is about how did we get here in terms of people who develop software, and our responsibility within our ethics about do no harm, integrity, and teamwork.

One of my favourite parts from the book:

Our software industry is wildly dynamic and changing; therefore, we must all be continuously aggressive learners.

How and when do you do this learning? If your employer provides you the time and space to do this kind of learning, then take as much advantage of it as you can. If your employer is not helpful, then you’ll have to learn on your own time.

Be prepared to spend several hours per month on it. Make sure you have the personal time set aside for it.

Yes, I know you have family obligations, bills to pay, planes to catch, and you’ve got a life. Okay, but you also have a profession. And professions need care and maintenance. I expect us all to be continuous aggressive learners.

Chapter 11. Courage - Continuous Aggressive Learning

Index #

Part I: The Disciplines #

Chapter 1. Craftsmanship #

Extreme Programming
Test-Driven Development
Refactoring
Simple Design
Collaborative Programming
Acceptance Tests

Chapter 2. Test-Driven Development #

Overview
The Basics

Chapter 3. Advanced TDD #

Getting Stuck
Arrange, Act, Assert
Test Doubles
Architecture

Chapter 4. Test Design #

Testing Databases
Testing GUIs
Test Patterns
Test-Specific Subclass
Humble Object
Test Design
Breaking the Correspondence

Chapter 5. Refactoring #

What Is Refactoring?
The Basic Toolkit
Extract Method
The Disciplines

Chapter 6. Simple Design #

YAGNI
Covered by Tests
Coverage
Design?
Maximize Expression
The Underlying Abstraction
Minimize Duplication
Minimize Size

Chapter 7. Collaborative Programming #

Chapter 8. Acceptance Tests #

The Discipline
The Continuous Build

Part II: The Standards #

Chapter 9. Productivity #

We Will Never Ship S**T
Inexpensive Adaptability
We Will Always Be Ready
Stable Productivity

Chapter 10. Quality #

Continuous Improvement
Fearless Competence
Extreme Quality
We Will Not Dump on QA
QA Will Find Nothing
Test Automation
Automated Testing and User Interfaces
Testing the User Interface

Chapter 11. Courage #

We Cover for Each Other
Honest Estimates
You Must Say NO
Continuous Aggressive Learning
Mentoring

Part III: The Ethics #

The First Programmer
Seventy-Five Years
Nerds and Saviors
Role Models and Villains
We Rule the World
Catastrophes
The Oath

Chapter 12. Harm #

First, Do No Harm
Best Work
Repeatable Proof

Chapter 13. Integrity #

Small Cycles
Relentless Improvement
Maintain High Productivity

Chapter 14. Teamwork #

Work as a Team
Estimate Honestly and Fairly
Respect
Never Stop Learning

I found this chat in YouTube where Uncle Bob talks about most of the topics form his book Clean Craftsmanship.

Listen out for:
* Quote & Intro - [00:00:00]
* Career Journey - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programmer as a Profession - [00:15:31]
* Craftsmanship - [00:18:45]
* Disciplines - [00:22:45]
* Disciplines: Test-Driven Development - [00:28:49]
* Disciplines: Refactoring - [00:34:31]
* Code Coverage - [00:39:02]
* Standard: Never Ship S**t - [00:42:35]
* Standard: Always Be Ready - [00:47:15]
* Ethics: Do No Harm - [00:50:00]
* Ethics: Estimate Honestly - [00:53:56]
* 2 Tech Lead Wisdom - [00:57:50]

The Path to Seniority in Software

2022-06-08T00:00:00+00:00

We all have been junior developers at some point. This is easy to know because it sits at the very beginning of your career. Your responsibilities were narrowed down by other peers who were looking after you.

At some point, after months or years, you got your promotion or another job, where you weren’t a junior anymore, but an intermediate.

An intermediate (also known as middle) is something between junior and senior. You know now that you are not a junior anymore, you know how to deliver value but yet you also have mixed feelings about seniority. You want to be a senior, but you don’t know how. There is no clear path to achieving this goal.

Wait for a second… there are actually two easy ways to get the senior title! You can get promoted as such in your company, or you can start a new position as a “senior” in another company, easy right?

Marketing and politics #

Unfortunately, the “seniority” level is very much polluted by marketing and politics. First, what does it mean “senior” in this context? In all the companies where I have been working (if not all) I have always been surrounded by people who claimed to be “seniors” when in reality only a few I would consider such.

Our senior label is inflated by companies needing experts on paper more than in reality, and this is a problem we need to deal with and speak about.

Seniority generally means more experience, but how do you calculate this? It is easy from a company’s point of view: more years in the industry. But, is the number of years you have been working really relevant in an industry that is constantly changing and evolving? Actually, this wouldn’t be a big issue if you have the software fundamentals well interiorized, but funny enough, I have seen these fundamentals in only ~10% of the seniors I have met across many years and several companies.

The fact that you have been working for 10 or more years doesn’t necessarily mean you are a “senior” with software. What else can we measure in order to identify if you deserve indeed this title?

It is not all about the money #

Let us be honest, senior titles are better paid than junior or middle positions. If you have the chance to get a higher salary because you got the “senior” in your job title, well, it wouldn’t be clever to reject it. But, independently of politics and marketing, we must address some seniority fundamentals to understand better what the word “senior” means in this context.

It is not all about the money, but also about the responsibilities that come with seniority.

Seniority fundamentals #

Being senior in our software industry is not about “the number of years of experience” but:

How well do you transmit your knowledge to others? Sharing what you know is a core task for a senior person.
How well do you collaborate with other people, including the PM/PO and other teams? Collaboration is crucial to creating a constant feedback loop.
How well do you work together with your peers? Pair-programming builds team cohesion and helps everyone become better.
How strong are your testing skills? Testing is tied to the quality of your work, and a senior should aim for an incremental design.
How well do you understand delivering value constantly in small chunks? The sooner you deliver value, the sooner you get feedback about it.
How deep is your technical knowledge of quality software and the trade-offs to get there? SOLID principles, clean code, TDD, refactoring as part of your daily job, low coupling, high cohesion, appropriate data structures, and choosing the right solution (KISS, YAGNI…).
How well do you adapt and cope with change? Change is inevitable, so we must learn to deal with it, especially the parts we cannot control.
How developed is your entrepreneurial thinking? Always keeping the organization’s goals in mind.

As you can see, there is no mention of concrete technology or years of experience. Why? Because technology is just an “implementation detail”, and experience comes by practicing and attitude, not by letting the time pass by.

Attitude is important #

We’ve got two persons:

A) a person who is working for 15 years, doing relatively the same every day, and without caring about his own skills. He just does what others tell him to do.

B) a person who is working for 5 years, challenging herself every week, trying different approaches when dealing with problems, and sharpening her own skills constantly.

Can you see the main difference? No, it’s not the 10 years difference of “experience” between them, but their attitude.

We wrongly understand that a year of experience must come with learning and knowledge, so we tend to use time as a measurement of seniority. But I argue that the “attitude factor” is equal or even more important. I have been surrounded by many people who call themselves seniors with 3, 6, 10, and more years of “experience” but lacking attitude, and you could clearly see this problem on a daily basis.

You need this combination to build yourself as a truly senior developer; time, experience, and most importantly: attitude towards improving your own skills and the ones that surround you.

Where to start #

Seniority is not granted, it is practiced. You don’t wait for the title, you build the behavior until the title catches up. Start small, and start now:

Teach what you know. Pick one thing you understand and explain it to someone this week. If you can’t explain it, you don’t own it yet.
Seek the uncomfortable. Volunteer for the task slightly beyond you. Growth lives at the edge of what you can already do.
Reflect on purpose. After each project, ask what you would do differently. Experience without reflection is just repetition.

The path is not a promotion. It is the daily decision to improve yourself and the people around you. Do that long enough, and the title becomes a formality.

Update Your Team to Be More Extreme

2022-02-26T00:00:00+00:00

Our software profession is constantly evolving; it demands a non-stop learning process. We must embrace the change in our industry.

We need to create spaces to get out of our comfort zone, so our cognitive brain can train and improve how to adapt to our surroundings, which are constantly transforming.

Why code katas, tech talks or research Fridays? #

The goal is to help create an environment that aims for continuous improvement towards looking for learning everywhere, all the time, as the core attitude for the individuals and the group.

Create learnings opportunities #

Schedule some time every X weeks for practicing together.

At the end of each iteration, or even 2 or 4 weeks, we celebrate and work on katas in pairs/mob for 2 hours. That space is also an opportunity to create an internal tech-talk presentation to share exciting knowledge with the team non-directly-related to our “regular daily business”.

The goal is to get out of our comfort zone, improving our recognition for change in general while learning other subjects regularly.

What is a code kata? #

As a group, software developers don’t practice enough. Most of our learning takes place on the job, so most of our mistakes get made there as well.

The term “kata” comes from the repetitive movements done in karate that help you improve your fighting skills.

Code Katas exists to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure in a production environment.

There are no right or wrong answers in any software kata: the benefit comes from the process, not the result.

Motivation #

Work on refactoring techniques.
Work on TDD examples.
Work on SOLID principles.
Work on live coding sessions.
Work on driver-navigator concepts.
Work on team cohesion.
Have fun while learning and practicing together.

If you’re interested in my thoughts about TDD and katas, I wrote a post about it not long ago: Test-Driven Development.

What is a tech-talk? #

Tech talks allow us to share some knowledge related to our tech industry with our team members.

It can be any FrontEnd, BackEnd, DevOps related. But I encourage also:

a new programming language that you are learning,
a summary of one book that you finished,
a new technology that you are studying or feeling curious about,
a piece of software that you would like to share and present thoughts about it,
a new tool that helps you to improve your productivity,
really: anything related to creating value or knowledge.

How can I present a tech talk? #

I wrote this article with some tips about how to improve your tech-talk. Some key questions that might help you to find something on your own:

What have you learned recently (in the last X months)?
What knowledge might be interesting to be shared with your peers?
Which aspect of yourself you’d like to improve professionally and/or personally?

Just one rule: Be curious and “embrace the change.”

Research and learning Fridays #

Block the last Friday of the month for research and learning purposes. The whole team will have a dedicated space for growth and experiment.

It’s crucial to build trust with your team, so you all know everyone will use this time as good as possible. Don’t micromanage this time forcing keeping a record in a wikipage with what everyone does in detail.

Although, it would be nice that the team shares what they do during this time, mostly to create transparency among themselves. A verbal announcement to the peers the day before, with their intentions. Even the day after with the learnings key-takeaways.

Summary #

You can help your team to be more extreme by helping with a dedicated team space for growth and experimentation.

Provide flexibility to experiment with these ideas as they see fit.
It is an opportunity for self-growth and learning at the same time.
It is, ultimately, up to the person and the team.

Do not micromanage this dedicated time. Focus on the outcome. Help your team to grow, and they will enjoy growing with you.

Tech Talk #

After writing this blog post (originally in Feb, 2022), I was invited to do a tech talk in different conferences about this topic.

London vs Chicago

2021-11-20T00:00:00+00:00

There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out).

Why London and Chicago? #

Two companies, one from London and another from Chicago, claimed to do TDD, but they were focused on different aspects. The London company was building software from outside-in, while the Chicago company from inside-out. Let’s see them in more detail.

Outside-in: London School #

It provides a behavior-driven approach to TDD. Starting from the outside of the application and working inwards to lower layers. For example, starting from the API/Controllers down to the application or domain layers.

PROS #

Behavioral Focused: this requires a lot of test doubles because you will test a lot of abstractions that don’t exist yet as you are creating a high level of logic first. You aren’t going to write dead-code but it will be easy to create tests highly coupled to the logic and therefore making refactoring a difficult task.
Command-Query separation: is a discipline for managing side effects. Either you perform an action (command) or you ask for a value (query).

CONS #

Fragile Tests: it tends to create tests that break easily because they are usually too coupled to the production code.
Difficult Refactoring: for the same reason as “Fragile Tests”, having tests coupled to production code make continuous refactoring very difficult and time-consuming.

Inside-out: Chicago School #

It’s an informal, exploratory, state-based approach of TDD. Starting from the inside of the application (usually the domain) and working out towards the APIs.

PROS #

Strong Safety Net: it tends to produce tests that are decoupled from the implementation. Enabling you to adopt a more experimental style of changing software without fear of breaking it. This is desired for continuous refactoring.
High Cohesion: as tests become more general, the production code becomes more specific. This promotes high cohesion, and with high cohesion comes loose coupling. Something that promotes high code quality: extensibility, maintainability, and testability.
Minimizes Test Doubles: building from the inside out requires fewer test doubles since you are building on top of the previously written tests. This helps to develop less fragile tests.

CONS #

YAGNI: it’s often over-engineering solutions, with code that is not really needed (or even used!) in the end.

London and Chicago work better together #

It’s not about choosing one over the other. It’s about understanding your context and driving optimization towards those qualities that need to be optimized. London and Chicago each have their pros and cons. The best approach to TDD is an integrated adoption of these two schools.

References #

TDD vs BDD

2021-09-25T00:00:00+00:00

These are two different techniques. The key to each of them is about the mindset and context of what you want to achieve.

BDD is a “test-driven feature” #

Basically, it’s a test-first driven development, where the main focus is ensuring the expected final behavior, and therefore the result of the software logic that you want to have at the end.

In BDD the main focus is the behavior of your domain logic that doesn’t exist yet. It is, from an abstract point of view, about the whole functionality and domain requirements.

TDD is about the rhythm #

Specify what you want.
Make it work.
Make it better.

TDD is not just about the already known “red-green-refactor” mentality, but mostly about the workflow that helps you understand the constant design decisions you are doing every time for every logic you are designing.

TDD is about constant feedback about your decisions.

In the context of OOP (to make the examples clearer), there are always tons of different ways to design your class:

What’s the name of this method’s class?
What are the dependencies or collaborators for this class?
How will this class behave when I use this other class inside it?
What’s the expected outcome of this method when I give these arguments?
etc, etc…

We ask these questions (and many more) every time, and we do give them an answer as well, but usually without any rational thinking or feedback about it. We just do what we think is “the best” at that particular time focusing on making something work, but is it enough to make it work?

The constant feedback loop #

Testing is not just a great tool because it gives you some safety-net so you can refactor with confidence, but also because it helps design a better system. How is that? Because before going for any solution, it makes you think about the decisions that you need to do. You are challenging yourself to understand the arguments of your decisions, and why A and not B is a better solution in a particular context.

BDD and TDD aren’t mutually exclusive, in fact, they can and should coexist. It depends mostly on the context of what you want to build and test.

BDD is about Test-First feature development. The goal is not how but what. The feedback loop is long because you will get “green” feedback once the feature is implemented and working as expected.

TDD is also another Test-First driven but, unlike BDD, it is about a shorter and quicker feedback loop.

First, you specify what you want. You think about the design of your class or method. Its name or signature. Its dependencies. But all of this by baby steps, one at a time.
Second, you make that little thing work in the simplest possible way.
Finally, you make it better. Because software is hard and complicated enough to make it right on the first try, so refactoring is a must to keep a system healthy. At this point, with a “green running test”, you can refactor and improve your logic safely.

The above is basically TDD, right, but… what’s so special about it? The constant feedback loop and design decisions that you need to make before you are actually writing the solution. This is the power of TDD.

Why so small steps in TDD? #

Theoretically you “must” write little steps for every iteration, but why? It’s all about the feedback loop. This is up to you, your expectations, and your experience with testing.

Resources #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

The complexity here is not about writing tests itself, but the habits that we have to change to create software that is easy to be tested.

The root of the problem #

Without (a solid) experience in testing, developers can have a hard time while trying to apply testing in general as part of their daily job. It’s not simply because of the topic’s complexity, but because they are used to writing code that is hard to test.

Writing tests for already working software (mainly when it was done without considering testing at all) translates as something boring, next to useless, usually accompanied by a lack of motivation, blaming the wrong subject in this context: “the tests itself are reducing my speed”.

In a domain context, if a piece of software logic is hard to be tested, the problem is not the test, but the code which wasn’t well written.

There are already hundreds of tutorials, books, and documentation about testing, but I can share my experience and how I do apply this great (and mandatory) philosophy in my daily work.

Test-Driven is based on this simple rule #

Instead of: design code -> develop code -> write tests.

It’s about: write failing automated test -> run failing test -> develop code to make test pass -> run test -> repeat.

The idea of driving your code by testing can be understood depending on the abstraction level of what you’re writing at the moment. You don’t want to create a wrong coupling between the tests and the code being tested. You want to test the behavior of your logic.

TDD is based on a loop of baby steps that helps you find patterns and guide your software design every little iteration with constant refactorings. It’s the best choice if you want to ensure the expected behavior of all possible paths of your logic.

The beauty of this is that you don’t need to know the full algorithm from the very beginning. Instead, you are discovering how your logic should be by expressing the desired implementation, step by step, on automated tests.

Considering writing tests for your software at the same time you’re writing it, will irremediably force you to write better software. Because you want to write software which has to be easy to be tested, and therefore it will end up with higher quality.

I already wrote another post about the relation between software quality and testing: The Art of Testing: where design meets quality.

Improve your Test-Driven skills #

The best way to learn Test-Driven is doing software katas. Try them alone and with others. Both are equally important.

Alone: to challenge your inner self without any distraction but yourself.
With others: pair-programming is essential in our job. Katas are the best tools to train our communication skills and learn together from each other.

What’s a Code Kata? #

Software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well.

Other creative professions practice: musicians play technical pieces, poets constantly rewrite works. In karate, most of a student’s time is spent learning and refining basic moves. These are katas.

What is the goal of a kata? What should we have at the end? #

Katas exist to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure of a production environment.

There are no right or wrong answers in any software kata: the benefit comes from the process, not from the result.

Tips #

Once you have resolved a kata, try it again in a few weeks or months.
Try to explore new solutions. Be creative in the process and do not rush.
When doing them in groups, they are not a competition to see who will accomplish more of the exercise.
The focus should be on the process, never on the result.
The true valuable outcome of any kata is the learnings that you (and your team) will get after talking about it and sharing your experiences.

You can find a lot of katas on the Internet. For example:

TDD is more as a workflow than a design #

“TDD is a design tool.” That’s what Sandro has said for years. But not anymore. After working with different teams and in different organisations, and also carefully inspecting how he works, Sandro changed his mind about the role of TDD in software design.

TDD in a nutshell; it’s about the rhythm.

Specify what you want.
Make it work.
Make it better.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— Kent Beck 🌻 (@KentBeck) July 30, 2021

Images original by Emmanuel Valverde Ramos.

To Mock or Not to Mock

2021-01-11T00:00:00+00:00

Mocking is useful, but “what to mock” usually turns out to be more complicated than expected if you don’t treat this carefully.

How to escape the mocking hell #

What is actually happening when we create a mock? Which types of mocks are there? Is mocking good or bad? Well, as always, everything depends on the context. And here we will consider some of the main situations about when to mock and when not to mock, but especially why.

What happens when you mock something? #

First, we should define what is a mock:

In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when it is impractical or impossible to incorporate a real object into a unit test.

Mocking makes sense in a unit testing context. An integration test should go through the real implementation checking the integration between multiple units, which are even allowed to talk to the DB or File IO: infrastructure code. Therefore we should agree that a unit test is a fast and deterministic test that doesn’t rely on external dependencies and doesn’t require any special context to run.

Mock objects meet the interface requirements. In consequence, they allow us to write and unit-test functionality without calling complex underlying or collaborating classes.

A mock is a test double that stands in for real implementation code during the unit testing process. It is also capable of producing assertions about how it was manipulated by the test subject during the test run.

I strongly recommend you to read this post if you want to get into the details of why Mocking is a code smell (Topics like these: What is a mock? What is a unit test? What is test coverage? What is tight coupling? What causes tight coupling? What does composition have to do with mocking? How do we remove coupling? and more!)

The problem with mocking #

When you mock you are overriding the logic of the mocked class. The real logic is getting hidden behind the scenes and there is actually where bugs love to live. Consider that:

The mock may have attributes, methods, or arguments that the real object doesn’t.
The mock’s return values may differ from the real objects’ return values. For example, it may return a different type of object that has different attributes.
The mock’s side effects and behavior may differ from the real objects’ ones. For example, maybe the mock fails to raise an exception when the real object would raise it.

Alternatives to mocking #

“Are you saying that mocking is bad and we shouldn’t mock?!” No.

It depends on what you are “overriding”.

Is your business domain logic what you are mocking? Then it’s wrong.
Is the connection to the DB what you are mocking? Then it’s right.

It depends on the context of the logic and where that logic belongs.

Is it part of your business domain logic? Then you shouldn’t mock it but instantiate it.

Is it part of any infrastructure dependency like DB connection, IO file system, Network, or any external service that has nothing to do directly with your business domain? Then mock it using abstractions/interfaces.

The interface should be the contract between your business domain logic and its external infrastructure dependencies. Imagine how easy it would be to unit test your domain logic by instantiating it and calling their methods with different arguments expecting different inputs under your entire control.

Some tricks #

When you are writing a unit test:

Try to instantiate your classes first.
Avoid mocking concrete classes. I wrote an article exclusively about this: encouraging final classes and interfaces.

Mock interfaces. Instantiate concrete classes.

“Excessive use of mocks leads to legacy code.” - Philippe Boargau

How can we avoid excessive mocking? #

Favor immutable state over a mutable state.
Make dependencies explicit.
Program to an interface, not to an implementation.

References #

Mocking is a code smell - Eric Elliott
When to mock & Test Definitions - Uncle Bob
Final classes by default - Matthias Noback
The problem with mocks - Sean Hammond
A Set of Unit Testing Rules - Michael Feathers

Testing Effectively Legacy Code

2020-08-17T00:00:00+00:00

These tests are also known as Characterization tests.

A characterization test describes the actual behavior of an existing piece of software, and therefore protects existing behavior of legacy code against unintended changes via automated testing. This term was coined by Michael Feathers.

They enable and provide a safety net for extending and refactoring code that does not have adequate tests. A test can be written that asserts that the output of the legacy code matches the observed result for the given inputs.

How to start? #

These are my learnings one year after reading Working Effectively with Legacy Code and applying it to the different projects I’ve been working on since then.

1. What do you want to test? #

Find out the assertions. Create a test file for your class, and a testing method for the function that you want to test. Hint:

If you have the following method applySomeLogic(): ReturnType,
the test you could write is test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // black box responsible to create a ReturnType
 // based on the given Input
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // I want to assert that "applying some logic"
 // from MyBusinessLogic with the given Input
 // I will receive a concrete ReturnType with a 
 // certain value as its property. Something like:
 
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instantiate the concrete/final class that you want to test. #

Do not mock your concrete classes. Especially your business domain. Mock only interfaces. Otherwise, you can be hiding bugs unintentionally (with green/passing tests!). Treat your business domain classes as final.

Either mock the interface or instantiate an anonymous class if you want to create a Stub:

Stubs provide answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // OR
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Where FakeDependency is a concrete implementation of DependencyInterface with already “fake data/implementation” that it’s useful only for testing purposes.

3. Call the method from that class providing the desired input. #

The output will be determined by the initial state of the business logic class that we want to test PLUS the input arguments that we are using.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Assert the output with the expected value. #

From step-1 you need to know what you want. Apply the assertion(s) now.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. You might want to assert different expected values. #

You can easily provide different arguments to your business logic either via the logic construction or different given arguments. To do so, use the @dataProvider annotation. The “dataProvider” method must be public and return any iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Lastly: clean what you did. #

Yes, clean the tests. They deserve to be as clean as your production code. Otherwise, they will rot as time passes by and remain dirty for your colleagues and your future self!

For example, you can apply extract method refactoring to move out the implementation details (of the creation of the different objects) and keep the same abstraction level while reading the test code.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Of course, everything depends on the context. Does it really make sense to extract into a private method the createBusinessLogic() or even createInput()? Well, that’s up to you. It depends on the number of lines and, most importantly, the abstraction level that belongs to that context.

Just remember: keep your methods small.

Now you can refactor the production code that you covered with tests without that fear of breaking it.

All together #

Legacy Code is code without tests #

Of course, there is way more to learn about testing and working with legacy code. In fact, especially when dealing with legacy code, you will encounter situations where the code is coupled somehow that you might want to mock your concrete classes because there is no interface (yet) for it.

This book presents to you a lot of techniques about when, why, where, and how you can apply these changes.

When working with code you need feedback. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests.

First, add tests, then do your changes. #

Change as little code as possible to get tests in place with the recipe: #

Identify “change points” to break your code dependencies.
Break dependencies.
Write the tests.
Make your changes.
Refactor.

The Art of Testing: Where Design Meets Quality

2020-04-07T00:00:00+00:00

Why you should consider testing as part of your daily development habit and how it’s directly linked to the software quality.

This post intends not to explain the different testing techniques that we can use. I’m not going to tell you the differences between unit, integration, feature, or end-to-end testing.

I’m still amazed by the lack of experience with testing in software in general. Common ignorance in this world about best testing practices for us as developers. Inexperience that you can easily see if you have already worked on different projects and teams.

Software testing #

Some horrible patterns I’ve seen (and done):

Testing for the sake of testing: testing every single file, sometimes wrongly considered a unit.
Mocking every class we intend to test, overriding the actual implementation, and creating a fake behavior, providing a false coverage perception.
Coupling production code with tests everywhere, so it’s impossible to change anything without breaking some tests, even if the feature itself it’s working as intended.
Not testing at all because “why should we even test anything if the feature is done, and it works? Why should we spend more time on this if it’s done?.”

One of the main reasons for software testing is actually verifying a suite of proofs for the expected behavior of the final software piece. However, testing can (and should) be more than that.

Software design #

Software design goes from algorithm to architecture design. Even when I believe these two levels of components have different needs and requirements, they still share some common patterns. For example, testing, and this is what we are going to talk about right now:

If it’s easy to test, it will likely be because of good design.

Software quality #

Is quality hard to measure out? Indeed. There are different measurement keys that we should take while considering quality for any piece of software. Still, I’m sure we could agree on this:

If you aim for quality in your software, you better seek a good design.

Testing by itself means “proving,” as we all know. That said… how difficult it sometimes turns to prove some logic that we finally give up because of its complexity itself?

The art of testing is about using testing itself to help and contribute to the final result. To encourage good design, suppose we’re able to use testing (of any kind) in our favor, depending on the context of what we want to prove. In that case, it will undoubtedly help us increase the product’s end quality.

Therefore, testing should be used not only to prove the behavior of our software but also to guide our software to a better design.

Should we test everything? Well, that’s the million-dollar question. In my opinion, everything depends on the context. We might encounter situations where tests might not be beneficial. Even in those situations, we should write our code as if it could be tested anyway.

Testable code tends to better design and, therefore, better quality.

Clean Agile

2020-03-12T00:00:00+00:00

Clean Agile comes from Uncle Bob, one of the founding fathers of Agile, one of the seventeen people who authored the Agile Manifesto back in 2001.

This talk is about Agile. What it was, what it is, and what it will be. This is a back-to-basics talk that covers the history of Agile, what motivated it, and what has happened to it since. The talk covers the basic practices of Agile, and compares and contrasts those practices with the current menagerie of Agile processes.

Extreme Programming Explained

2020-03-05T00:00:00+00:00

Definition #

Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.

Values #

The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below.

Communication #

Software development is inherently a team sport that relies on communication to transfer knowledge from one team member to everyone else on the team. XP stresses the importance of the appropriate kind of communication: face to face discussion with the aid of a white board or other drawing mechanism.

Simplicity #

Simplicity means “what is the simplest thing that will work?” The purpose of this is to avoid waste and do only absolutely necessary things such as keep the design of the system as simple as possible so that it is easier to maintain, support, and revise. Simplicity also means address only the requirements that you know about; don’t try to predict the future.

Feedback #

Through constant feedback about their previous efforts, teams can identify areas for improvement and revise their practices. Feedback also supports simple design. Your team builds something, gathers feedback on your design and implementation, and then adjust your product going forward.

Courage #

Kent Beck defined courage as “effective action in the face of fear”. This definition shows a preference for action based on other principles so that the results aren’t harmful to the team. You need courage…

to raise organizational issues that reduce your team’s effectiveness.
to stop doing something that doesn’t work and try something else.
to accept and act on feedback, even when it’s difficult to accept.

Respect #

The members of your team need to respect each other in order to communicate with each other, provide and accept feedback that honors your relationship, and to work together to identify simple designs and solutions.

Principles #

Humanity #

Human beings are the ones developing software. It is a fact. The book mentions 5 points that are needed for developers to become good: basic safety, accomplishment, belonging, growth, and intimacy.

The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.

Economics #

Software costs. Someone or multiple people paid or invested in it.

Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.

The earlier software makes money, the sooner the development is valuable.

Mutual Benefit #

Mutual benefit in XP is about activities benefitting all concerned. This principle is about finding practices that benefit me now, me later, and the customers as well.

The book brings up 3 points how XP mutually deals with communication-with-the-future problems:

I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road.
I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.

Self-Similarity #

This principle is about copying the structure of one solution into a new context.

For example, the basic structure of development is that you write a failing test and then make it work. This structure operates at all different scales. Take into account, this principle is a good start, but it may not always work.

Improvement #

Do your best today but strive to do better tomorrow, strive to have a deeper understanding tomorrow. XP shines in this aspect, it is about always improving.

Put improvement to work by not waiting for perfection. Find a starting place, get started, and improve from there.

Diversity #

Teams need to bring in people from different backgrounds, with different experiences, attitudes, etc. In order for the team to have different ways of thinking and solving a problem.

The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.

Reflection #

Good teams reflect after action, regularly. They think about why and how they are working.

Why did we succeed? What should we continue doing?
Why did we fail? What can we do better or differently?

Reflect and strive to improve. Even if everything seems perfect, know that there is always room for improvement and throw in the question:

Why do things seem perfect? What are we doing well? What can we do better in order to succeed even more?

Flow #

Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. Don’t deliver software in big portions. Deploy smaller increments of value more frequently.

Opportunity #

Learn to see problems as opportunities for learning and improving.

Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy #

The difficult problems in software development should be solved in multiple ways.

The cost of the redundancy is more than paid for by the savings from not having a disaster.

Failure #

Sometimes it is extremely difficult to implement something, we don’t know which way or approach to take, try the ideas you have, even if they fail! Failure isn’t a waste, rather a learning experience.

Be aware of falling into the trap of discussing or thinking forever and not getting things done.

When you don’t know what to do though, risking failure can be the shortest, surest road to success.

Quality #

Projects don’t go faster by lowering the quality. Actually it’s often the other way around (if not always). It results in later and less predictable delivery, especially due to the amount of time spent on fixing bugs for example.

Pushing quality higher often results in faster delivery.

A concern for quality is no excuse for inaction. If you don’t know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later.

Baby Steps #

Take baby steps. Making big changes in big steps is dangerous. People and teams can take many small steps so they appear to be moving forward rapidly.

Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.

Accepted Responsibility #

Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.

Practices #

While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development.

Sit Together #

Since communication is one of the five values of XP, have your team sit together in the same space without barriers to communication, such as cubicle walls.

Whole Team #

Include on the team people with all the skills and perspectives necessary for the project to succeed.

Informative Workspace #

Set up your team space to facilitate face to face communication, allow people to have some privacy when they need it, and make the work of the team transparent to each other and to interested parties outside the team.

Energized Work #

You are most effective at software development and all knowledge work when you are focused and free from distractions.

Pair Programming #

Pair Programming means all production software is developed by two people sitting at the same machine. The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review and quicker response to nagging problems that may stop one person dead in their tracks.

Teams that have used pair programming have found that it improves quality and does not actually take twice as long because they are able to work through problems quicker, and they stay more focused on the task at hand, thereby creating less code to accomplish the same thing.

Pair programmers:

Keep each other on task.
Brainstorm refinements to the system.
Clarify ideas.
Take initiative when their partner is stuck, thus lowering frustration.
Hold each other accountable to the team’s practices.

Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.

Though, if you need privacy and time to work on an idea, go ahead and do it. We need both companionship and privacy. Make sure to rotate pairs frequently and take frequent breaks, pairing can be tiring, but surely is rewarding.

Stories #

Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.

Give the stories a short title and a description. Write them on cards and put them on a wall that is often being passed.

In XP stories are estimated extremely early, which gets the team thinking about how to get the largest return from the tiny investment.

Weekly Cycle #

The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories.

The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.

Ten-Minute Build #

The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes.

Continuous Integration #

Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner.

This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development.

Test-First Programming #

Write a failing automated test before changing any code.

The book mentions 4 problem Test-First Programming addresses at once:

Scope creep: It’s easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you’ve made this one work.
Coupling and cohesion: If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.
Trust: It’s hard to trust the author of code that doesn’t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.
Rhythm: It’s easy to get lost for hours when you are coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm: test, code, refactor, test, code, refactor.

Incremental Design #

Invest in the design of the system every day.

You do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features.

This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.

Roles #

Although XP specifies particular practices for your team to follow, it doesn’t really establish specific roles for the people on your team.

Depending on which source you read, there is either no guidance, or there is a description of how roles typically found in more traditional projects behave on XP projects.

The Customer #

The Customer role is responsible for making all of the business decisions regarding the project including:

The XP Customer is assumed to be a single person, however experience has shown that one person cannot adequately provide all of the business related information about a project.

The Developer #

Because XP does not have much need for role definition, everyone on the team (with the exception of the customer and a couple of secondary roles listed below) is labeled a developer. Developers are responsible for realizing the stories identified by the Customer.

The Tracker #

The main purpose of this role is to keep track of relevant metrics that the team feels necessary to track their progress and to identify areas for improvement.

The Coach #

This is usually an outside consultant (or someone from elsewhere in your organization) who has used XP before and is included in your team to help mentor the other team members on the XP Practices and to help your team maintain your self-discipline.

What is XP? (in 2 min) #

Tech Talk by kent Beck: XP 20 years later #

Working Effectively with Legacy Code

2019-07-01T00:00:00+00:00

What is legacy code? #

Legacy code is simply code without tests.

Benefits of tests #

Behavior is central to understanding the benefits of testing:

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

How to get tests in place in legacy codebases #

When we change code, we should have tests in place. To put the tests in place, we often have to change code.

The suggested approach:

Identify change points.
Find test points.
Break dependencies.
Write tests.
Make changes and refactor.

Another useful term is a “seam.” A seam, in this context, is “a place where you can alter behavior in your program without editing in that place”. The analogy is to a seam in clothing, the place where two parts are stitched together. In software, these places are generally places where there are well-defined interfaces. This can be leveraged to change the implementation using techniques such as dependency injection or mocking interfaces in the case of writing tests.

The Clean Coder

2016-08-01T00:00:00+00:00

Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals.

Readers will learn #

What it means to behave as a true software craftsman
How to deal with conflict, tight schedules, and unreasonable managers
How to get into the flow of coding, and get past writer’s block
How to handle unrelenting pressure and avoid burnout
How to combine enduring attitudes with new development paradigms
How to manage your time, and avoid blind alleys, marshes, bogs, and swamps
How to foster environments where programmers and teams can thrive
When to say No and how to say it
When to say Yes and what yes really means

Summary #

Chapter 1: Professionalism #

Being a professional means taking full responsibility for one’s actions.
First rule is not doing harm to the function nor the structure of the software.
You will always make occasional mistakes, but you must learn from each.
You should be certain about all code you release and firmly expect QA to find nothing wrong with it.
- Test it and test it again.
- Automate your tests.
- Design your code to be easy to test.
You should follow the Boy Scout rule and always leave a module a little cleaner than you found it so that it becomes easier to change over time, not harder.
Your career is your responsibility, not your boss nor your employers.
- Spending 20 hours a week beyond your normal work to improve your knowledge and skills.
- Read, experiment, practice (kata), talk to other, collaborate, look over the fence, mentor.
- It should be fun.
Also, know your domain, identify with your customer (no “us vs. them”, ever).

Chapter 2: Saying No #

Professionals have the courage to say no to their managers.
Managers and developers have roles that are often adversarial, because on the short term, their goals tend to conflict.
The higher the stakes, the more valuable a “no” becomes, and the harder to say.
Good teams will successfully work towards a yes, but only a right yes, that will later work out in practice.

Chapter 3: Saying Yes #

There are three parts to making a commitment:
- You say you will do it
- You mean it
- You actually do it
Your commitment must respect the limits of what you expect (based on your experience) you can and cannot do.
- If you recognize you will probably not be able to meet a commitment, you need to raise a red flag immediately.

Chapter 4: Coding #

Programming requires a level of focus that few other disciplines require.
“The zone” (or “flow”) is not as good as people think: you will be locally productive, but will often lose the bigger picture and possibly product not-so-good designs.
Interruptions are bad distractions.
- Pair programming is helpful to cope with them.
- TDD helps to make the pre-interruption context reproducible.
  - Minimize time spent debugging
Coding is a marathon, not a sprint, so conserve the energy and creativity.
Leave when it’s time, even in the middle of something important.
Continuously re-estimate your best/likely/worst completion time and speak up as soon as you recognize you will likely be late.
- Do not allow anyone to rush you.
- Use a proper definition of “done”, with sufficiently high quality requirements.
Programming is too hard for anyone, so get help and provide help to others, in particular (but not only) in mentoring style.
- Don’t be shy from asking.

Chapter 5: Test-Driven Development #

TDD is not a cure-all and is impractical or inappropriate in some (rare) cases.
TDD Cycle:
1. Add a test
2. Run all tests. The new test should fail for expected reasons
3. Write the simplest code that passes the new test
4. All tests should now pass
5. Refactor as needed
6. Repeat

Chapter 6: Practicing #

A programming Kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem.
- A Kata is about the process, not the solution.
- You aren’t solving the problem because you already know the solution.

Chapter 7: Acceptance Testings #

Avoid garbage in, garbage out. Make sure you understand the requirements.
- Creating this understanding means removing ambiguity.
The best way to do this is defining acceptance tests:
- All customer’s conditions need to be fulfilled by automated tests to prove the expected software behavior.
- Success of those tests constitutes the definition of “Done”.
Code implementation should start only when the tests are complete.
Unlike unit tests (which are only for programmers), the audience of acceptance tests are both: business and developers.
Run all tests in a continuous integration and immediately fix any failures.

Chapter 8: Test Strategies #

Consider QA part of the team. They act as specifiers: writing acceptance tests, including the failure cases and corner cases, and perform exploratory testing.
Testing pyramid:
- Most tests are unit tests. By developer and for developers.
- Many tests are component or integration tests. By QA or Business assisted by Developers. For Business and Developers.

Chapter 9: Time management #

Management roles in software development requires good time management.
Meeting are necessary but are also often huge time wasters, so avoid meeting that have no clear benefit <- this is a professional obligation.
Meeting must have an agenda and a clear goal.
- Agile stand up meetings can be an efficient format.
- Iteration planning should take 5% of the iteration.
Concentration (focus) is a scarce resource.
- Use it well when present and recharge with simpler tasks (meetings) and breaks in between.
- How to improve?
  - Sport.
  - Creative input.
  - Short breaks every 45 minutes.

Chapter 10: Estimation #

Estimation is the source of most distrust between business people and developers because the latter provide estimate which the former treats like commitments.
- Both are insufficiently aware that the estimate really is a probability distribution, not a fixed number.

Chapter 11: Pressure #

The professional developer is calm and decisive under pressure, adhering to his training and disciplines, knowing that they are the best way to meet pressing deadlines and commitments.
Avoid situations that cause pressure via:
- make only commitments you can fulfill
- keep your code clean
- work in such a way that you need not change it when in crisis
Don’t panic. Talk with your team. Don’t rush. Trust your disciplines.
Offer to pair to others in crisis.

Chapter 12: Collaboration #

Not all but most programmers like working alone. But we need to understand the goals of the surrounding people, including business folks.
- This requires communication.
Likewise, within the development team: only collective code ownership and pairing produce a good level of communication.
- Programming is all about communication.

Chapter 13: Teams and Projects #

Teams need time (months) to gel, to really get to know each other and learn to truly work together.
- Assigning fractional people to different projects is a bad idea, as is breaking up a good team at the end of a project.
- Instead, assigning several projects to one team can work well.

Chapter 14: Mentoring, Apprenticeship and Craftsmanship #

Young programmers need mentoring.
- Mentoring can be implicit or explicit.
Given that we entrust software with all aspects of our lives, a reasonable period of training and supervised practice would be appropriate.

In this lesson, Uncle Bob demonstrates the need to write a clean code and establishes the bases to achieve it, being these bases of a social and scientific nature. Making it clear that the future of programming is based on an ethical and polite code.

In this second lesson, Uncle Bob teaches us the purpose of comments in the code, breaking the paradigm that commenting is something “I have to do” for the simple fact that we mistakenly consider that commenting is a good practice. For Uncle Bob, writing a comment is a sign of failure, since a good code must be able explain by itself: Fewer Comments = Better Code.

In this third lesson, Uncle Bob focuses on raising awareness, given the need to increase the level of criteria in code production. Pointing to the lack of preparation in most programmers, as one of the main reasons for the inefficiency in software development today.

In this fourth lesson, Uncle Bob introduces us to a software development methodology oriented through testing. This is the Test-Driven Development (TDD), a practice with a long learning curve, but with significant results to generate a more robust, safer, more maintainable code and with greater development efficiency.

Clean Code

2016-05-01T00:00:00+00:00

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Summary #

Chapter 1: What Is Clean Code? #

The code can be measured with either “good” or “bad” in the code review or by how many minutes it takes you to talk about it.
A clean code should be elegant, efficient, readable, simple, without duplications, and well-written.
You should add value to the business with your code.
Clean code offers quality and understanding when we open the source file.
It is necessary that your code is clean and readable for anyone to find and easily understand. Avoid wasting others’ time.

Chapter 2: Meaningful Names #

Names of the classes, variables, and methods must be meaningful and clearly indicate what a method does or what an attribute is.
Create pronounceable names to facilitate communication.
Avoid acronyms and avoid confusing names, which may bring anyone who reads the code to the wrong conclusions.
Use names that reflect the system domain, the context, and the problems that must be solved.

Chapter 3: Functions #

Methods should be easy to read and understand.
Methods should convey its intention.
Methods should be small.
They must have up to 20 lines.
Methods should only do one thing.
You should use names with words that say what it really does.
The optimal number of parameters of a method is zero, after one and two.
Three should be avoided, but if you think it should be used, have a justification.
Boolean type as a parameter already states that it does more than one thing.
Avoid duplication.

Chapter 4: Comments #

One of the common reasons for comments is because the code is bad.
If you’re thinking about writing a comment, then the code should be refactored.
Comments do not save a bad code.
Try to explain what the code causes happening.
Comments can be useful when placed in certain places.
Don’t explain your code with comments. Use informative vars/method names.
Comments can be used to express the importance of certain points.
Do not write comments with redundant, useless, or false information.
They shouldn’t be used to indicate who changed or why, use versioning.
Don’t comment code that will not be used. Remove it instead.

Chapter 5: Formatting #

Formatting should indicate things of importance since it is a developer of communication form.
A messy code is hard to read.
The readability of the code will take effect on all the changes that will be made.
Smaller classes are easier to understand.
Set a limit of characters per line of code. For example 120.
Try to keep more next related concepts vertically to create a code stream.
Use spaces between operators, parameters, and commas.

Chapter 6: Objects and Data Structure #

Follow the Law of Demeter:
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
Do not make dumb objects.
Objects hide the data abstraction and expose methods that operate the data.
Data structures expose your data and do not have significant methods.

Chapter 7: Error Handling #

Error handling should be planned carefully by all programmers.
When wrong things occur, we have to get it to do the right things.
Give preference to launching an exception than treating it just to hide.
Create messages with information about the error.
Mention that it failed. Where was this failure? If possible, mention why it failed.
Look at separate business rules for errors and error handling.
Avoid returning a NULL in methods, preferably to return an empty object.
Avoid passing NULL to the methods; this can generate NullPointerExceptions.

Chapter 8: Boundary #

In third-party code, to avoid passing objects, APIs look forward in order to keep things in the same class.
Perform tests on the API’s third party.
Study the documentation and test the third API before you start using it.
Check well the features you will use.

Chapter 9: Unit Tests #

Make sure each piece of code is doing what you expect it to do.
Follow the TDDs law:
- Don’t create code before you have a failing test.
- Don’t create more tests than necessary to fail.
- You cannot write more code than enough to pass the test that is failing.
Keep your test clean.
The tests must undergo changes in the same way that the code.
The dirtier the code, the more difficult test will be to maintain.
Use the F.I.R.S.T rule for testing:
- The test is fast-running.
- The tests are independent of others.
- The test is repeatable in various environments.
- The test is self-validating.
- The test is timely.
The test is as important as the production code.

Chapter 10: Classes #

By default, classes should start with the variables:
- Static and constants public.
- Static and variable private.
- Instances and variables privates.
- Soon after comes the functions.
- The class name should represent its responsibility.
The class must have only one responsibility: one reason to change.
You should try to make a brief description of the class.
The methods should be small and one responsibility.

This interview is based on Uncle Bob’s book “Clean Code”. They cover some existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape.