Chemaclass - testing

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.

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.

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]

Modern Software Engineering

2022-06-29T00:00:00+00:00

This book presents software development as an engineering practice at every level. To master software engineering, we must become experts at learning and managing complexity.

Optimize for learning #

To optimize for learning, the book presents five behaviors to consider:

Working iteratively
Feedback
Incrementalism
Empiricism
Being Experimental

The main idea is to work on small steps, collect feedback, and adjust.

Optimize for managing complexity #

The book presents other five ideas to manage complexity:

Modularity
Cohesion
Separation of Concerns
Information Hiding and Abstraction
Managing Coupling

We need to manage the complexity of our systems.

Tools to support engineering in software #

Going deeper into some ideas that were already discussed in the book, like:

Testability
Deployability
Controlling the variables
Continuous Delivery

A great video explaining the core ideas behind this book by his author:

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 Refactoring

2020-06-28T00:00:00+00:00

If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask.

What is refactoring? #

Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example.

Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. But we shouldn’t stop trying our best in order to improve the quality of the system just because of that controversiality.

When and how should we refactor? #

Always. In the scope of your current task unless it is an already planned task, something like “architecture refactoring” or similar, where the scope of the task is actually to do refactoring.

Refactoring should be part of our daily job, not a separate task by default.

We do not need to ask permission to refactor. Or do we ask our managers for permission to do our best job?

In order to do proper refactoring, the intention of such refactoring needs to be clear. What is intended to achieve and how? Pair programming (or even pair thinking!) certainly helps in this topic because it syncs two brains on the same topic and that encourages team building and a better understanding of them.

Applying refactoring in a collaborative way, in a “bidirectional channel”, is fundamental when working within a team. Refactoring shouldn’t be a taboo topic, on the contrary: it will be helpful in order to unify the goals and the direction of the team code quality.

Some personal advice about the “how” #

Continuous improvement is what we’re looking for within this topic, but…

If you realize your changes are generating more noise than help, stop immediately and think again if your changes are worth it in the current system status.

Maybe it’s not the right moment for that refactoring.

Maybe you are polluting your current diff with out-scoped changes.

Or, maybe, your refactoring idea is too big to be applied in your current task. In such a case, a follow-up task (in order to apply the refactoring) would be a better idea.

If you see that refactoring is perhaps needed even before starting your current task, do the refactoring first.

We usually refactor in order to increase our productivity, making the code more readable and therefore easier to understand.

Testing #

Be aware that you should have a pretty good suite of tests covering the logic that you might have changed. Without tests, refactoring can be really risky. Usually, the easier something is to be tested, the easier it is to be replaced or removed.

You can read more about how testing is related to quality here.

Why should we do it? #

Wouldn’t you want to have a better system as time goes by?

Software isn’t like wine: it doesn’t get better as time passes by. Therefore, if you want to have a better system you must work for it.

Final Classes in PHP | Java | Any

2020-06-06T00:00:00+00:00

Clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself.

Motivation #

Reduce the scope visibility to the minimum #

When you see a class prefixed with final you will prevent a particular class to be extended by any other, which not only makes it more readable but also makes you be sure that the scope of the logic where you are is limited to that particular class.

Encourage “composition over inheritance” mentality #

The Open-Close Principle states: open for extension but closed for modification.

If for any reason, a good one you should be completely aware of, you decide to create an inheritance there, well, then just drop the final keyword and you are good to go.

When you “by default” can’t extend from a class (because it’s final), you will help yourself by thinking about using composition instead of inheritance.

Why isn’t this class final? #

If we aim for composition over inheritance, then we should try to avoid inheritance as much as possible, and use it only when it’s really necessary. Inheritance is often misused in OOP.

Misconception #

When we first taught OOP, we usually introduced the classic inheritance example.

Nonetheless, when Alan Kay created Smalltalk, the inheritance was never the main concept of it. The main concept was messaging, which is that you can send messages to objects and they encapsulate the data and logic in it, and you can change their behavior by using different objects, which is actually composition. But the concept of inheritance is so popular that it eventually overshadows composition.

Benefits #

Clear contracts. Using interfaces will force you to think in terms of communication between objects.
Isolated, side effect free code units. Injecting interfaces only as dependencies will remove every nasty side effect around the code you are working on.
Testability. Mocking dependencies is extremely easy when they are interfaces.
Low, manageable complexity. Since everything is isolated, you won’t need to worry about rippling changes. This dramatically decreases the complexity of your code.
Low cognitive load. With decreased complexity, your brain will be free to focus on what matters.
Code fluidity. By removing any unnecessary coupling, you will be able to move things around way more easily than before.
Confidence in yourself. Being able to test your code in isolation so well will give you a wonderful sense of confidence in changing it.

Composition over inheritance #

If you feel the need to reconfigure an object, to change parts of an algorithm, or to rewrite part of the implementation, consider creating a new class instead of overriding an existing class. If you need to represent a hierarchy of classes, where subclasses are proper substitutes for their parent classes. This would be the classic situation where you may still consider inheritance. However, the result may even be better if you don’t inherit from concrete parent classes but from abstract interfaces.

What you should start doing instead #

Use interfaces to define the contracts between your classes.
Use final classes to implement behavior for those interfaces.
Use composition (using dependency injection through constructor) to put things together and prevent complexity.

Interfaces -> Final classes -> Composition

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.

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.

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.