Codesai

Our Architectural Guardrails for AI-Generated Code

2026-04-26T05:30:00+00:00

Introduction.

The idea to write this post came about almost half a year ago, but the flood of events in the industry and my personal life has not allowed me to write about it until now.

During a deliberate practice session^[1] where the pair I was assisting was programming using Cursor, I watched in amazement as Cursor’s autocomplete suggested using test builders to instantiate an object in production code, and nobody noticed.

I pointed out the problem to the pair so they could fix it, and advised them to be more careful with what the AI was suggesting. But I was left with the feeling that my advice is much easier said than done, because it’s not easy to always be vigilant, since it’s difficult to spot problems in code that’s mostly fine. This difficulty is exacerbated when the code is generated by agents due to the sheer volume of code generated.

I believe we need all the help we can get in this task of evaluating AI-generated code.

What we’d like to avoid.

As we’ve already discussed, the speed and size of the increments when using code agents make it harder for developers to detect these problems. When evaluating code that appears mostly correct for extended periods, phenomena like code review fatigue or cognitive surrender can occur, making one more likely to accept AI-generated code (even small amounts suggested by autocomplete) without careful evaluation.

This evaluation of AI-generated code gets even more difficult when developers have not yet developed enough knowledge to have criteria to evaluate the design implicit in the solution proposed by AI.

Since one of the main objectives of deliberate practice sessions is precisely to develop critical skills to evaluate design options^[2], we decided to support the participants with some minimal design rules that automated away basic problems we’d like to avoid^[3].

1. Domain should not depend on infrastructure.

Business rules should guide software system design because they represent the core logic and purpose of the organization, which should remain independent from changing technologies or external systems. In addition, by isolating the domain from infrastructure, the business logic remains easier to test, maintain, and evolve independently of external technologies. This approach also reduces accidental complexity, avoiding the leakage of infrastructure details into the business language and preserving a cleaner, more adaptable architecture.

This rule helps us strictly keep the dependency rule described in the ports and adapters pattern.

2. Production code should not have circular dependencies.

Circular dependencies because they blur module boundaries and make systems harder to understand, maintain, and safely evolve. Changes in one component tend to propagate unpredictably into the other, increasing coupling and making refactoring riskier. Cycles also create fragile initialization behavior, often causing import-order issues or partially initialized objects at runtime. Most importantly, they hurt testability: components cannot be instantiated or mocked independently, which makes unit testing and dependency injection harder and pushes teams toward slower, more brittle integration tests.

3. Production code should not depend on tests.

Production code should not depend on tests because tests are meant to verify behavior, not define or support runtime structure. When production relies on tests, it creates tight coupling between validation code and application logic, making the system fragile and harder to maintain. Changes to tests can unintentionally affect production behavior, undermining the reliability and independence that tests are supposed to provide. This creates fragility and deployment risks. It also blurs responsibilities by making tests both validators and runtime collaborators, which undermines separation of concerns. Such coupling encourages the introduction of test hooks, fake abstractions, and conditional behaviors into production code, reducing cohesion and maintainability.

This may seem obvious, but it was precisely this rule that I observed code suggested by Cursor breaking.

How to enforce these design rules.

We evaluated three primary enforcement strategies: architecture tests, reviews with agents, and documentation/skills, but in the end, we decided to use architecture tests.

Why not skills, docs or agentic reviews: guidelines vs guardrails, determinism and costs.

Architecture tests are automated tests that can be used to verify the structure and design of our code to a certain extent, and as such, can help us enforce some design rules, acting as automated constraints that make it deterministically “difficult to do the wrong thing.”

Documentation (like AGENTS.md) and skills for agents are used to enhance the probability of generating code according to what we expect. While they are essential when working with coding agents, they function merely as guidelines, and, as such, we think they are too weak to enforce design rules like the ones mentioned above. We think that, in the case of design rules like ours, we need to move from “best effort” to “guaranteed compliance,” shifting our focus from guidelines toward guardrails.

Reviews with agents, while being a form of guardrail, introduce a layer of probabilistic uncertainty and recurring costs that make them less reliable and more expensive, respectively, than architecture tests.

The following analysis explains in more detail why we prioritize deterministic architecture tests over the other options evaluating them across two critical dimensions: likelihood of adherence and token cost and efficiency.

1. Architecture Tests (a reliable guardrail).

Architecture tests turn objective design rules into executable code^[4].

a. Likelihood of adherence.

Architecture tests are fully deterministic. If we integrate them into our CI/CD pipeline, we achieve a 100% adherence rate because a rule violation physically prevents the build from passing, they act as binary gates for the rules. They are automated fitness functions^[5] that ensure the enforcement of the design rules.

b. Token Cost and Efficiency.

These tests execute locally on the CPU with zero token cost. They provide instant feedback during the inner development loop without hitting any external API, making them the most cost-effective and lowest-latency option.

2. Docs/Skills (guidelines).

Documentation and skills rely on human memory and/or the LLM’s ability to follow instructions.

a. Likelihood of adherence.

Documentation and skills enhance the probability of getting a generated code that follows our design rules.

Under pressure or high cognitive load, humans tend to prioritize task completion over structural constraints. In a similar way an agent, due to the non-deterministic nature of LLMs, may ignore instructions, or take shortcuts in their eagerness to complete tasks.

Agents can also suffer from their version of high cognitive load, suffering from instruction-following degradation as their context window gets too full: context rot.

The amount of documentation we feed an agent can worsen context rot because every rule added to a loaded “skill” library or prepended to a prompt consumes space in the context window. We need to be careful deciding which skills and documentation are worthy to occupy space in the context window.

Even if we manage effectively the context window, the important point is that design rules defined as guidelines are susceptible to “drift.” because agents may often bypass or forget guidelines.

b. Token Cost and Efficiency.

Every loaded “skill” or documentation prepended to a prompt lead to higher per-request costs and increased latency.

We also saw how context rot produces a performance degradation which may require more attempts to complete a given task increasing the number of requests.

Unlike “free” local architecture tests, enforcing design rules that are really objective like ours using documentation or skills creates an increase in operating costs.

3. Reviews with Agents (an unreliable guardrail).

This method uses a second LLM pass to “audit” code against a set of standards (passed as documentation or skills).

a. Likelihood of adherence.

Because agentic reasoning is non-deterministic, this kind of enforcement will be “best-effort” rather than guaranteed. It is probabilistic and inconsistent by nature. An agent may overlook subtle violations if the primary logic looks correct. This creates an unreliable feedback loop where the same violation might pass one review and fail the next.

b. Token Cost and Efficiency.

This approach introduces a massive “token tax.” Every line of code must be sent and processed twice, once for generation and once for verification. This leads to escalating API costs and higher latency, making constant evaluation of design rules an expensive recurring expense, and a source of happiness for your AI-inference providers 😅.

Conclusion.

We hope that we have been able to communicate with this analysis the reasons why we prefer to use architecture tests to enforce design rules like ours rather than the two other options: they are an automatic, cost-effective, unambiguous, deterministic and reliable way to enforce objective rules.

Linters vs. architecture tests for design rules.

We also experimented with linters as guardrails to enforce our design rules. From the point of view of likelihood of adherence, as well as token cost and efficiency, linters are as valid as architecture tests. Both approaches can automatically reject changes that violate predefined constraints, making them equally viable enforcement mechanisms.

However, we prefer architecture tests over linters because we find that architecture tests make the intent of design rules easier to read. With architecture tests, design rules are usually expressed directly in code, and described by the name or description of the test itself. In linters, the same rules tend to live in JSON or configuration files, in a more cryptic format that is harder to interpret at a glance.

Our minimal architecture tests.

We wrote these architecture tests with the help of a coding agent and then did “agentic mutation testing” in the code to see if they really detected violations of the rule, (we’ll talk more about agentic mutation testing, and how to offload it to determinism in a future post).

For the deliberate practice sessions.

These are the architecture tests in TypeScript we are using in the deliberated practice sessions:

We used basic functionalities from the ArchUnitTS architecture testing library to enforce our minimal design rules.

For a client’s project.

We have also added architecture tests to a project my colleague Fran Reyes and I are developing for a client.

We hadn’t felt the need to automatically enforce design rules in this project until we started using agents to delegate some tasks. When Fran and I were pair programming without agents we never produced the problems those rules are meant to avoid, probably thanks to keeping a more human pace and sharing a mental model through pair programming. But now that we’re using coding agents, we decided that adding architecture tests to the project would be helpful.

These are the architecture tests in Java we are using in our project:

They contain more rules than the ones we use for the deliberate practice sessions. In this case, we are using ArchUnit architecture testing library (which I think is a complicated beast) to enforce the design rules.

Conclusions.

The frequency and size of AI-generated code increments often outpaces our natural capacity for vigilance. The risk of cognitive surrender or fatigue is real. When an LLM consistently produces code that looks “mostly right,” it becomes increasingly difficult to spot subtle design drifts. We think that relying solely on guidelines is insufficient to maintain high design standards under these conditions.

We believe that to successfully integrate AI agents into our workflow, we must complement guidelines with guardrails. While documentation and skills can help steer an LLM in the right direction, they remain probabilistic and context-heavy. By contrast, architecture tests offer a deterministic, cost-effective way to ensure compliance. They allow us to at least offload the mental burden of structural verification to the CPU, enforcing our core design rules regardless of who, or what, is writing the code.

By implementing minimal architecture tests, we have created a safety net that protects our core design rules. These tests function as automated fitness functions that provide instant, local feedback. This approach continually enforces our design rules without burning any token.

We are using these tests, both in deliberate practice sessions and client projects, in which AI-generated code is growing. In our experience, they have proven very useful because while we cannot always prevent an agent from generating code that breaks a desired design rule, guardrails like architecture tests can certainly prevent that code from ever becoming a permanent part of our system.

Acknowledgements.

I’d like to thank Fernando Aparicio, Fran Reyes and Antonio de la Torre for giving me feedback about several drafts of this post.

References.

Notes.

[1] Our deliberate practice sessions with Audiense are designed with two goals in mind:

Keep fundamental engineering skills strong, avoiding skill atrophy induced by AI.
Introduce new technical practices and ideas to the team on a continuous basis.

[2] In the deliberate practice sessions, we try to transmit a style of OO design based on the ports and adapters pattern combined with Responsibility-driven design, Domain-Driven Design principles, other OOP principles, and when they apply, some classical OOP design patterns.

[3] We could also have banned AI completely during deliberate practice sessions. Instead we decided to work without agents, but still allow using AI autocomplete in the IDEs. The reason for this is that we believe that generating code at a more “human pace” is more instructive for learning and practicing the type of skills we want to develop and maintain.

[4] According to Birgitta Boeckeler “LLMs are great for exploratory and fuzzy rules, but once you have [a rule] that really is objective, converting it to a formal, unambiguous, deterministic format can give you more assurance”.

Our design rules are objective, so they are best implemented in a formal, unambiguous, and deterministic format such as architecture tests or linter rules.

[5] To learn more about fitness functions have a look at chapter 2 of Building Evolutionary Architectures, 2nd edition.

Roots of the mock trauma in a Flash

2026-04-26T05:30:00+00:00

Roots of the mock trauma.

The problem is usually caused by either:
1. Design problems in production code
  - Procedural code or code with too many responsibilities.
  - Weak interfaces (with high probability to be changed):
    - Wrong level of abstraction.
    - Responsibility smells.
    - Data smells.
2. A misuse of test doubles, as we saw, using them when we shouldn’t:
  - the misconception of thinking the class is the unit (probably responsible of most of the mock-trauma).
  - using test doubles for value objects.
  - using test doubles for internals.
  - using test doubles for types we don’t own.

We think that instead of blaming test doubles, we need to learn to:

Design better.
Use the tool better.

An Expensive Errand: Chasing 100% Mutation Coverage with an Agent Can Make Your Test Suite Worse

2026-04-21T05:30:00+00:00

Introduction.

In this post, we walk through an experiment with AI-generated code and tests in order to explore the pitfalls of blindly using mutation testing to “improve” AI-generated test suites^[1].

The code and tests generated by the coding agent.

We used a coding agent^[2] to generate the code of a repository, MariaDBDiscountsRepository, that gets discounts from a MariaDB database. This is the generated code:

To test it we prompted the agent with:

and the coding agent generated the following tests^[3]:

Evaluating the AI generated tests with mutation testing.

The generated tests initially looked reasonable, but, since we don’t trust AI-generated code, we ran mutation testing with StrykerJs in order to assess how good the tests were. We targeted only the MariaDBDiscountsRepository class and its tests to make the execution of StrykerJs faster.

This was the resulting report:

Initial mutants report.

There were 5 surviving mutants:

M1.

Surviving mutant M1.

M2.

Surviving mutant M2.

M3.

Surviving mutant M3.

M4.

Surviving mutant M4.

M5.

Surviving mutant M5.

Blindly chasing 100% mutation score with a coding agent.

It’s tempting to treat a mutation report like a checklist. Seeing those five survivors, we can think: “No problem, let’s tell the coding agent to just enhance the test suite until no mutant remains standing”. This is convenient and leverages AI’s speed to reach a 100% mutation score. Let’s see how this naive approach goes:

Prompt used to kill surviving mutants.

At first glance, it looks like a victory. After a significant amount of time and burning some tokens^[4], the agent eventually managed to kill every single mutant. But, you’ll soon see, as we review the code, how this “convenient” approach created a maintenance headache.

Summary shown by the agent after killing all mutants.

To kill the surviving mutants the agent generated new test cases in the integration tests of MariaDBDiscountsRepository. It also generated unit tests (what?!? 😮):

Let’s review them:

The new version of the integration tests of `MariaDBDiscountsRepository`.

Comparing the two versions of the integration tests we see that the agent modified one of the existing test cases, and added three new test cases.

Let’s start with the modified existing test case, 'should throw an error when discount is not found':

Existing integration test case modified by the agent.

The new version of 'should throw an error when discount is not found' effectively kills the surviving mutant M2. However this test case is overspecified because it fixes the whole text of the exception message which makes it fragile to changes in the concrete error message. We think this may generate too much noise. Instead we should only specify the type of the exception and the discount code. At the end, we’ll show a refactored version of this test that removes this overspecification and still kills the mutant.

These are the new three integration test cases added by the agent:

New test case 1: `'should throw an error when the discount type is unknown'`

This test case contains no assertions, just a comment saying that there is a DB constraint which prevents the discount type being unknown from happening. The comment also says that the related logic is fully covered in the unit tests, which is “smelly” and worrying, because the implementation of a repository should not be covered by unit tests, and the only way to write unit tests for it is by using test doubles for types we don’t own.

This test case was meant to kill the surviving mutants M3 and M4. The agent wrote it in its first attempt to kill M3, but it failed because due to DB constraint discount type can’t be unknown. After several failed attempts, the agent decided to change its approach and still try to kill M3 writing unit tests full of test doubles… (we’ll review them later).

New test case 2: `'should handle non-string condition data correctly (e.g., when driver already parses JSON)'`

This test case is redundant. It’s testing exactly the same as another already existing test case: 'should find a percentage discount given its code'.

New test case 3: `'should not find a discount if the query filter is broken (killing WHERE d.code = ? survivor)'`

This test case is useful. It kills the surviving mutant in the surviving mutant M1. Still, its name is bad and it has some overlap with 'should find a percentage discount given its code'. It would have been much better to modify that already existing test by adding two discounts to the DB in the initial fixture instead of only one.

In summary, only two of the four changes generated by the coding agent in the integration tests of MariaDBDiscountsRepository are actually improving the test suite:

The modified assertion in an already existing test case: 'should throw an error when discount is not found' which kills the surviving mutant M2.
A new test case: 'should not find a discount if the query filter is broken (killing WHERE d.code = ? survivor)' which kills the surviving mutant M1, although it would have been much better to modify the fixture of the previously existing test case, 'should find a percentage discount given its code'.

The rest of the changes are noise or duplication.

The unit tests of `MariaDBDiscountsRepository`… 😞.

These are the unit tests generated by the agent:

A huge red flag to notice is that the agent is using a test double of a type that we don’t own: Connection, which is part of mariadb, the Node.js client library for connecting to a MariaDB database. Specifically, these unit tests are stubbing the query method of Connection.

Using test doubles of types that we don’t own is a recipe for suffering^[5]. This often hurts because:

Our tests become tied to implementation details instead of outcomes which makes them utterly fragile.
Any changes in the interface of the type can break our tests.
The test double can drift away from real behavior.
We end up reimplementing the library’s behavior in our test.

We should rely on integration tests to ensure our code talks to the database correctly; that is precisely the responsibility the integration tests were already fulfilling for MariaDBDiscountsRepository. Even in those rare cases where stubbing a method like query might be necessary (for example, to trigger an exceptional behavior that is difficult to replicate in a real database) the agent should have at least introduced a thin wrapper around Connection to isolate the dependency. Instead, by using a test double for the library directly, the agent ignored a basic guideline and left us with tests that are tied to implementation details rather than outcomes.

Having said this, let’s review the test cases to discuss what the intention of the agent was (which surviving mutant they were targeting) and whether they improve the test suite at all.

There are six test cases:

'should throw an error with specific message when discount is not found'
'should throw an error with specific message when discount type is unknown'
'should handle non-string condition_data (e.g., when driver already parses it as object) and preserve the value'
'should handle string condition_data correctly'
'should distinguish between PERCENTAGE and FIXED types correctly'
'should kill row.type === "FIXED" mutant by ensuring it throws when type is not FIXED even if it is the second condition'

Of these six test cases, three are redundant because the behaviour they are checking is already covered by the integration tests of MariaDBDiscountsRepository:

'should throw an error with specific message when discount is not found'
'should handle non-string condition_data (e.g., when driver already parses it as object) and preserve the value'
'should distinguish between PERCENTAGE and FIXED types correctly'

We can delete them, and still no mutants survive.

Of the remaining three test cases, two are addressing the same surviving mutants, M3 and M4:

'should throw an error with specific message when discount type is unknown'
'should kill row.type === "FIXED" mutant by ensuring it throws when type is not FIXED even if it is the second condition'

We can delete one of them, and still no mutants survive.

So only two of the six generated unit test cases were required for killing surviving mutants:

'should throw an error with specific message when discount type is unknown'
'should handle string condition_data correctly'

Let’s examine them in more detail

Non redundant test case: `'should throw an error with specific message when discount type is unknown'`

This test case kills the surviving mutants, M3 and M4. However, a discount type in the database can’t be unknown because of a restriction in the definition of the discounts table:

Notice the line CONSTRAINT allowed_types CHECK (type IN ('FIXED', 'PERCENTAGE')).

The agent is using a stub to return something that can’t be in the database, in order to kill a surviving mutant. This test case is not improving the test suite at all, in fact, it’s making it worse, because it’s not only coupling the tests to a type we don’t own, but also “ossifying” an implementation detail that is unnecessary. We’ll explain this when we analyze the relevant mutants in the next section.

Non redundant test case: `'should handle string condition_data correctly'`

This test case kills the surviving mutant M5. However, the data of a condition in the database can’t be a string because of how the discount_conditions table is defined:

The data of a condition returned by the query method will always be an object.

Again, the agent is using a stub to return something that can’t be in the database, in order to kill a surviving mutant. Like in the previous case, this test case is making the test suite worse (for the same reasons).

Conclusion: the generated unit tests were useless.

We’ve seen how the only two test cases that weren’t redundant, were actually making our test suite harder to maintain (by coupling to types we don’t own) and “ossifying” unnecessary implementations.

You may ask: “how are we going to kill the surviving mutants, M3, M4 and M5 then?”

The answer is that we won’t kill them with tests.

Let’s delete those unit tests and examine the surviving mutants, M3, M4 and M5 using the idea of relevant mutants^[6].

Going back and analyzing which mutants are relevant first.

Instead of blindly asking the agent to “improve” the test suite to kill mutants, a better approach would have been examining each surviving mutant first to see if it’s a relevant mutant or not.

Relevant Mutants.

Not all surviving mutants indicate weaknesses in the tests suite: they are not relevant for improving the test suite.

Surviving mutants that don’t signal problems in the tests suite may survive because:

They are in dead code (unreachable code).
They are part of legacy seams, and thus intentionally excluded from test execution.
They are part of code only that is only used by code in legacy seams. This exclusion from test execution is also intentional.

Another kind of surviving mutants that don’t signal weaknesses in the tests suite, are mutants which are in superfluous code. Even though they are in reachable code that is exercised by the tests suite, they survive because the mutation does not change any behavior. These mutants are still useful because they signal a possible simplification: a refactoring opportunity.

Analyzing the surviving mutants in `MariaDBDiscountsRepository` using the idea of Relevant Mutants.

Only M1 and M2 were relevant to improve our test suite: they were signalling problems in the test suite like missing boundaries, too lenient assertions, etc.

M1 was signalling a missing boundary. The original generated tests were using fixtures with only one discount, and checking that they were finding it, so no wonder we didn’t need to check its code in the where clause.

Surviving mutant M1.

M2 was signalling a too lenient assertion. The test case in the original test suite was just checking the type of the exception that the repository threw, so the mutation testing tool could remove the exception message without breaking any test.

Surviving mutant M2.

The agent did a better job with these two mutants because they really were meant to be killed by improving the test suite. Although it still didn’t do it too well (overspecifying in one case and overlapping test cases in another).

On the contrary, M3, M4 and M5 were not signalling problems in the test suite. They are signalling code that can be removed without changing the behaviour because it’s either superfluous or unreachable.

M3 was signalling superfluous code. Remember that the type of discount in the database can only be PERCENTAGE or ‘FIXED’, so if the type is not FIXED, it can only be PERCENTAGE that makes the else if (row.type === ‘FIXED’) superfluous (it’s always true).

Surviving mutant M3.

M4 was surviving because that branch is unreachable. Again, if the type of discount in the database can only be PERCENTAGE or ‘FIXED’, there is no integration test that can exercise code in that branch.

Surviving mutant M4.

M3 and M4 should be killed by refactoring, not testing. We can simplify the implementation and keep the same behaviour of the MariaDBDiscountsRepository by substituting that conditional code by this other one with no surviving mutants^[7]:

Regarding M5, this surviving mutant was also signalling superfluous code.

Surviving mutant M5.

Since the type of the data of a condition in the discount_conditions table is defined as a JSON field, it will never be a string. That’s why typeof row.condition_data === string can be mutated to false without changing the behaviour of the MariaDBDiscountsRepository.

Again M5 should be killed by refactoring, not testing. We can simplify the implementation and keep the same behaviour of the MariaDBDiscountsRepository by removing the whole ternary Operator (? :):

This is the code of MariaDBDiscountsRepository after applying two simplifications:

and this is the final version of the tests that kill all the relevant mutants:

Notice how we have managed to kill M2 while at the same time avoiding overspecifying 'should throw an error when discount is not found' by asserting the exception type and that the exception message contains the non-existing discount code (the only part of the message we care about), instead of asserting the exception type and the whole exception message. That way the “literature” around the discount code can change without breaking our test.

Learnings from Relevant Mutants.

Not all surviving mutants need to be killed: Those in legacy seams or in code only used by code in legacy seams survive because that code is intentionally not exercised by the tests.
Not all surviving mutants that need to be killed should be killed by testing “better”, some should be killed by refactoring (simplifying superfluous code or deleting dead code).

In this example, we should have never asked the agent to kill M3, M4 and M5 by “improving” the test suite in the first place. The result of having done it was a much harder-to-maintain test suite and “ossifying” unnecessary behaviour with tests.

Unless we’re able to teach our coding agents to discern between these kinds of surviving mutants, I think we should stay in the loop to help them.

In a future post, we’ll show a better way to give feedback to coding agents when using mutation testing.

Summary.

In this experiment, we used a coding agent to generate both the implementation of a repository and its tests, then used mutation testing to evaluate the suite. Our goal was to illustrate the pitfalls of a workflow we find worrying: treating mutation testing as a mechanical way to “improve” AI-generated tests without humans in the loop. The initial tests looked reasonable, but once mutation testing exposed several surviving mutants, we deliberately followed the naive path: just asking the agent to eliminate them all.

The result was exactly what we expected. We reached a 100% mutation score, but the agent got there by introducing a mix of overspecified assertions, duplicated coverage, and tests for scenarios that can’t actually occur given the database constraints. It even generated unit tests that used test doubles for types we don’t own, tightly coupling the tests to implementation details. On paper, the metrics improved; in practice, the test suite became more fragile.

When we reviewed the generated tests carefully, we saw that only a small subset addressed real weaknesses in the test suite. Some surviving mutants, known as relevant mutants, were useful signals pointing to missing boundaries or weak assertions, and improving or adding tests to kill them made sense. But other surviving mutants weren’t related to test problems at all. They were symptoms of unreachable or superfluous code: cases where the implementation could be simplified without changing behavior. For those, adding tests didn’t improve confidence; it just entrenched unnecessary complexity. To fix the mess produced by the naive approach, we deleted the unit tests generated by the agent and “killed” these latter mutants by refactoring and simplifying the production code. By removing the superfluous logic, we ended up with a simpler implementation of the repository and a more maintainable test suite.

The point of this exercise is to show that blindly prompting a coding agent to enhance a test suite until all mutants are killed is a mistake. It is an approach that risks wasting a lot of tokens in the process to get a less maintainable test suite. Not all mutants are worth killing with tests, and treating a mutation report as a checklist for an agent encourages overfitting and brittle design. Our experience suggests that we must remain in the loop to discern how to treat each surviving mutant; leaving that judgment entirely to a coding agent is a risky and expensive practice.

Acknowledgements.

I’d like to thank Fernando Aparicio, and Fran Reyes for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Pavel Danilyuk for the photo.

References.

Relevant Mutants, Manuel Rivero
Relevant Mutants in a Flash, Manuel Rivero
Growing Object Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce.
Mock roles, not objects, Steve Freeman, Nat Pryce, Tim Mackinnon and Joe Walnes.
Mock Roles Not Object States talk, Steve Freeman and Nat Pryce.
Testing on the Toilet: Don’t Mock Types You Don’t Own, Stefan Kennedy and Andrew Trenk.

Notes.

[1] We used an example from one of the sessions of the deliberate practice program we have been running for Audiense’s developers since 2022.

[2] In the deliberate practice session, we used TDD rather than AI agents to develop the repository. These sessions are designed with two goals in mind:

Keep fundamental engineering skills strong, avoiding skill atrophy induced by AI.
Introduce new technical practices and ideas to the team on a continuous basis.

[3] We actually extracted a helper method with our IDE to improve the readability of the generated tests.

[4] We think, it is important to note that, as shown in the review of the tests, we consumed a significant amount of tokens chasing a goal that was fundamentally misguided. Because the agent lacked the context to see that some mutants were simply signalling unreachable or superfluous code, it spent expensive cycles trying to ‘kill’ with tests, mutants that should have been refactored away or ignored. With just a moment of human feedback, we could have avoided this expensive errand and focused the AI on the mutants that actually mattered. Instead, we didn’t just waste tokens; we effectively paid to introduce technical debt in the form of fragile, coupled unit tests.

[5] Several good sources to understand why using test doubles for types you don’t own is a bad idea:

Subsection 4.1 Only Mock Types You Own of section 4. Mock Objects in Practice of paper Mock roles, not objects. Probably the original source of the idea.
Section Only Mock Types That You Own from chapter 8 of GOOS book.
The post Testing on the Toilet: Don’t Mock Types You Don’t Own

[6] You can read about this idea in these two posts:

[7] In Spanish we say: “muerto el perro se acabó la rabia” 😅

Refactoring with AI: Introducing a State Pattern using a coding agent

2026-04-10T05:30:00+00:00

Introduction.

This is a snapshot of an intermediate step of a kata we use to practise specification testing and test doubles^[1].

The Course class presents a case of the temporary field code smell, which occurs when a field is set only at certain times and is null or unused at other times, making the object harder to understand and maintain. This is what happens with the startTime field which is implicitly set to null until the start method gets called. As usual, the temporary field comes with a null check code smell which is avoiding a NullPointerException in the computeMinutesBetween method.

As we’ve seen in previous posts^[2], a temporary field may indicate a deeper design issue. In this case the Course class is representing three different states of a course:

A course that has not started yet.
An ongoing course.
A finished course.

We can remove both the temporary field and the null check code smells by introducing a state design pattern that explicitly models this state machine and removes conditional code.

Course state machine diagram.

Introducing the state design pattern is an involved refactoring that comprises extracting new classes, introducing polymorphism and moving behaviour around. We’ll show how we can accelerate it with the help of an AI coding agent.

Refactoring to the state design pattern with an AI agent.

I passed the following prompt to the copilot cli agent using the Claude Sonnet 4.6 model with the default thinking effort (balanced, thinks on harder problems).

Let’s introduce a state pattern.

Course class will keep its current interface.

Course will use an abstract class of type CourseState that will represent its state.

CourseState is an abstract class with the following public methods: void showDetails(), > CourseState start() and CourseState end(), of which start and end are abstract.

CourseState is going to be derived by three concrete states:

Concrete classes representing states:

YetToStartCourseState: This is the initial state of Course.

OnGoingCourseState: Pass its startTime through its constructor: new OnGoingCourseState(startTime, clock, configuration, courseView).

FinishedCourseState: Pass its durationInMinutes through its constructor: new FinishedCourseState(durationInMinutes, clock, configuration, courseView).

Initial state: YetToStartCourseState

Final state: FinishedCourseState

Possible transitions:

YetToStartCourseState —-start()—-> OnGoingCourseState YetToStartCourseState —-end()—-> YetToStartCourseState OnGoingCourseState —-start()—-> OnGoingCourseState OnGoingCourseState —-end()—-> FinishedCourseState FinishedCourseState —-start()—-> FinishedCourseState FinishedCourseState —-end()—-> FinishedCourseState

The agent generated the following new classes: CourseState, YetToStartCourseState, OnGoingCourseState and FinishedCourseState.

CourseState is an abstract class:

And the state classes YetToStartCourseState, OnGoingCourseState and FinishedCourseState derive from CourseState:

This the resulting code of the Course class that delegates all its operations to its inner state:

We can consider this transformation a refactoring because:

a. It preserved observable behaviour: all tests still passed after it, and b. It improved maintainability: both the temporary field and null check code smells were removed.

The agent did a great job introducing the state design pattern, and it did it in less time than what it had taken me to refactor it using the IDE (IntelliJ Idea in this case).

Using our metadocumentation to learn.

Let’s have a look at the metadocumentation generated by the agent.

The reasoning document is very interesting:

Even though the agent does not mention the temporary field code smell, it describes the initial design saying that Course managed its lifecycle internally using nullable fields and having a null-check to distinguish “not yet started” from other states.

The alternatives that it considered and then rejected are also very interesting to me, and I agree with all its decisions:

Override showDetails() in each concrete state, which would have created duplication that we would have had to remove with a Pull Up Method refactoring.
Keep name only in Course, pass it on each showDetails() call, which is really not necessary.
Make transitions a lookup table / enum, which would have been over-engineering for only three states.

This was the feedback the agent gave me on my prompt:

It states that giving it a transition table was the most valuable part of the prompt, and advises me to do it in future prompts that ask to introduce state machines.

Two other things that were useful were telling it to preserve the interface of Course which eliminated many options to explore, and specifying the parameters of each constructor which clarified the intent of each state.

In the prompt I forgot to add name as a parameter of the constructors of the state classes. I didn’t realize that until I read the feedback. In spite of that, the agent realized that that was a mistake and that name needed to be passed as a parameter to all the constructors.

The three other gaps in the prompt were things I considered obvious. They were not a problem using the copilot cli agent with the Claude Sonnet 4.6 model, but they may have been problematic using a different combination of agent and model^[3].

My learning is that some things that are obvious to me may not be so for the model, and that If I had any doubts that it can handle some expectation by default, I should at least make that expectation explicit. Additions like “classes should not have any unused fields after the transformation“^[4]. or “give methods the least visibility possible” may have proved useful in this case.

Finally, this is the enhanced summary created by the agent:

In the Side effects / follow-up section, there’s a very useful piece of advice that I plan to follow, saying that I need to change the configuration of the mutation testing tool in pom.xml so that targetClasses covers not only the Course class but also all the new state classes.

Improving the design a bit more.

I was very satisfied with the code that the agent generated. However, there is something that I think could have been better: in order to avoid possible cases of the inappropriate intimacy code smell, I’d prefer that all the fields in CourseState were private.

With the current design they have to be protected because they are being used in some derived class to pass them to constructors when there are state transitions.

If we introduced protected factory methods representing the state transitions, the fields could become private to CourseState. The factory methods would also improve the semantics of the code.

Refactoring with an agent or using IntelliJ?

The refactoring to introduce those protected factory methods is not very involved if we use an IDE like IntelliJ Idea. With this IDE, we only need to chain two automated refactorings for the state transition from YetToStartCourseState to OnGoingCourseState, and three automated refactorings for the state transition from OnGoingCourseState to FinishedCourseState.

These chains of automated refactorings are detailed in the following table:

Transition	Chain of Automated Refactorings
YetToStart -> OnGoing	Extract Method -> Pull Up Method refactoring
OnGoing -> Finished	Introduce Variable -> Extract Method -> Pull Up Method refactoring

I felt that using an agent for this refactoring would not be more efficient than using the automated refactorings in the IDE, even considering that the Pull Up Method refactoring does not have a default shortcut associated with it in IntelliJ Idea (which is fine because we don’t use this refactoring so often).

In order to test my gut feeling, I decided to do the following experiment:

Measure the time it takes me to refactor to the desired design with IntelliJ Idea.
Revert the change.
Measure the time it takes me to write the prompt and the agent to process it (I didn’t include the time it took the agent to generate the metadocumentation which happens at the end).

This is the result of the experiment:

Using automatic refactorings in IntelliJ Idea: 4’.
With the agent (prompt writing + agent execution): 7’.

My intuition was right, it was shorter to refactor it myself using IntelliJ Idea.

If you’re curious about the prompt I used, here it is:

I want to make all the fields in CourseState private. To do that first extract to method the state transition in OnGoingCourseState’s end() method to a method accepting startTime as a parameter and the state transition in YetToStartCourseState’s start() method, then pull both methods up to CourseState.

After your changes all tests should be still passing and all fields in CourseState should be private.

I also attached to the prompt the four course state classes.

The agent got to a final design that was exactly like mine. In fact, I think the names it gave to the factory methods were better than mine. You can check the final code of the state hierarchy in this gist.

I think that asking an agent to do a small refactoring like this one, that can be made with a short chain of automatic IDE refactorings, would have been fine for me only if I let the agent do it autonomously while I have a break.

Some people would say that I could have worked on another task while the agent was working, but there are two reasons I prefer not to:

Seven minutes is not too long, and switching contexts take some time.
We already know that multitasking is not good for anyone’s brain nor productivity.

My current aspiration is getting to an approach to AI similar to what Mitchell Hashimoto describes in My AI Adoption Journey.

Another advantage of automatic IDE refactorings is that they are deterministic and tend to be safe^[5].

I prefer to use an agent for refactorings in which there’s really a speed boost, so that taking the risk of assuming possible reworks associated with non-determinism is still worth it.

Using our metadocumentation to learn.

Let’s start with the reasoning file:

In the reasoning, we can see that the agent followed the process outlined in the prompt. I wonder whether the agent would still be able to produce correct code if the prompt were more vague and required less effort to write (I may test this in the future).

If we have a look at the alternatives the agent considered and rejected, I’m satisfied of its decisions and the reasons why it took them:

Add getters instead of pulling up methods, this option would have achieved the goal of making the fields private, but as the agent says “would expose the fields indirectly and leave transition logic scattered”. It rejected this option because “it moves in the wrong direction for encapsulation”, which I think is totally right. I also prefer a tell don’t ask approach.

I think this option would have probably been accepted if I had written a more vague prompt like:

I want the fields in CourseState to be private. Make the changes in the state classes to make it possible without altering its public interface. All tests should pass after your changes

Keep fields protected final: the agent says that this option is “simpler but weaker encapsulation” which is true. What I like is the reason why it rejects it: because rejecting it is “in favour of the user’s stated goal”.

I don’t like its reasoning simply because the agent followed my suggestion; instead, I like it because, in this simple case, it’s true that encapsulating the fields offers little advantage. I think the agent is indirectly recognizing that we may be trading simplicity for insufficient benefits, since the signal of the inappropriate intimacy code smell is currently very weak.

Let’s see now the feedback about my prompt:

Of the three improvement suggestions, I think the most valuable to me is the one about clarifying the visibility of the pulled-up methods.

I don’t care about the suggestion about unused-import cleanup because that is something I can automatically and deterministically do with other tools at the end or in a hook. Why make the agent spend time and tokens on something that is solved cheaper, faster and safer by other existing tools? The Offload Deterministic augmented coding patterns states:

“Don’t ask AI to do deterministic work. Ask AI to write code that does it.”

I think that, when a reliable deterministic tool already exists and is available, we are better off applying an extension of the Offload Deterministic pattern:

“Don’t ask AI to do deterministic work for which a deterministic tool already exists. Use the tool if available; otherwise, ask AI to write code that does it.”

Regarding the suggestion about naming, in this case, I was very confident that the agent would get the naming right, given the names of the constructors mentioned in the prompt and that I was stating that the methods were factories. However, in other not so clear-cut cases, I think I would follow its suggestion. In any case, renaming is often safe and easy in most IDEs.

If you feel like, you can check the summary file in this gist, for completeness sake.

Conclusions.

In this post, we’ve explored using a coding agent to introduce the state design pattern into an existing design that was implicitly handling multiple states. By making those states explicit, we moved from a Course class with a temporary field and null checks code smells to a clearer design based on polymorphism and explicit state classes.

We prompted the agent, describing the state transitions of the desired state machine and some constraints, and let the agent carry out the bulk of the transformation: extracting state classes, redistributing behaviour, and removing conditional logic. The result was a design that better reflected the domain, with each state owning its responsibilities and transitions.

Looking at the agent’s metadocumentation gave us additional value beyond the code itself. It helped us understand how the agent interpreted the problem, what alternatives it considered, and how our prompt shaped the outcome. One clear takeaway was that being explicit, especially about transitions and invariants, can make a noticeable difference in the quality of the result.

We also iterated on the design after the initial refactoring, improving encapsulation in CourseState and introducing factory methods for transitions. That step served to perform an experiment that compared approaches: while the agent was capable of performing the refactoring, traditional IDE-supported transformations proved faster and more predictable in this case.

We used the introduction of the state pattern to explore how and when a coding agent can help with structural refactorings. Our experience suggests a balanced approach: rely on the agent when it meaningfully accelerates complex changes, and lean on deterministic tools when they provide a simpler path.

Acknowledgements.

I’d like to thank Fernando Aparicio, Fran Reyes and Alfredo Casado for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Maxwell Pels for the photo.

References.

Notes.

[1] This code is a snapshot of an intermediate step of the Course Duration kata which is part of our training in testing techniques for developers. You can find the contents of the Spanish version in Técnicas de Testing para desarrolladores.

[2] The posts we refer to are:

[3] We tried using the same prompt with Junie using Gemini 3 Flash with very different results.

We didn’t like the resulting code:

It left some dead code (getters for the dependencies), unused fields for the dependencies (only used in the unused getters) and setters in Course (to set the duration of the course).
It set a reference to Course into the CourseState using an attach method that was called right after creating each instance of the course state.
It left several useless “what” comments in the course state classes.
It left an unused field in FinishedCourseState.

You can have a look at the code in this gist.

In a future experiment, we plan to try the improved version of the prompt with Junie and Gemini 3 Flash to see if we get better results.

[4] As we mentioned in the previous note, Junie using Gemini 3 Flash generated exactly this problem.

[5] At least in Java and C#, though not always in dynamic languages.

Detallando historias de usuario para acotarlas y reducir su ambigüedad.

2026-03-27T00:00:00+00:00

Introducción.

En un post anterior, exploramos nuestro flujo de decisión para refinar historias de usuario poco antes de iniciar su desarrollo. Allí vimos cómo utilizar los criterios INVEST para diagnosticar si una historia ya está lista para ser desarrollada y así evitar retrabajo. El principal objetivo de nuestro proceso es aplicar refinamientos específicos que aseguren un desarrollo fluido, minimizar el waste y acelerar la entrega de valor.

También vimos que algunos incumplimientos tanto del criterio de Estimable (E) como del criterio de Testable (T), pueden producirse porque la historia no esté suficientemente acotada o aclarada. Comentamos que ambos casos se podrían solucionar añadiendo más detalle, y dejamos para otro post la explicación de cómo detallar mejor una historia.

En este post profundizaremos en cómo detallar una historia de usuario mediante criterios de aceptación y ejemplos que nos ayudarán a que todo el equipo tenga una visión común de lo que significa que la historia quede realmente “hecha”.

Añadir más detalle.

Antes de empezar a explicar este proceso, nos gustaría recalcar que no hay que añadir todo el detalle posible a una historia de usuario de golpe, de hecho esto podría ser contraproducente ya que podría ocasionar waste. Es más aconsejable detallar las historias de usuario de forma incremental.

Los detalles acotan y aclaran los límites de la historia^[1]. Esto permite que todos los participantes empiecen a tener una visión compartida sobre el tamaño de la historia y todos los comportamientos que se esperan de ella.

Durante el proceso de añadir detalle, se hace más evidente lo que se espera de la historia, y esto puede hacer que nos planteemos si podría ser mejor hacer ciertas partes en otra historia (o directamente descartarlas). Así, el proceso de añadir más detalle puede llevarnos a evaluar el criterio Small (S) para plantearnos si hay algún tipo de partición que pueda ser beneficioso^[2].

Este ciclo de añadir detalle y evaluar el criterio Small antes de continuar haciendo crecer la historia, es fundamental para entregar de manera incremental y no generar waste haciendo trabajo innecesario.

Justo antes de empezar a desarrollarla, acabar de completar el detalle de una historia ayuda a que todas las personas del equipo estén alineadas en lo que significa que una historia de usuario esté “hecha”. Es decir, buscamos cumplir uno de los aspectos más importantes de la historia de usuario: la confirmación^[3].

La manera más efectiva de añadir detalles justo antes de empezar a desarrollarla es utilizando criterios de aceptación^[4] y ejemplos^[5] que aclaren el alcance, reduzcan la ambigüedad y ayuden a entender los escenarios^[6].

En el siguiente diagrama mostramos este proceso de detallar una historia mediante criterios de aceptación y ejemplos, y las diferentes preguntas qué nos podrían ayudar a saber si hace falta detallarla más.

Preguntas clave al añadir más detalle

Paso 1.

Tenemos que examinar cada criterio de aceptación que ya tiene la historia de usuario preguntándonos:

¿Es este criterio de aceptación claro y contiene suficientes ejemplos?.

Si un criterio de aceptación no está bien definido o presenta ambigüedades, lo cambiaremos y le añadiremos ejemplos que ayuden a su comprensión.

Es posible que, tras aclarar estos criterios de aceptación ahora abarquen más de lo esperado. En ese caso, conviene reevaluar si existe una manera de dividir la historia en incrementos de valor más pequeños.

Además, por cada uno de los ejemplos de cada criterio de aceptación, podríamos explorar si existen otros escenarios. Para explorar otros escenarios creemos que resulta especialmente útil aplicar los patrones conversacionales que propone Liz Keogh en Conversational patterns in BDD ^[7].

Los patrones conversacionales cuestionan el contexto (GIVEN) y el resultado (THEN) de escenarios expresados siguiendo el patrón Given-When-Then, de la siguiente manera:

Para cuestionarnos el contexto (GIVEN) nos hacemos preguntas del tipo ¿Existe algún otro GIVEN que, para el mismo WHEN, nos dé un THEN diferente?
Cuando estamos cuestionando el resultado (THEN) nos hacemos preguntas del tipo ¿Hay algún otro THEN importante dado este contexto GIVEN y WHEN?

Paso 2.

Una vez hemos aclarado los criterios de aceptación existentes, tenemos que preguntarnos si hacen falta más criterios de aceptación para acabar de aclarar la historia de usuario.

Para cada nuevo criterio de aceptación que añadamos tenemos que volver aplicar el paso 1.

Explorar ejemplos ¿Posibles particiones?.

Al explorar nuevos ejemplos que no habían sido explorados aún o detallar mejor otros, es posible que la historia crezca demasiado. Por tanto, aquí es otro momento en el que conviene volver a reflexionar si existe alguna división que nos pueda ayudar a conseguir entregar antes, reducir riesgo y obtener feedback antes^[8].

Conclusión.

Añadir más detalle a una historia de usuario no consiste en documentar todo de una vez, sino en aclarar progresivamente su alcance hasta lograr un entendimiento compartido de qué significa que la historia de usuario esté “hecha”. Los criterios de aceptación y los ejemplos son las herramientas clave para reducir ambigüedades, alinear al equipo y facilitar tanto la estimación como la validación.

Durante este proceso es habitual descubrir huecos, nuevos escenarios o incluso la necesidad de dividir la historia para mantenerla manejable y orientada a entregar valor cuanto antes. Por eso, detallar y evaluar el tamaño de la historia deben verse como actividades iterativas y complementarias.

Aplicar preguntas sistemáticas ayudan a explorar contextos y resultados alternativos, disminuyendo el riesgo de que haya interpretaciones distintas dentro del equipo.

En definitiva, añadir detalle de forma intencional e incremental mejora la calidad de las historias, reduce incertidumbre y favorece un desarrollo más fluido y predecible, que permitirá entregar valor antes y con menos waste.

Agradecimientos.

Nos gustaría agradecer a Edward Jenner la foto.

Serie Historias de Usuario.

Este post es parte de una serie sobre Historias de usuario:

¿Tamaño y nivel de detalle adecuados para una historia de usuario?.
Nuestro flujo de decisión para refinar Historias de Usuario poco antes de empezar a desarrollarla.
Detallando historias de usuario para acotarlas y reducir su ambigüedad.

Referencias.

Notas.

[1] Como ya comentamos en nuestro post ¿Tamaño y nivel de detalle adecuados para una historia de usuario?.

[2] Hay múltiples heurísticas de particionado. En este post hablamos de SPIDR que puede ser un buen punto de partida. En el curso de Historias de Usuario nos basamos en el trabajo de William Wake.

[3] La confirmación es uno de los aspectos esenciales enunciados por Ron Jeffries en su artículo de 2001, Card, Conversation, Confirmation.

[4] Algunos autores usan el concepto de condiciones de satisfacción o reglas para hablar de los criterios de aceptación por diferentes motivos. Mike Cohn prefiere utilizar condiciones de satisfacción y en Example Mapping se utiliza el concepto de Rules.

[5] Tener ejemplos en la historia de usuario nos ayuda muchísimo a tener un TDD fluido, ya que parte importante del trabajo al hacer TDD es obtener ejemplos reales. Incluso si hacemos los tests a posteriori, también reducimos el coste de hacerlos ya que podemos usar o partir de los ejemplos que la historia contiene.

[6] Nos gustaría señalar que hay escenarios donde resolver las dudas producidas por la falta de detalle tiene un coste diferente dependiendo de cómo esté organizado el equipo. Por ejemplo, en un equipo que hace Mob programming resolver estas dudas tiene un coste muchísimo más bajo que en un equipo al que, por problemas de disponibilidad, le cueste uno o dos días obtener una respuesta.

[7] Otra técnica interesante para explorar escenarios es aplicar Decision Table Testing (DBT) a escenarios o ejemplos existentes. Hay un ejemplo detallado de cómo aplicar tablas de decisión para explorar escenarios de BDD en la sección 11.3.1.1 Behavior-Driven Development del libro Software Testing A Craftsman’s Approach 5th Edition de Paul C. Jorgensen & Byron DeVries.

[8] Hay varias heurísticas interesantes que nos pueden indicar posibles particiones. En este artículo hablamos sobre SPIDR, que puede ser un buen punto de partida. En el curso de Historias de Usuario nos basamos en el trabajo de Bill Wake.

Metadocumenting to Improve Our Interactions with Coding Agents: Capturing Reasoning, Summaries, and Prompt Feedback

2026-03-25T05:30:00+00:00

Lately I’ve been experimenting with a small addition to my project setup when practising with coding agents.

I add a meta documentation section at the end of my project instructions (AGENTS.md or copilot-instructions.md) that asks the agent to generate three small markdown files after every change to the code: one documenting the agent’s reasoning, another one giving me feedback on my prompt and the last one including an extended summary of the changes.

1. The reasoning file.

This file documents the step-by-step decisions and alternatives considered by the agent. It helps me see how the agent approached its solution, including trade-offs and paths not taken. I can learn about options I hadn’t considered, or see how distinct trade-offs were evaluated when making a decision. It’s reassuring for me, somehow, when I find that the agent makes the right choice for the right reasons.

2. The prompt feedback file.

In this file the agent critiques my original request and suggests how I can improve it. It highlights where I was vague or could have structured things better. It also highlights the information and structure in my prompts that were most useful to the agent. Hopefully, this feedback will help me to reflect and gradually improve how I communicate with the agent.

3. The extended summary file.

This file explains what changed, why it matters, and what to review. Its content is similar to what the agents I’ve worked with give me by default, but enriched with:

The “Why” behind the changes. This helps me to connect each change made to its intent. Reading the “Why” the agent is able to deduce helps me see how aligned the agent and I are, and discover new points of view.
The consequences of each change and follow-up actions the agent thinks I should be aware of. This has already helped me identify some potential pitfalls and mistakes.
A list of key aspects to verify during code review, and advice on how to ensure that they are verified during the review. Personally, since I’ve been mostly trying big, involved refactorings so far, what I’m striving for is for the agent to tell me that there’s nothing to review because all aspects were covered by tests. When that is not the case, it means I’ve discovered something to improve in my process.

My goal with these metadocuments is to somehow get some visibility into the decision-making process of the agent in order to create a learning loop that will help me build my intuition.

I’ve iterated this meta documentation section several times with the feedback I’ve received from different agents. This is the one I’m currently using:

I asked Copilot (with Claude Sonnet 4.6) what he thought was the intention of the meta documentation section, and it replied the following:

I’ve found this meta documentation especially helpful in the learning context I’m in. Instead of just reviewing the result the agent generates, I get a bit more insight into how the agent put it together, and how I might improve my next interaction with the agent.

In a big production context, I likely wouldn’t add the meta documentation section to the AGENTS.md. Instead, I’d rather have a command or a stored prompt to only add these documents in sessions in which I consider it worths the trouble.

It’s a small thing, but it’s been for me a useful way to reflect a bit more on both the code and how I’m working with the agent. Maybe it might be useful to you as well.

In future posts about my experiences coding with agents I plan to include things I’ve learned using this meta documentation (now you’ll know where those learnigs come from).

Acknowledgements.

I’d like to thank Manuel Tordesillas for encouraging me to write this post, and Antonio de la Torre, Fernando Aparicio and Fran Reyes for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Joshua Woroniecki for the photo.

Refactoring with AI: Lessons in Introducing a Decorator Pattern

2026-03-05T05:30:00+00:00

Introduction.

In a previous post we explained a refactoring we did to make code and tests more maintainable by introducing a decorator to separate responsibilities.

We refactored the original code and its tests using the AI assistant in WebStorm.

This post shows how we guided the AI assistant through this refactoring, the problems we faced and our learnings.

Introducing the decorator.

This is the initial code of the AcmeCompanyApi class:

We prompted the AI assistant with:

create a decorator of CompanyApi called WithErrorHandlingCompanyApi that handles all the possible error cases that AcmeCompanyApi is currently handling

This prompt made the AI assistant create the WithErrorHandlingCompanyApi decorator and simplify the AcmeCompanyApi class by removing all the error handling:

It did it much better than we expected taking into account we just used a one-shot prompt and no rules file: the tool correctly created the decorator and removed all the error handling logic from the decorated class. We think that using design patterns vocabulary in the prompt might have helped.

However, it forgot to update the factory function that was creating AcmeCompanyApi which made the tests fail:

So, we updated it manually to make all tests pass again:

We could have reduced the probability of the AI forgetting to update the factory function if we had given it a better context^[1].

Aside from this mistake, the AI-assistant nearly did the refactoring quite well, and, we think, it took less time than it had taken us doing it on our own with the help of WebStorm.

Later we discovered that the AI assistant had slipped in a problem that, while not breaking the behavior, did weaken the type checking. Maybe you’ve already noticed the problem, we didn’t in our first review.

The AI-assistant had changed the signature of the open function in the CompanyApi interface from async open(claim: Claim): Promise<OpeningResult> to async open(claim: Claim): Promise<any>, relaxing the type. This was an unintended change, and not that easy to detect. We only noticed the problem after a while when we were reviewing the result of another AI-assisted transformation.

In retrospect, we could have automatically detected this problem with a linter. For instance, using typescript-eslint with the no-explicit-any rule ^[2]. We think this kind of guardrail would become even more crucial if we were working with coding agents.

Simplifying the tests.

These were the original tests we had for the error handling in AcmeCompanyApi (we had separated in different files the tests for the happy past and the error handling):

They were still simulating the behaviour of the interfaces ForGettingCauses, ForOpeningClaim and AuthTokenRetriever with test doubles.

These tests did a great job protecting the behaviour while introducing the WithErrorHandlingCompanyApi decorator (they had catched an error introduced by the AI changes, remember), but, once the decorator was there, we used the AI assistant to simplify the tests and reduce their coupling to the production code.

We used the following prompt:

change the tests so that they test the WithHandlingErrorsCompanyApi. The test should mock only the CompanyApi interface

The AI assistant modified the tests producing the following code:

It nearly got it right, however this code did not type check because the usage of mockRejectedValue was producing the following error:

TS2345: Argument of type CannotRetrieveTokenError is not assignable to parameter of type never

We asked the AI assistant how to fix it but it started to hallucinate badly…

After some research on our own, we found that using mockImplementation worked, so we prompted the AI to use mockImplementation instead of mockRejectedValue, and that fixed the tests:

use mockImplementation instead of mockRejectedValue

We still need to learn to recognize sooner when AI is confidently leading us down a wrong path, and we’d be better off retaking control.

A pleasant surprise was that we learned that it’s possible to type the functions you are mocking with jest.fn():

This is an example of how we can use AI to learn alternative ways to do something.

Once it worked, we used the IDE to remove the unused factory function at the end of the file.

Then we told the AI assistant to add a test that was missing using the following prompt:

add a test case for when it fails with an unknown error

It didn’t need more context because we used the inline Generate code with AI option of the Generate command in WebStorm. This was the generated code:

As we explored in our previous post, the goal of this refactoring was to move from a coupled implementation to a clean separation of concerns. The following table summarizes the structural shift we were aiming for:

	Original code	Refactored (Decorator Pattern)
Business Logic	Mixed with error handling	Isolated in `AcmeCompanyApi` (decoratee)
Error Handling	Mixed with business logic	Encapsulated in `WithErrorHandlingCompanyApi` (decorator)
Test-to-production-code coupling	3 interfaces (3 test doubles)	1 interface (1 test double)

Reduction in complexity.

Simplifying the design.

Then we created a factory class to compose AcmeCompanyApi and the decorator that handled its errors with the following prompt:

create a AcmeCompanyApiFactory class with a create static method that composes AcmeCompanyApi and the handling errors decorator. Do not use it anywhere yet.

which produced the following class:

Next we introduced the AcmeCompanyConfig as fourth parameter of the constructor of AcmeCompanyApi using the IDE and then prompted the AI with:

initialize the fields creating instances of the 3 interfaces in the constructor and change the signature of the constructor so that it receives only the configuration

We could have omitted the last step, changing the constructor interface to remove the unused parameters, using the Change Signature automatic refactoring instead.

This would have been a much safer option because Change Signature is a deterministic transformation unlike using AI. However, we wanted to explore if the AI assistant could manage this transformation well, and so it did:

Finally, we asked Junie (JetBrains’ agentic assistant that can handle multi-file tasks and verify its own work) to do the following:

use the implementations of the 3 interfaces to type the fields in the AcmeCompanyApi and then remove the interfaces ForGettingCauses, ForOpeningClaim and AuthTokenRetriever

in order to materialise the peers demoting them to be internals. It produced the following code that worked fine:

We only had to manually remove the default value of the config parameter in the constructor to finish the job.typescript-eslint

Summary.

The post describes how we used an AI assistant in WebStorm to refactor a codebase by introducing a decorator that separates error-handling responsibilities from the AcmeCompanyApi class. With a simple prompt, the AI successfully created the WithErrorHandlingCompanyApi decorator and simplified the original class. However, it failed to update the factory that instantiated the API, causing tests to break, which we fixed manually. Later we also discovered an unintended weakening of type safety: the AI had changed a return type to Promise<any>. A linter such as typescript-eslint could have caught this. This emphasizes the importance of guardrails.

We then used the AI assistant to simplify existing tests. Originally, the tests relied on multiple test doubles, but we prompted the AI to rewrite them so only the CompanyApi interface was simulated. The AI’s first attempt produced type errors when using mockRejectedValue, and its suggested fix was incorrect. After our own investigation, we instructed the AI to use mockImplementation, which resolved the issue. This reinforced the need to recognize when AI guidance is unreliable. A pleasant surprise was that we also learned a new technique: typing functions mocked with jest.fn().

After cleaning up unused code, we asked the AI to add a missing test case for unknown errors, which it generated correctly. We then moved on to simplify the overall design by prompting the AI to create an AcmeCompanyApiFactory to compose the concrete CompanyApi with its decorator. We further refactored the constructor to accept only configuration and to instantiate dependencies internally. Although we could have done this simple deterministic refactoring safer with the IDE, we wanted to explore if the AI could handle this transformation successfully. It did.

Finally, we used Junie to replace several interfaces with concrete implementations, to effectively internalise those collaborators. The generated code worked with only a small manual adjustment needed. Overall, we conclude that the AI assistant significantly sped up the refactoring but also introduced subtle issues, reinforcing the need for careful review, tooling guardrails, and knowing when to take back manual control.

Learnings.

AI sped up a refactoring that would have taken several steps with the IDE: The AI assistant significantly accelerated the process of introducing the decorator. We used it also to create a factory class, although in this latter case doing it with the IDE would have taken less or as long. We think that using a pattern as a refactoring target helped guide the AI assistant^[3].
AI lacks global awareness: While the AI successfully introduced the decorator, it failed to update the factory that instantiated it, causing broken tests. We could have reduced the probability of this happening by using a better prompt that gave the AI more context.
Subtle degradations are difficult to detect and we’ll need as much help as we can get^[4]: The AI introduced an unintended subtle change that was difficult to notice: it weakened type safety by changing some return types to Promise<any>. It’s difficult for humans to review and detect errors in code that works and is “nearly correct”. We think that we can improve our chances by using automatic, deterministic tools to support us. In this case, a linter triggered by a git hook could have detected and even fixed the type weakening.
Importance of external guardrails: Automatic testing, linters and other tools are going to be more and more necessary to prevent behavioural errors and other problems such as technical debt that AI may introduce into the codebase^[5].
Limits of AI troubleshooting: When the AI’s first attempt to simplify the tests produced type errors, it started hallucinating incorrect fixes. In the end, we had to investigate on our own and fix the problems manually. It’s important to learn to recognize earlier. We need to learn to recognize sooner when AI is confidently leading us down a wrong path, and we’d be better off retaking control.
AI as a source of new techniques: We had the pleasant surprise of learning from the AI a technique for typing functions mocked with jest.fn() that we didn’t know.
Knowing which tool to apply: Even though we used AI for most of the refactorings to explore how it managed, we think that some of them could have been made more safely and faster with deterministic, automatic IDE refactorings, or other deterministic tools like OpenRewrite. Knowing and practising with other tools aside from AI gives you more options.

We’ll go on writing about what we learn as we go on using AI coding tools.

Acknowledgements.

I’d like to thank Fernando Aparicio and Fran Reyes for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Maxwell Pels for the photo.

References.

Notes.

[1] Chatting with Gemini about the problems and ways to improve the prompt to give better context to the AI assistant, it suggested me to use an improved prompt:

Refactor AcmeCompanyApi by creating a decorator named WithErrorHandlingCompanyApi to handle all its current error-handling responsibilities. After creating the decorator, identify every location in the codebase where AcmeCompanyApi is instantiated—specifically checking factories or dependency injection modules—and update them to compose the new decorator with the concrete implementation. Ensure that the return types remain strictly typed and do not revert to any.

and explained to me why this prompt is better than the one I used:

Defines the “Blast Radius”: By explicitly mentioning “every location where it is instantiated,” you force the AI to look beyond the single file.
Targets the Weak Point: Specifically calling out “factories” reminds the AI of the specific architectural layer it missed last time.
Sets Type Guardrails: The instruction regarding any prevents the silent degradation of type safety you encountered previously.
Enforces Composition: It provides a clear architectural goal (composition) rather than just a code transformation.

We went on discussing the type guardrails, because, to avoid using up context space, we prefer preventing the type degradation in a deterministic way using a linter triggered by a hook.

[2] Gemini also suggested us how to set up typescript-eslint and a git hook using husky and lint-staged.

We could also do this with something similar to Claude’s hooks.

See Lada Kesseler’s Hook pattern.

[3] We think that using the vocabulary of design patterns may improve outcomes because they encode roles, boundaries, and expectations in a compact form. This is a form of semantic compression: by using the single word “Decorator,” you replace what would otherwise be a detailed technical specification (interface adherence, delegation logic, and constructor injection). For a LLM pattern names likely function not only as semantic guides but also as statistical anchors that steer code generation toward familiar code shapes. This may be helpful to reduce ambiguity and structural drift, but there’s also the risk of prematurely converging on canonical solutions that are not actually the best fit for the problem at hand. We think we still need to study and know when to apply a given pattern and their forces, trade-offs and consequences.

[4] See this interesting talk by Damian Brady: The dangers of probably-working software.

[5] Have a look at Birgitta Böckeler’s great post Harness Engineering.

After discussing for a while with ChatGpt and Gemini (I do that sometimes now…) about a more specific: topic “harnessing AI assisted refactorings”, I got this nice visual summary of the discussion from Gemini:

Navigating AI assisted refactoring

There are many other missing things that can help like, for instance, dividing the transformations in small steps to reduce risk and facilitate reviews, etc.

I wonder, if the old concept of Refactoring Thumbnails might also help us guide AI-assisted refactorings, (I learned about Refactoring Thumbnails in the book Refactoring in Large Software Projects by Stefan Roock and Martin Lippert). For instance, this is the thumbnail for Evolving to the Proxy / Decorator Pattern:

Refactoring Thumbnail for Evolving to the Proxy / Decorator Pattern

Relevant Mutants in a Flash

2026-02-27T05:30:00+00:00

Relevant Mutants.

Not all surviving mutants indicate weaknesses in tests.
Not relevant surviving mutants (don’t signal any test weakness):
- Ignore these ones:
  - In dead code (unreachable code)
  - In legacy seams (intentionally excluded from test execution).
  - Code not used because of legacy seams (also intentional).
- Mutants in superfluous code:
  - They survive because the mutation did not change any behavior.
  - Still useful 💰: signal a possible simplification (refactoring opportunity).
Relevant surviving mutants 💰: reveal genuine gaps in the test suite
- e.g. missing boundaries, too lenient assertions, etc.
Read Relevant Mutants.

Usando Combinaciones de ApprovalsJs en WebStorm

2026-02-25T05:30:00+00:00

Introducción.

En un post anterior, explicamos como integrar ApprovalsJS con WebStorm para facilitar la aplicación de la técnica Golden Master + Sampling que puede ser muy útil cuando trabajamos con código legacy^[1].

ApprovalsJS nos ayuda con algunos de los pasos más complicados y/o engorrosos de la técnica Golden Master + Sampling.

Una estrategia para el sampling.

Una de las partes más tediosas, pero necesaria para poder aplicar la técnica Golden Master es obtener el input y el output necesarios para generar los datos de nuestro golden master inicial, esta obtención de datos es lo que se conoce como sampling (muestreo).

Existen diferentes estrategias para hacer el muestreo. Algunas de ellas son:

Hacer combinatoria de inputs relevantes para el flujo de la aplicación y grabar el output correspondiente. Esta estrategia se puede hacer incrementalmente o con utilidades facilitadas por librerías.
Generar input de forma aleatoria y grabar el output correspondiente.
Grabar el input y output en una ejecución real del software para luego usarlo en los tests.

La elección de una u otra estrategia dependerá de nuestro contexto, pero lo ideal es elegir una estrategia que nos permita generar el golden master con el menor coste posible.

Si tras evaluar nuestras opciones está la posibilidad de hacer combinatoria de inputs (estrategia 1), la librería ApprovalsJS puede facilitar bastante este trabajo.

Generando combinaciones de inputs con Approvals.

ApprovalsJS proporciona la función verifyAllCombinations que genera todas las combinaciones posibles de los valores de inputs que le indiquemos.

ApprovalsJS también se encarga de grabar el output aprobado.

La aprobación del output es responsabilidad del desarrollador, aunque, como ya vimos en posts anteriores, ApprovalsJS proporciona herramientas que la facilitan.

La firma de la función recibe como primer parámetro la función que ejecutará al sistema que estamos testeando y devolverá el output que esperamos verificar. Los siguientes parámetros de entradas son opcionales, y cada uno de ellos es un array de valores correspondiente a cada parámetro de la función que ejecuta al sistema que estamos testeando.

Veamos un ejemplo de uso:

El test que se muestra en el ejemplo generará como input para la función updateStore el producto cartesiano de los conjuntos {‘Regular’}, {0, 1, 5} y {20, 50, 49, 1}. Eso quiere decir que, cuando aceptamos el output que produce el test, habremos generado un golden master que consta de 1 x 3 x 4 = 12 ejemplos que son el resultado de combinar los conjuntos de inputs iniciales, es decir habrá un ejemplo cuyo input es 'Regular', 0, 20, otro con 'Regular', 1, 20, otro con 'Regular', 5, 20, etc.

Usar combinaciones con ApprovalsJS puede ser muy útil en aquellos casos en los que conocemos qué valores de inputs son relevantes para conseguir ejercitar diferentes flujos de ejecución.

Problemas al usar verifyAllCombinations en WebStorm.

En post anteriores, explicamos cómo al utilizar ApprovalsJS desde WebStorm nos encontramos con el problema de que no lanzaba la herramienta de diff que se usa en caso de encontrar discrepancias entre el output aprobado (golden master) y el output real que está generando la ejecución de los tests (dicha herramienta se denomina Reporter^[2]). Dicho problema lo superamos configurando la herramienta para incluir en la lista de reporters, un reporter que creamos para que funcione con la herramienta de diff de WebStorm: WebStormReporter.

Este era su código:

Pero esta solución no nos sirve en el caso de verifyAllCombinations ya que este método no nos permite configurar qué reporter usar pasando un parámetro, como sí que hacía la función verifyAsJson. Así que debemos buscar otra solución.

Nuestra solución.

La solución que hemos encontrado para poder configurar el reporter consiste en cambiar la configuración por defecto de ApprovalsJS antes de ejecutar la función verifyAllCombinations.

Como la configuración por defecto de ApprovalsJS tiene un ámbito global, cualquier cambio que le hagamos puede influir en la ejecución de otros tests. Para evitarlo, debemos deshacer el cambio después de ejecutar verifyAllCombinations dejando la configuración por defecto de ApprovalsJS en su estado anterior. Con este fin escribimos un wrapper para la función verifyAllCombinations. Nuestro wrapper, primero, modifica la configuración de ApprovalsJS para que use el reporter que queremos, después llama a verifyAllCombinations, y por último, deja la configuración como estaba inicialmente.

Este es el código del wrapper:

La clase WebStormReporter se quedó como estaba.

Para utilizar el wrapper solo tenemos que importarlo en nuestros tests en vez de importar la función verifyAllCombinations de la librería. Con esto ya basta porque el wrapper tiene la misma firma que la función de la librería:

Conclusión.

En este post abordamos un problema que se nos presentó al usar la función verifyAllCombinations de ApprovalsJS desde WebStorm en el contexto de la técnica Golden Master + Sampling.

Resulta que en WebStorm no se lanza correctamente la herramienta de diff cuando aparecen discrepancias entre el output aprobado y el que generan los tests. Esto sucede porque la interfaz de la función verifyAllCombinations no permite configurar el reporter por parámetro, a diferencia de otras funciones de la librería.

La solución práctica que planteamos consiste en crear un wrapper alrededor de verifyAllCombinations. Este wrapper cambia la configuración por defecto para forzar que se use el reporter compatible con WebStorm que presentamos en posts anteriores, WebStormReporter, ejecuta la verificación y finalmente restaura la configuración original para evitar que se vean afectados otros tests. De este modo, podemos usar verifyAllCombinations en WebStorm sin perder la integración con la su propia herramienta de diff.

Referencias.

Notas.

[1] Vemos esta y otras técnicas en profundidad en nuestro curso Cambiando Legacy.

[2] Approvals define toda una serie de abstracciones fundamentales (Writer, Reporter, Namer..) que permiten extender su comportamiento y adaptarlo en caso de que sea necesario.

Composing responsibilities to reduce coupling and improve tests' maintainability

2026-02-22T05:30:00+00:00

Introduction.

We’d like to show an example of how composing responsibilities reduced the coupling between tests and production code and enabled simplifications, both in tests and production code, which led to more maintainable tests.

The original code.

This is the original code of the AcmeCompanyApi class.

AcmeCompanyApi had the responsibility of opening a claim in Acme insurance company. To do that, it was coordinating interactions with three endpoints that were required to open a claim. AcmeCompanyApi was also in charge of handling all the possible exceptions that those interactions can throw.

We had a broad integration test written using Wiremock for the happy path of AcmeCompanyApi that was virtualizing the three endpoints. We also had focused integration tests for each endpoint also using Wiremock to check that all possible errors were mapped to domain exceptions.

Since test-driving the error handling in AcmeCompanyApi with broad integration tests felt too cumbersome, we decided to introduce three interfaces (ForGettingCauses, ForOpeningClaim and AuthTokenRetriever) to simulate problems in the interactions with the endpoints. Notice that these interfaces were introduced only to make testing the error handling logic easier and that they had only one implementation (AcmeCausesEndpoint, AcmeClaimOpeningEndpoint and AcmeAuthTokenRetriever, respectively).

These are the initial tests of AcmeCompanyApi’s error handling logic:

The problem with these tests was that they had a low structure-insensitivity because they are coupled toForGettingCauses, ForOpeningClaim and AuthTokenRetriever, and any change in those interfaces would force to change the tests of the error handling logic, even in cases in which its behaviour hadn’t changed.

How can we enhance the structure-insensitivity of tests for error handling logic while simultaneously avoiding having to write cumbersome broad integration tests?

The real problem: poor separation of concerns.

We traced the origin of the problem to AcmeCompanyApi having too many responsibilities:

Opening a claim.
Handling all the possible exceptions that could be raised and mapping them to an adequate OpeningResult.

We decided to separate those two responsibilities by introducing a decorator of the CompanyApi that would be in charge of handling the errors, that we could compose with a new version of AcmeCompanyApi, only responsible for opening a claim.

We used AI assistance to introduce this decorator, and it went quite well. We’ll explain the process in a future post. This post focuses only on how separating responsibilities reduced coupling between tests and production code, and thus, improved the tests’ maintainability.

The code after introducing the decorator.

This is the resulting code of the AcmeCompanyApi class after introducing the decorator:

Notice how there’s no error handling logic left.

This is the code of the new decorator, WithErrorHandlingCompanyApi, in which we moved the error handling logic:

The simplified tests of the error handling logic are now only coupled to the CompanyApi interface. Remember that with the previous design these tests were coupled to three interfaces which had only one implementation each (ForGettingCauses, ForOpeningClaim and AuthTokenRetriever).

These tests were also simplified with AI assistance.

Since the tests were not coupled to these interfaces any more, we materialised^[1] those three peers of AcmeCompanyApi. This is the resulting code of AcmeCompanyApi using internals instead of peers:

This materialisation of the peers was done by AI, as well.

Finally, we completely removed the usage of the unnecessary interfaces from AcmeCompanyApi:

and deleted the unused interfaces.

Separating responsibilities led to both production code and tests that were easier to evolve and maintain. We achieved these benefits by introducing composition. However, this leads to a new problem: how should we know if the object graph we compose has the desired behaviour?

To avoid this decrease in predictability, we can complement the existing unit tests with one broad integration test that checks the desired composed behaviour is there.

Summary.

In this post we have shown how an object with too many responsibilities can lead us to unintentionally increase coupling between tests and production code, when we try to make it easier to test-drive. We also showed how separating responsibilities can lead to simpler and more maintainable tests and production code.

The original AcmeCompanyApi was responsible both for coordinating multiple external endpoints to open a claim and for handling and handling all possible errors. To avoid having to write cumbersome integration tests for the error handling, we had introduced “testing-only” interfaces, which made the resulting tests easier to write, but more sensitive to structural changes, even when behaviour remained the same.

We decided to separate the two responsibilities by introducing a decorator that took over the error handling logic, and allowed AcmeCompanyApi to focus exclusively on orchestrating the claim opening process. This separation made each responsibility explicit in production code and allowed the error-handling logic to be tested in isolation.

As a result, the tests for error handling became simpler and more robust. They had a much better structure-insensitivity because they were only coupled to the CompanyApi interface, the entry point to the role of opening a claim in a company. This decoupling made it possible to materialise the three former peers of AcmeCompanyApi and remove the unnecessary interfaces altogether. At the same time, by using test doubles to simulate that the CompanyApi raises exceptions, we could still avoid writing cumbersome broad integration tests.

Both production code and tests became easier to evolve and maintain because separating responsibilities made each component’s responsibility explicit and reduced coupling between them. However, notice that these benefits came at the price of having to pay careful attention when composing the object graph, because an incorrect composition could lead to unexpected behaviour. To avoid this problem, we should complement unit tests with at least one integration test that explicitly validates the composed behaviour. Doing this improves the predictability of the tests.

In a future post, we’ll show how AI helped in both the introduction of the decorator to separate responsibilities and the later simplifications made possible by the new design.

Acknowledgements.

I’d like to thank Fran Reyes and Emmanuel Valverde Ramos for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Cottonbro Studio for the photo.

References.

Mock roles, not objects, Steve Freeman, Nat Pryce, Tim Mackinnon and Joe Walnes.
Test Desiderata, Kent Beck.
Materialization: turning a false peer into an internal, Emmanuel Valverde Ramos and Manuel Rivero.

Notes.

[1] Emmanuel Valverde Ramos and I talked about materialisation in the post: Materialization: turning a false peer into an internal

Bundling up to reduce coupling and complexity (peer detection techniques)

2026-02-15T05:30:00+00:00

1. Introduction.

In previous posts^[1] we have talked about the importance of distinguishing an object’s peers from its internals in order to write maintainable unit tests, and how the peer-stereotypes help us detect an object’s peers.

We also presented three techniques, described in the GOOS book, to detect object and value types^[2]:

Breaking out.
Bundling up.
Budding off.

and explained in depth one of them: breaking out^[3].

How we detect the need and the mechanism used to apply each of the techniques^[4].

In this post we focus on the bundling up technique.

2. Bundling up.

The bundling up technique is an application of the “Composite Simpler Than the Sum of Its Parts” rule of thumb that the GOOS authors describe in chapter 6, Object-Oriented Style.

Note that “composite” refers to “something made of various parts”. In this post, the terms “composite type” and “composite abstraction” refer to a type composed of other types. They should not be confused with the composite design pattern.

The GOOS authors explain that when we compose object or value types to create a composite type, our goal is for the resulting type to exhibit behaviour simpler than that of its components taken together. This means that the composite should reduce complexity rather than merely aggregate it. To achieve this, the composite type’s API should hide its internal components and their interactions, and expose a simpler abstraction to its consumers, (following the Information Hiding principle), which simplifies its consumers.

In short, the “Composite Simpler Than the Sum of Its Parts” rule of thumb states:

“The API of a composite object should not be more complicated than that of any of its components.”

This rule of thumb is useful for evaluating the outcome of a refactoring that was intended to eliminate complexity by introducing a new abstraction.

The bundling up technique can be used to detect both object and value types.

2. 1. Detecting value types.

For value types, bundling up consist in detecting and eliminating existing data clumps through refactoring^[5].

2. 2. Detecting object types.

For objects, bundling up consist in hiding related objects into a containing object.

Whenever we observe a cluster of related collaborator objects working together to fulfill a specific responsibility for their consumer, it might be a signal of an implicit concept. We can make this concept explicit by introducing a new composite object type that will package the cluster of related collaborator objects up.

This composite object hides the complexity of the cluster behind an abstraction that allows us to program at a higher level. This not only improves cohesion, but also reduces coupling since consumers only interact with the new composite object.

Furthermore, the new abstraction enhances domain clarity because it more clearly delimits the scope of the cluster of related objects more clearly, and naming it clarifies the underlying concept it represents. At the same time, it shields its consumers from the interactions between the objects in the packaged cluster to fulfill their responsibility.

2. 2. 1. How do we apply a bundling up?

We introduce a new composite object that bundles up some object’s peers through refactoring. The process would be as follows:

We create an instance of the new composite object in the constructor of the object for which the related cluster of peers played a specific role, and store that instance in a field. We should inject those peers into the new composite object’s through its constructor when creating its instance.
We move the composite behaviour into the new object. We may need to segregate that behaviour first^[6].

After this refactoring, the new composite object is an internal of the object from which it was extracted. Consequently, introducing it does not affect the tests, because they are not coupled to it and already cover its behaviour.

2. 2. 2. Signals that a bundling up is necessary.

There are two ways to notice that a bundling up is necessary:

a. Detecting code smells in production code.

We may detect that the object using the cluster of related collaborating objects code suffers from the divergent change code smell which points to a cohesion problem, the class has too many responsibilities.

In chapter 20, of his Working effectively with legacy code book, Michael Feather explains several heuristics to identify responsibilities in a class. Some of them might prove useful to identify clusters of fields and private methods that are being used together to fulfill a responsibility that is not the main responsibility of the class^[7]. If most of the fields in the cluster are peers, we have found a candidate cluster for applying a bundling up. Notice that those clusters might be hidden by long methods, so we may need to decompose those first.

b. Detecting testability problems.

These testability problems will appear in the tests of the object for which the related collaborators in the cluster act as peers. We’ll notice that the test setup becomes overly complex because we need to simulate too many peers (and possibly supply additional configuration) just to get the object under test into a relevant state. The authors of the GOOS book illustrate this situation when describing the “Bloated Constructor” test smell in chapter 20 of the book, which is devoted to test smells that may indicate design problems^[8].

The tests might be especially painful to maintain, if there’s still some churn^[9] in the interfaces of the peers, or in their interactions to fulfill their composite responsibility because the tests are coupled with them and that churn will affect them.

Take in mind that this signal might take longer to be noticeable than detecting code smells in the production code, but when it appears it points to a stronger need to to bundle up some of the object’s peers.

If we are suffering testability problems, extracting a new internal composite object won’t be enough, we’ll also need to promote the new composite object to be a peer and refactor the tests.

2. 2. 3. Refactoring the tests.

We promote the internal composite object to be a peer of the object that uses it by introducing an interface for the role it plays, then invert the dependency on it, and inject it through the constructor of the object that uses it.

Then we refactor the tests, to simplify them:

We test the new composite object directly.
We use test doubles to simulate the behaviour of the composite in the tests of the code from which it was extracted.

In the case of a bundling up, promoting the internal composite object to be a peer won’t reduce the structure-insensitivity of the tests, as was the case for a breaking out. This happens because a bundling up reduces the overall coupling.

Imagine that we have an object that has 5 peers, 3 of which form a cluster that work together to fulfill some responsibility for the object. If we bundle up the cluster in a new composite object and make it a peer, the object will now have 3 peers (2 original peers that were not part of the cluster + the new composite object) instead of the original 5. This means that when there are testability problems making the new composite object a peer makes sense because it increases the structure-insensitivity of the tests^[10].

Furthermore, the tests using the interface of the composite object directly will be more focused which will improve the overall tests’ readability, writability, specificity and composability.

The tests of the client of the new abstraction will also be more maintainable because the new abstraction shields its consumers from any churn inside it, i. e., changes in the interfaces or interactions between the peers the abstraction is bundling up. This is one of the advantages of information hiding. We benefit even more from this protection while the functionality within the cluster is still actively evolving.

As in the case of breaking out, we prefer to promote the new internal composite object to peer only if we are experiencing testability problems. Otherwise, we keep it as an internal to avoid coupling tests to an abstraction that might prove unnecessary, in case coupling to it ends up providing no benefits.

3. An example.

Some time ago, we were developing an application that processed clicks on ads in different portals and associated them to the campaign they should be charged to using several criteria.

3. 1. Before applying a bundling up.

Early in the development of the application we had a design like the one shown the following diagram:

Initial design with many peers.

The ClickProcessor class had 7 collaborators, of which 6 were peers^[11] (SourcesMapGenerator, DomainLogger, ClickRecording, CampaignsMapping, CampaignsRepository and EuroExchangeService), and 1 was an internal, (MessageComposer), that in turn had two peers (Clock and UniqueIdGenerator).

The 6 peers of ClickProcessor and the 2 peers of MessageComposer matched the dependency role stereotype. They were ports of the application.

This meant that the unit tests of ClickProcessor had to use 8 test doubles to simulate the behaviour of the 8 dependencies.

Since the application was still in flux as we iterated to add new sources of campaigns and ads, the logic in ClickProcessor was evolving rapidly and soon we would need to add new peers to retrieve information from new sources. This churn transmitted to the tests that had to keep up with the changes in logic and peers. The complicated set up of the tests and that churn were causing us a lot of pain.

As their names indicate, two of the peers of ClickProcessor were related to campaigns: CampaignsMapping and CampaignsRepository.

We also observed that most of the churn in ClickProcessor was coming from iterations to evolve the logic to retrieve the campaign to which a given click was assigned. Furthermore, we also knew that this campaign retrieval logic was soon to grow to support new sources for campaigns and ads coming from two recently acquired companies.

There were three peers working together to retrieve the campaign to which an ad was assigned: CampaignsMapping, CampaignsRepository and EuroExchangeService. We decided to bundle up this cluster to shield ourselves from churn in the campaign retrieval logic, reduce coupling and improve test maintainability. Consequently, we extracted a new composite object, CampaignRetrieval which encapsulated the cluster and was responsible for retrieving the campaign.

3. 2. After introducing the new composite type.

The new composite type, CampaignRetrieval, was an internal of ClickProcessor. The resulting design is shown in the following diagram:

Design after introducing the new composite object.

ClickProcessor had 5 collaborators, of which 3 were peers, SourcesMapGenerator, DomainLogger and ClickRecording; and 2 were internals:

MessageComposer which in turn had 2 peers Clock and UniqueIdGenerator; and
CampaignRetrieval which in turn had 3 peers also CampaignsMapping, CampaignsRepository and EuroExchangeService.

This refactoring reduced the overall coupling because ClickProcessor went from having 7 collaborators to having 5. As we explained in a previous section, the coupling reduction is equal to the number of peers bundled in the new composite object minus one, in this case, 3 – 1 = 2.

Since, CampaignRetrieval was still an internal of ClickProcessor, the tests didn’t change after this refactoring.

3. 3. After promoting the new composite type to be a peer.

Finally, we promoted CampaignRetrieval to be a peer and simplified the tests (the details of this refactoring in section 2. 2. 3. Refactoring the tests). The resulting design is shown in the following diagram:

Design after promoting to peer the new composite object.

After this final refactoring, the ClickProcessor class still had 5 collaborators, but now 4 of them were peers (SourcesMapGenerator, DomainLogger, ClickRecording and CampaignRetrieval), and only 1 was an internal, MessageComposer which in turn had 2 peers: Clock and UniqueIdGenerator.

The tests of ClickProcessor became much simpler: they were coupled to 6 peers instead of the 8 before the refactoring and therefore required only 6 test doubles. This reduction in coupling was reflected in the tests, which became more focused and were shielded from the churn in the campaign retrieval logic.

The campaign retrieval logic resided in the class implementing the CampaignRetrieval interface, NotYetUsingDataApiCampaignRetrieval, (a temporary name reflecting that we were still iterating its behavior). Its focused tests were the only ones affected by ongoing changes in the campaign retrieval code.

Reducing the number of peers of ClickProcessor by 2 may not seem much, but shielding its tests from the churn in the campaign retrieval logic made a big difference for us, because it removed the high maintenance burden of having to update them every time a small change happened in the campaign retrieval code.

Eventually the logic to retrieve a campaign grew in complexity until it became a subsystem in its own right, thus having applied a bundling up to that initial cluster of 3 objects proved to be a very successful bet^[12].

CampaignRetrieval subsystem.

This table summarizes the reduction in complexity on this stage of the process.

Stage	ClickProcessor	ClickProcessor test	Complexity
Before bundling up	1 internal (2 peers) + 6 peers, 8 peers in total	8 test doubles	Many peers, high coupling to tests
After introducing composite	1 internal (2 peers) + 1 internal (3 peers) + 3 peers, 8 peers in total	8 test doubles	Better cohesion, same coupling to tests
After promoting composite to peer	1 internal (with 2 peers) + 4 peers, 8 peers in total	6 test doubles	Same cohesion as previous stage, reduced coupling to tests: improved testability

Stages showing a reduction in complexity.

4. Conclusions.

The bundling up technique is a refactoring that manages and reduces complexity by grouping related collaborators into a single composite object. It is an application of the “Composite Simpler Than the Sum of Its Parts” rule of thumb. Rather than merely aggregating objects, the goal of bundling up is to create a higher-level abstraction that makes the design simpler to understand, reason about, and use.

This technique can be applied to both value and object types. In the case of values, bundling up involves detecting and eliminating data clumps by introducing meaningful abstractions that represent them explicitly. For objects, it consists of identifying clusters of collaborators that work together to fulfill a specific responsibility and packaging them inside a new composite object. By doing so, implicit concepts are turned into explicit abstractions with clear boundaries and well-defined responsibilities.

Applying bundling up brings several important design benefits. It improves cohesion by isolating a distinct responsibility within its own abstraction, and it reduces coupling because clients interact with one composite object instead of many individual objects. It also improves domain clarity, since naming the new abstraction helps reveal the underlying concept it represents. At the same time, it strengthens information hiding by shielding consumers from internal interactions and future changes within the packaged cluster of objects.

In the case of object types, there are signals that indicate when bundling up may be necessary. In production code, code smells such as divergent change, long methods, or large classes often point to hidden clusters of related behaviour. In tests, the need for bundling up becomes apparent when setup logic grows complicated requiring many test doubles, or when tests become fragile because they are tightly coupled to a cluster of collaborating objects in churn. These testability problems are strong indicators that an implicit abstraction should be made explicit.

The refactoring process typically involves introducing a new composite object, injecting the relevant peers into it, and moving the related behavior into this new abstraction. Initially, the composite can remain an internal of the original object, leaving existing tests unchanged. If testability problems persist, the composite can then be promoted to an explicit peer, which usually simplifies tests by reducing the number of awkward collaborators they must simulate. Unlike breaking out, bundling up tends to increase the structure-insensitivity of the tests because it reduces coupling.

In summary, bundling up is an effective way to uncover meaningful abstractions, control complexity, and improve maintainability in both code and tests. Even small reductions in coupling can have a significant impact when they shield consumers from volatile parts of the system. As shown in the example, a well-chosen composite may naturally evolve into a subsystem, confirming the value of bundling up as a long-term investment to create a more sustainable design.

Our next post in this series will focus on the budding off technique.

Thanks for reading to the end of this post. We hope the ideas presented here prove useful in your own work.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

Acknowledgements.

I’d like to thank Emmanuel Valverde Ramos, Marabesi Matheus and Fran Reyes for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Cottonbro Studio for the photo.

References.

Notes.

[1] These are the posts mentioned in the introduction:

The class is not the unit in the London school style of TDD in which we commented, among other things, the importance of distinguishing an object’s peers from its internals in order to write maintainable unit tests.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness in which we explained how the peer stereotypes helped us identify an object’s peers.

[2] When we use the term object in this post, we are using the meaning from Growing Object-Oriented Software, Guided by Tests (GOOS) book:

Objects “have an identity, might change state over time, and model computational processes”. They should be distinguished from values which “model unchanging quantities or measurements” (value objects). An object can be an internal or a peer of another object.

[3] We devoted two posts to explain the breaking out technique in depth:

Breaking out to improve cohesion (peer detection techniques), and its continuation,
Refactoring the tests after a “Breaking out” (peer detection techniques).

[4] This mind map comes from a talk which was part of the Mentoring Program in Technical Practices we taught in 2024 in AIDA.

[5] In the Value Types section of chapter 7, Achieving Object-Oriented Design of GOOS, the author explains that they apply a bundling up when they detect an instance of the data clump code smell: “when we notice that a group of values are always used together, we take that as a suggestion that there’s a missing construct”.

They continue detailing how they refactor it: “A first step might be to create a new type with fixed public fields—just giving the group a name highlights the missing concept. Later we can migrate behaviour to the new type, which might eventually allow us to hide its fields behind a clean interface.”

[6] Applying Extract Function/Method and other related refactorings, see chapter 6, A First Set of Refactorings, of Martin Fowler’s Refactoring book.

[7] We think that the following four heuristics to detect responsibilities may be useful to detect clusters collaborating peers and methods: Grouping Methods, Looking at Hidden Methods, Decisions that may change and Internal Relationships.

[8] You can also find posts explaining these test smells in their old blog under the category: Listening to the tests .

[9] In the context of software development, churn refers to frequent changes in the code, interfaces, or design.

Specifically, in this post, we are talking about:

“Churn in the interfaces”: Meaning that the definitions of how different components (peers) communicate are changing often (e.g., method names, parameters, or return types are being modified repeatedly).
“Churn in their interactions”: Referring to frequent changes in how these components collaborate or the sequence of steps they take to achieve a goal.

[10] If a cluster contains n peers of an object that work together, bundling them into a composite object and making it a peer of the original object will reduce the number of peers the object is coupled with by n – 1 (we remove the n peers in the cluster, but add one new peer: the composite object).

[11] You can find several practical heuristics that help you decide whether a collaborator should be considered a peer or an internal in the post: Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.

[12] When I left the application the implementation of CampaignRetrieval already had 5 peers and several internals.

¡"Isolated" test significa algo muy diferente para distintas personas!

2026-01-24T05:30:00+00:00

Este post es una traducción del post original en inglés: “Isolated” test means something very different to different people!.

Introducción.

Un concepto que encontramos muy útil tanto cuando hacemos TDD como cuando introducimos tests en código legacy son las propiedades FIRS (Fast, Isolated, Repeatable, Self-validating), que se utilizan para caracterizar un test unitario ideal. Estas propiedades tienen su origen en el acrónimo FIRST, que caracterizan los tests unitarios ideales en el contexto de TDD, en donde la T significa Timely, (“hecho a tiempo”)^[1].

Esto es lo que queremos decir con tests Fast, Isolated, Repeatable y Self-validating:

Fast: deberían ejecutarse tan rápido que nunca sintamos la necesidad de ejecutarlos más tarde.
Isolated: deberían producir los mismos resultados independientemente del orden en el que se ejecuten. Esto significa que los tests no dependen unos de otros, ni directa ni indirectamente.
Repeatable: deberían ser deterministas; sus resultados no deberían cambiar si el comportamiento que probamos y el entorno no han cambiado.
Self-validating: deberían pasar o fallar automáticamente, sin requerir que un humano intervenga para determinar el resultado. Esta propiedad es esencial para la automatización de tests.

En el contexto de TDD y en el de añadir tests a código legacy, las propiedades FIRS cumplen roles diferentes, en el primer caso nos pueden servir de guía para diseñar unidades testables, mientras que en el segundo nos ayudan a descubrir problemas de testabilidad^[2].

Cuando añadimos tests en un código legacy, las violaciones de las propiedades FIRS resaltan aquellas dependencias que dificultan el testing, conocidas como colaboraciones incómodas (awkward collaborations)^[3]. Estas colaboraciones incómodas serían las dependencias que necesitaríamos romper utilizando técnicas de rotura de dependencias^[4] para poder introducir tests unitarios.

En el caso de los tests de integración bastaría centrarse en las violaciones de las propiedades Isolated, Repeatable y Self-validating. Las dependencias que violan las propiedades Repeatable y Self-validating requieren de la aplicación de técnicas de rotura de dependencias, mientras que las violaciones de la propiedad Isolated a menudo también pueden resolverse usando otros enfoques, como fixtures específicas para tests o cambios de configuración.

En el contexto de TDD, las violaciones de las propiedades FIRS son una heurística clave para identificar aquellas colaboraciones que necesitamos empujar fuera de la unidad bajo test. Estas colaboraciones incómodas las simularemos con dobles de prueba en nuestros tests unitarios.

Cuando hacemos TDD, identificar colaboraciones incómodas es más difícil porque debemos inferirlas a partir de la especificación. En cambio, en el código legacy son más fáciles de identificar porque las vemos en el código y además se manifiestan a través de los problemas de testabilidad que causan.

Identificar colaboraciones incómodas es, por tanto, una habilidad importante para poder diseñar código testable. En este sentido, las propiedades FIRS resultan una valiosa guía para definir los límites de una unidad, y nos ayudan a desarrollar código testable.

¡Parece que “isolated test” significa algo muy diferente para distintas personas!

Si lees la definición original de isolated en Agile in a Flash: F.I.R.S.T. notarás que es diferente de lo que nosotros hemos expresado en la sección anterior.

Para nosotros isolated significa que “un test debería producir los mismos resultados independientemente del orden en el que se ejecute. Esto significa que los tests no dependen unos de otros de ninguna manera, ni directa ni indirectamente”.

En la definición de isolated de Agile in a Flash: F.I.R.S.T., la flash card afirma:

“Isolated: Failure reasons become obvious.” (Isolated: Las razones del fallo se vuelven evidentes)

Más adelante, en la explicación, elaboran lo que esto significa (el énfasis en negrita fue añadido por nosotros):

Isolated: Tests isolate failures. A developer should never have to reverse-engineer tests or the code being tested to know what went wrong. Each test class name and test method name with the text of the assertion should state exactly what is wrong and where. If a test does not isolate failures, it is best to replace that test with smaller, more-specific tests. (Isolated: Los tests aíslan los fallos. Un desarrollador nunca debería tener que hacer ingeniería inversa de los tests o del código que se está probando para saber qué salió mal. El nombre de cada clase de test y de cada método de test, junto con el texto de la aserción, debería indicar exactamente qué está mal y dónde. Si un test no aísla fallos, es mejor reemplazarlo por tests más pequeños y más específicos.)

A good unit test has a laser-tight focus on a single effect or decision in the system under test. And that system under test tends to be a single part of a single method on a single class (hence “unit”). Tests must not have any order-of-run dependency. They should pass or fail the same way in suite or when run individually. Each suite should be re-runnable even if tests are renamed or reordered randomly. Good tests interfere with no other tests in any way. They impose their initial state without aid from other tests. They clean up after themselves.” (Un buen test unitario se centra de forma extremadamente precisa en un único efecto o decisión en el sistema bajo test. Y ese sistema bajo test suele ser una parte única de un único método en una única clase (de ahí “unit”). El resultado de los tests no debe depender del orden de ejecución. Deberían pasar o fallar de la misma manera al ejecutarse en una suite o de forma individual. Cada suite debería poder ejecutarse de nuevo incluso si los tests se renombran o se reordenan aleatoriamente. Unos tests bien hechos no interfieren con otros tests de ninguna manera. Imponen su estado inicial sin la ayuda de otros tests. Limpian su entorno después de ser ejecutados.”)

Tim Ottinger en FIRST: an idea that ran away from home lo resume así:

“Isolated - tests don’t rely upon either other in any way, including indirectly. Each test isolates one failure mode only.” (Isolated - los tests no dependen unos de otros de ninguna manera, ni siquiera indirectamente. Cada test aísla un único modo de fallo.)^[5].

Por contra, para nosotros isolated, en el contexto de identificar colaboraciones incómodas, significa que los tests deberían estar aislados entre sí, lo que, en la práctica, significa que no pueden compartir ningún estado o recurso mutable. Nuestra definición es menos restrictiva que la de Ottinger. Elegimos considerar sólo un aspecto de su definición, que “los tests no interfieren con otros tests de ninguna manera”, y no el otro, “los tests tienen una única razón para fallar” (comentaremos más sobre este otro aspecto más abajo).

Creemos que lo que nosotros entendemos por isolated se alinea con la definición que Kent Beck proporciona en su libro Test Driven Development: By Example. En la sección Isolated Test (página 125) del capítulo Test-Driven Development Patterns, escribe:

“How should the running of tests affect one another? Not at all.” (¿Cómo debería afectar los tests unos a otros al ser ejecutados? Nada en absoluto.)

“[…] the main lesson […] tests should be able to ignore one another completely.” ([…] la lección principal […] los tests deberían poder ignorarse unos a otros completamente.)

“One convenient implication of isolated tests is that the tests are order independent.” (Una implicación conveniente de los tests isolated es que son independientes del orden.)

Además, en su trabajo más reciente Test Desiderata define isolated como:

“tests should return the same results regardless of the order in which they are run”^[6] (los tests deberían dar los mismos resultados independientemente del orden en el que se ejecuten).

Dicho esto, hay otra propiedad deseable para los tests en Test Desiderata que resulta interesante para esta discusión, specificity, que Kent Beck explica como:

“Specific: if a test fails, the cause of the failure should be obvious.” (Specific: si un test falla, la causa del fallo debería ser obvia)

Creemos que el segundo aspecto de isolated que aparece en la definición de Ottinger, tener una única razón para fallar, corresponde al nivel más alto posible de especificidad de Beck. Por tanto, parece que lo que Ottinger entiende por isolated estaría incluyendo dos de las propiedades deseables para los tests de las que Beck habla en Test Desiderata:

la propiedad de devolver los mismos resultados independientemente del orden en el que se ejecuten (ser isolated).
la propiedad de que los fallos de los tests tengan una causa obvia (ser specific).

Tener una única razón para fallar sigue siendo una propiedad altamente deseable que nosotros también tenemos en cuenta al escribir casos de test. Nos puede ayudar tanto a detectar cuando componer comportamientos independientes, como a evitar la sobreespecificación de algunos tests^[7].

Sin embargo, en el contexto de identificar colaboraciones incómodas, hemos encontrado que la definición de isolated de Beck es más útil, para evitar caer en la trampa de considerar que la unidad es la clase, y para enseñar el uso de los dobles de prueba como herramientas de aislamiento, el uso principal en el estilo clásico de TDD.

Resumen.

Mostramos cómo las propiedades FIRS pueden resultar valiosas tanto al hacer TDD como al añadir tests en código legacy, porque nos guían a desarrollar código más testable y mantenible.

Exploramos cómo el concepto de tests isolated difiere según el autor. Mientras que la definición de Kent Beck enfatiza la independencia entre tests, asegurando que estos produzcan resultados consistentes independientemente del orden de ejecución, la definición que encontramos en F.I.R.S.T in Agile in a Flash establece además que los tests deberían tener una única razón para fallar. Creemos que esta última definición mezcla la definición de isolation de Beck con otra propiedad de los tests: specificity, ya que tener una única razón para fallar representa el nivel más alto de specificity.

Pensamos que tanto la definición de isolated de Beck como la de Ottinger son valiosas. Sin embargo, la versión de Beck se alinea más estrechamente con lo que nosotros entendemos por isolated en el contexto de identificar colaboraciones incómodas. Para nosotros, la definición de Beck ha demostrado ser especialmente útil para identificar colaboraciones incómodas, evitar caer en la trampa de considerar que la unidad es la clase, y enseñar cómo usar los dobles de prueba como herramientas de aislamiento.

La serie sobre TDD, dobles de prueba y diseño orientado a objetos.

Este post forma parte de una serie sobre TDD, test doubles y diseño orientado a objetos:

La clase no es la unidad en el estilo de TDD de Londres.
¡”Isolated” test significa algo muy diferente para distintas personas!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness, (aún por traducir).
Breaking out to improve cohesion (peer detection techniques), (aún por traducir).
Refactoring the tests after a “Breaking Out” (peer detection techniques), (aún por traducir).
Bundling up to reduce coupling and complexity (peer detection techniques), (aún por traducir).

Agradecimientos.

Me gustaría agradecer a Fran Reyes, Emmanuel Valverde Ramos, Fran Iglesias Gómez, Marabesi Matheus y Antonio De La Torre por darme feedback sobre varios borradores de este post.

Finalmente, también me gustaría agradecer a imgflip por su Inconceivable Iñigo Montoya Meme Generator.

Referencias.

Notas.

[1] Lean también el post “pure unit test” vs. “FIRSTness” de Jay Bazuzi para aprender más sobre la categorización de tests según su FIRSness (eliminando la T), lo cual puede ser útil al trabajar con código legacy o al hacer tests a posteriori.

[2] Profundizamos en este tema en nuestras formaciones de TDD y Changing Legacy Code.

[3] El artículo Mocks Aren’t Stubs de Fowler es el origen del término colaboración incómoda (awkward collaboration).

[4] Lean nuestro post Classifying dependency-breaking techniques.

[5] Además de resumir muy bien qué significa “Isolated” para ellos, FIRST: an idea that ran away from home profundiza en la historia de cómo surgieron las propiedades FIRST y cómo su significado se ha difuminado con el tiempo. Además, incluye una lista de fuentes que discuten FIRST, destacando los cambios realizados por cada fuente, cómo en el juego del teléfono roto, y señalando que algunas ni siquiera dan crédito a los autores originales.

También hace referencia a otro artículo publicado por Pragmatic Programmers como el origen del acrónimo Unit Tests Are FIRST: Fast, Isolated, Repeatable, Self-Verifying, and Timely, que creemos que explica FAST aún mejor y ademas incluye ejemplos de código.

Finalmente, explica el valor de escribir los tests primero y critica escribirlos después.

[6] Ian Cooper, en su charla TDD, where did it all go wrong, afirma que:

“For Kent Beck, [a unit test] is a test that runs in isolation from other tests.” (Para Kent Beck, [un test unitario] es un test que se ejecuta de forma aislada respecto a otros tests.)

“[…] NOT to be confused with the classical unit test definition of targeting a module.” ([…] NO debe confundirse con la definición clásica de test unitario que apunta a un módulo.)

”A lot of issues with TDD is people misunderstanding isolation as class isolation […]” (Muchos de los problemas al hacer TDD provienen de que la gente malinterpreta el aislamiento como aislar la clase […])

Hablamos de este malentendido frecuente, considerar que la unidad es la clase, en nuestro post La clase no es la unidad en el estilo de TDD de Londres.

[7] Puede que escribamos sobre esto en un post futuro.

A simple example of the temporary field code smell

2025-12-13T05:30:00+00:00

Introduction.

Temporary field is a code smell that occurs when a field is set only at certain times and is null or unused at other times, making the object harder to understand and maintain. This may indicate a deeper design issue.

Often the issue is a missing abstraction with a different lifecycle. Introducing a semantically meaningful class that includes the field can then clarify responsibilities and remove the code smell.

Temporary fields can also appear for other reasons. For example, an algorithm may use fields to store temporary data instead of passing it as parameters, which can be fixed by passing data as parameters. They may also result from using the wrong scope for data, which can be fixed by converting the fields into local variables only used where needed.

In our experience, it can be difficult to find clear examples of this smell online, so we wanted to share one we recently came across^[1].

The example.

The OpeningResult class models the outcome of opening a claim, which can succeed or fail. Depending on the outcome, it notifies a different event through the OpeningListener interface.

OpeningResult contains two temporary fields: _referenceInCompany and _failureDescription.

The _referenceInCompany field is set only when the result is successful and is null when the result is a failure. This field is used exclusively when notifying a success and is never needed when notifying a failure. This makes _referenceInCompany a temporary field. In fact, we think that any nullable field in a domain object should always raise our suspicions.

On the contrary, the _failureDescription field is set only when the result is failure and is null when the result is a success. This field is used exclusively when notifying a failure and is never needed when notifying a success. This makes _failureDescription another temporary field.

The issue here is that OpeningResult is trying to model two concepts at the same time: a successful result and a failed result. This issue leads to the temporary fields, and to need to have code that checks which kind of result, failure or success, we are facing in the IsFailure() method^[2] and conditional code in the Notify method to know what to do in each case.

All this complexity is the result of two missing abstractions, one to represent the notion of succeeding in opening a claim and another to represent the notion of failing.

In the next section we’ll show how introducing them will remove not only the two cases of temporary fields, but also the conditional code in Notify and even the IsFailure() case check.

A refactored version.

To remove the temporary fields we introduced two new classes: SuccessfulOpeningResult and FailingOpeningResult. We did this by applying the Introduce Special Case refactoring twice, one for each special case: the success and the failure.

After the refactoring each concrete class encapsulates its specific data, (_referenceInCompany for success, _failureDescription for failure), which removes the temporary fields that introduced ambiguity and confusion.

The refactored code implements the Special Case pattern. It uses polymorphism, dispatching on the kind of result. This removes the need of checking for nulls to know whether we faced a failure or a success, which is why the IsFailure method and the conditional disappeared^[3].

OpeningResult is now an abstract class on top of a hierarchy that models the two variations of the notification behaviour. We made OpeningResult an abstract class instead of an interface, because we wanted to keep the two factory methods, Success and Failure, so that we keep clients from coupling to any class that derive from OpeningResult. This way the clients will only see the abstraction: OpeningResult.

Summary.

In this post, we showed a simple code example containing two cases of the temporary field code smell which were caused by a modelling problem.

We had a class, OpeningResult that was trying to model two concepts at the same time: success and failure in opening a claim. This flawed modelling required conditional code to select the right behaviour in the Notify method, and led to a case of the null check code smell.

We also showed a refactored version which removed both the temporary fields and the null check code smells. We got to that version by applying twice the Introduce Special Case refactoring. The final design has a clearer intent and simpler logic which makes it easier to maintain.

We hope that having more examples of the temporary field code smell may help you to identify and prevent it in your code.

Acknowledgements.

I’d like to thank Fran Reyes for giving me feedback about a draft of this post.

I’d also like to thank Carlos Miguel Seco for giving us the opportunity to work with him on a very interesting project.

Finally, I’d also like to thank Samer Daboul for the photo.

References.

Refactoring: Improving the Design of Existing Code, 2nd Edition, Martin Fowler.
Refactoring Workbook, William C. Wake.
On code smells catalogues and taxonomies, Manuel Rivero.
Patterns of Enterprise Application Architecture, Martin Fowler.
Special Case pattern, Martin Fowler.
Tell, don’t ask, Martin Fowler.
Map, don’t ask, Damian Płaza
Java by Comparison, Simon Harrer, Jörg Lenhard and Linus Dietz.
Option type. Wikipedia.

Notes.

[1] You can find a more complex example in one of our past posts: Using code smells to refactor to more OO code (an example with temporary field, solution sprawl and feature envy).

[2] This method contains an example of the null check code smell described by Bill Wake in Refactoring Workbook.

[3] Using an Option type would also be ok only if we use it functionally, “mapping” over it. If, instead, we add some conditional code in which we ask the option type whether we faced a failure or a success, this conditional check would be an example of the special case code smell described by Bill Wake in Refactoring Workbook. You can read more about using option types functionally in this great post Map, don’t ask, or in the section Use Optionals as Streams of the chapter Let your data flow of the book Java by Comparison.

Both the Special Case pattern , (applying Tell, don’t ask), or using the option type functionally (applying Map, don’t ask) avoid the smelly conditionals.

We think that, in this case, using the Special Case pattern is clearer, although the solution is arguably less general than using an option type functionally.

Parallel change example: simplifying some test builders

2025-11-30T05:30:00+00:00

1. Introduction.

In this post we’ll revisit the design of a test builder using the Curiously recurring template pattern (CRT), that we showed in a previous post: Segregating a test builder applying the curiously recurring template pattern, and discuss how we simplified it using composition after gaining some insights about the domain of our application.

We’ll also describe how we applied a parallel change to incrementally refactor from the design using generics to the new design using composition without breaking the tests in any moment^[1].

2. The initial design.

We applied the CRT pattern to design three test builders that shared most of their setters. The design enabled chaining setter methods in any order while restricting available methods to only those relevant for building each specific claim type.

This is the code of the base test builder using generics and the CRT pattern, Claimbuilder:

And these are the three concrete derived test builders

ClaimDataBuilder:

ReadyToOpenClaimBuilder:

OpenButNotNotifiedClaimBuilder:

This design solved the problems we faced because it enabled chaining setter methods in any order while restricting available methods to only those relevant for building each specific claim type.

3. Domain insights set our minds free.

We had two implementations of Claim: ReadyToOpenClaim y OpenButNotNotifiedClaim, that were modelling the two different states of a claim in our process, and a Data Transfer Object (DTO), ClaimData. They shared most of their data and that’s why we were trying to build them using common code. Still, something was off 🤔.

Later, we learned that we were not modelling our domain usefully. Thinking about the behaviour of our application we realized that ReadyToOpenClaim and OpenButNotNotifiedClaim were not actually representing possible states of a Claim. Instead, they represented steps in the workflow of making a claim. We had conflated concepts.

To encode this learning, we started by renaming the Claim interface and its two implementations, ReadyToOpenClaim and OpenButNotNotifiedClaim, to ClaimCommand, OpenClaimCommand and NotifyOpenedClaimCommand, respectively. Then we renamed ClaimData to Claim since that name was not taken anymore.

Then, it was easier to see that it made no sense to use inheritance in the test data builders. The design using the CRT pattern was solving the symptoms caused by having conflated the concepts of the claim state and the steps in a claim opening workflow, but not the actual problem. This realization led us to separate those concepts which then enabled a simpler design option for the test builders: composition.

4. Applying parallel change to move from inheritance to composition.

We applied parallel change to incrementally introduce the new composition-based design through refactoring without making the tests fail at any moment.

We divided this introduction of the new design in two steps:

Introducing new composition based test builders and removing the inheritance, generic based ones for OpenClaimCommand and NotifyOpenedClaimCommand.
Introducing a new test builder forClaim that does not derive from ClaimBuilder.

Let’s comment each step in more detail:

4. 1. Introducing new composition based test builders and removing the inheritance, generic based ones for `OpenClaimCommand` and `NotifyOpenedClaimCommand`.

We’ll apply two parallel changes, one for each of the new composition based test builders.

4. 1. 1. Parallel change to introduce the new `OpenClaimCommand` test builder.

4. 1. 1. 1. Expansion.

We generated a builder for OpenClaimCommand using AI, renamed its setters to our liking, and used builder composition to improve readability^[2] (check the of method in the code below). This is the resulting builder:

4. 1. 1. 2. Migration.

We changed the places where the old ReadyToOpenClaimBuilder was used to use OpenCommandBuilder instead.

As an example, this is a fragment of a test case before being migrated:

and after being migrated:

4. 1. 1. 3. Contraction.

Finally, we removed the imports of ReadyForOpeningBuilder, and deleted the class.

4. 1. 2. Parallel change to introduce the new `NotifyOpenedClaimCommand` test builder.

4. 1. 2. 1. Expansion.

We generated a builder for NotifyOpenedClaimCommand using AI, renamed its setters to our liking, and used builder composition to improve readability. This is the resulting builder:

4. 1. 2. 2. Migration.

We changed the places where the old OpenButNotNotifiedClaimBuilder was used to useNotifyOpenedClaimCommandBuilder instead.

As an example, this is a fragment of a test case before being migrated:

and after being migrated:

4. 1. 2. 3. Contraction.

Finally, we removed the imports of OpenButNotNotifiedClaimBuilder, and deleted the class.

4. 2. Introducing a new test builder for`Claim` that does not derive from `ClaimBuilder`.

4. 2. 1. Expansion.

We started by creating a new test builder for Claim called ClaimBuilderX that did not derive from ClaimBuilder but had the same setter methods:

Then, we overloaded the of method of the OpenClaimCommandBuilder. The new version of the of method received a ClaimBuilderX. We did the same for the of method of the NotifyOpenedClaimCommandBuilder.

We also modified the build method of both classes, so that, if the field claimBuilderX was not null, we used ClaimBuilderX to create the Claim, whereas if it was, we used the old test data builder, ClaimDataBuilder. This conditional code was a scaffolding that allowed us to incrementally migrate from the old design to the new design.

This is the resulting OpenClaimCommandBuilder with some code omitted for the sake of brevity:

and this is the resulting NotifyOpenedClaimCommandBuilder with some code omitted for the sake of brevity:

The last part of the expansion was importing statically the aClaim method of ClaimDataBuilderX in all the tests in which the aClaimDto method of ClaimDataBuilder is used. I did it with a script that I had vibe coded with Junie.

4. 2. 2. Migration.

After all the scaffolding we prepared in the expansion phase, the migration consisted only in substituting the text “aClaimDto” with “aClaim” in every test case in which the aClaimDto method of ClaimDataBuilder was being used.

Replacing text in files.

After executing this text substitution all the tests kept passing.

4. 2. 3. Contraction.

First, we removed the static imports of the unused aClaimDto method of ClaimDataBuilder using IntelliJ’s Optimize imports command on all the tests.

After that, the ClaimDataBuilder class was being used only in the scaffolding we added in the OpenClaimCommandBuilder and NotifyOpenedClaimCommandBuilder during the expansion phase to make the migration possible.

We removed the methods that the IDE marked as unused and ran the Optimize imports command in both tests. After that, ClaimDataBuilder became dead code and we deleted it.

Since ClaimDataBuilder was the only remaining class inheriting from the generic ClaimBuilder class using generics, after deleting it ClaimBuilder also became dead code, and we could delete it as well.

Finally, we renamed ClaimBuilderX to ClaimBuilder since that name was not taken anymore.

5. Final design.

The new design of the test builders using composition is easier to understand and maintain than the previous one using the CRT pattern because the new design does not use generics nor inheritance.

6. Summary.

After realizing that we were conflating concepts: ReadyToOpenClaim and OpenButNotNotifiedClaim were not states of a claim but steps in a workflow, we clarified the domain model renaming them to OpenClaimCommand and NotifyOpenedClaimCommand, respectively, and also renaming ClaimData to Claim.

This domain insight also removed the need for inheritance in the test builders using the CRT pattern, and opened the door to a simpler design: composition-based test builders, that better matched the domain.

We applied a parallel change to safely move from one design to the other without ever breaking the test suite. In the expansion phase we generated new builders and introduced temporary scaffolding, then, in the migration phase, we gradually migrated the test builders usage in the tests, and only once everything was migrated, we finally performed a controlled cleanup of the old classes.

The final design avoids generics and inheritance entirely, relying instead on straightforward composition. Each command builder now composes a ClaimBuilder, leading to a clearer, flatter structure. This makes the builders easier to understand, modify, and extend while better reflecting the clarified domain model.

We encourage you to learn more about parallel change so you too can join The Limited Red Society and practice safer, incremental refactoring^[3].

Acknowledgements.

I’d like to thank my colleague Fran Reyes for giving me feedback about this post.

I’d also like to thank Carlos Miguel Seco for giving us the opportunity to work with him on a very interesting project.

Finally, I’d also like to thank cottonbro studio for the photo.

Notes.

[1] See the fantastic The Limited Red Society talk to know more about the origins of this technique.

[2] Read Nat Pryce’s short post about composing test data builders: Tricks with Test Data Builders: Combining Builders.

[3] Our training Code Smells & Refactoring makes a special emphasis on teaching and practising the parallel change technique so teams can refactor safely and incrementally without breaking their codebase.

Refactoring the tests after a "Breaking Out" (peer detection techniques)

2025-11-10T05:30:00+00:00

1. Introduction.

This post is a continuation of our previous post devoted to the breaking out technique, in which we explained the breaking out technique which consists in splitting a large object into a group of collaborating objects and/or values.

This technique is useful to fix cohesion problems caused by delaying design decisions until we learn more about the domain when facing volatile and poorly understood domains.

We also described how to use code smells and, in more severe cases, testability problems as indicators of poor cohesion to recognize when we need the technique, and how to apply it.

Finally, we highlighted two facts about the code after applying a breaking out:

The new objects created through this refactoring are treated as internals rather than peers.
The tests still have poor readability, writability, specificity and composability, but high structure-insensitivity.

At the end of the previous post, there were to open questions that we’ll try to answer in this post:

Should we refactor the tests now or later?
How do we refactor the tests?
How do we decide if we should promote an internal object to be a peer?

2. Refactoring the tests now or later?

2. 1. Context.

The following figure summarizes the analysis of some test properties of the original tests we did in our previous post:

Original tests properties.

This analysis of test properties will help us identify the trade-offs involved in deciding whether to refactor the tests now or defer it to a more advantageous time.

Another information we need to consider to make the decision is how we got to this situation. Let’s do a quick recap:

We were starting a new area of code, and test-drove the behaviour through the public interface of an object without attempting to impose much structure, in order to have more time to learn before committing to any design decision.
After observing some code smells (and possibly some test smells) produced by a lack of cohesion, we decided to break up the original object into smaller components. After that refactoring, the resulting composite object (original object + extracted internals and values) has better cohesion, but the original tests have not changed.

We also need to know that the refactoring of the test comprises two steps:

Testing “problematic” internals and values independently, (where “problematic” means that they cause painful testability problems).
Refactoring the original tests.

Let’s analyze the first step.

2. 2. Testing “problematic” types independently now or later?

2. 2. 1. Consequences of testing “problematic” types independently.

Let’s start by thinking what testing an internal object or value independently means in terms of readability, writability, specificity, composability and structure-insensitivity.

Improvements in readability and writability.

The new tests would be more granular and focused because they are testing only one behaviour. This will make them easier to write and understand.

Improvement in specificity.

With these new tests, it would be much easier to interpret test failures (including failures in the original tests).

Improvement in composability.

We can separately test each different behaviour (dimension of variability) through its interface. Then adding a few test cases that verify the combination of behaviours will allow the number of test cases to grow additively instead of multiplicatively, while still providing confidence that the tests are sufficient.

Reduced structure-insensitivity.

The new tests are coupled to the interfaces of the new types. Since the original tests were not aware of these interfaces, this added coupling increases the cost of any refactoring that changes one of the new interfaces.

Test properties when testing “problematic” internals and values independently.

Therefore, independently testing internals or values through their interfaces can ease most of the testability problems of the original tests. However, this comes at the cost of tighter coupling between the tests and the production code.

2. 2. 2. Trade-off and contexts.

There’s a trade-off between structure-insensitivity, and other desirable test properties like specificity, composability, readability and writability. There’s no ideal general solution, so we’ll have to “pick our poison” depending on the context.

In a context in which we don’t have enough knowledge yet about the problem to delimit the object’s boundaries well, it’s likely that we’ll do a lot of refactoring as we learn more about the domain. Some of those refactorings may involve refining the interfaces of the new types we introduced by applying the breaking out.

In a context marked by volatility and limited knowledge, it’s preferable to maintain a high degree of structure-insensitivity to avoid increasing the cost of refactoring while preserving other desirable test properties, ensuring that applying new learnings remains inexpensive. That is precisely why we decided not to impose much structure when we started test-driving the behaviour through the entry point.

If after the breaking out, we are still in the same context of volatility and lack of knowledge, it might be wise to defer independently testing the extracted types independently and continue relying on the original tests for a while. In this kind of context, testing them independently might be dangerous because it prematurely couples the tests to interfaces that we may later realize were not sound, leading to more expensive refactorings to refine those internal interfaces.^[1]. Keeping the original tests with low specificity, composability, readability and writability will eventually slow us down and produce maintainability problems, but for a while, having a high structure-insensitivity might pay off by allowing cheaper refactoring of internal interfaces.

This trade-off pays off well until it doesn’t 🙂. This happens when the pain of poor specificity, readability, composability and/or writability starts weighing more than the benefits of cheap refactoring due to high structure-insensitivity. This tipping point may happen due to different reasons, for instance:

1. More knowledge and low volatility.

We have learned enough about the problem so that the code is more stable and has some degree of structure. Interfaces and abstractions are more stable, and their refactoring becomes less likely.

2. Too much testability pain.

The behaviour of some internals becomes so complex that it exacerbates the testability problems so much that they weigh more than the benefits of cheap refactoring of interfaces.

2. 2. 3. Consequences of deferring testing “problematic” types independently.

Poor readability and writability.

We might somehow palliate the pain by using explanatory helper methods and test patterns such as test data builder, object mother, etc. Keep in mind that these techniques only alleviate the symptoms; they don’t address the root of the problem. Even so, they are very useful for reducing the pain caused by poor readability and writability during the period in which higher structure-insensitivity is advantageous for us.

Poor specificity.

If this problem starts being especially painful, we may need to start testing independently some problematic internal or value. I think there’s no other technique to reduce this kind of pain. Although, we might get lucky and not get regressions that are difficult to interpret.

Poor composability.

This problem may even make it impossible to defer independently testing a new type that is causing it. As we said before when talking about behavioural composition, we won’t be able to test-drive complex behaviours without breaking them into smaller behaviours. In such cases, we would have no other choice but to start test-driving independently the “problematic” internal or value in order to reduce the size of the increments of behaviour we are tackling. We’ll see that this may or may not involve using test doubles.

2. 2. 4. Conclusions.

To summarize, keep in mind that the strategy of deferring testing the new types independently is beneficial only in a context where we don’t have enough knowledge of the problem because it avoids committing prematurely to any design decision and makes it cheaper to refine the design as we learn.

Having said that, using this strategy in a different context can be dangerous. The more we defer refactoring the tests, the more expensive it will become and the more pain we’ll suffer test-driving new features (accruing and recurring interests of technical debt at play). So don’t wait too long to refactor the tests.

There might be contexts in which we have a more stable design, and/or enough knowledge of the domain. In these contexts, even the initial strategy of test-driving without imposing much structure might make little sense because we have better odds that the design we impose proves successful^[2]. We’ll discuss this deeper when we talk about the budding off technique in a future post.

2. 3. Why should we only test “problematic” types independently, and not all types?

We have shown how independently testing the new types produced by a breaking out through their interfaces can ease most of the testability problems of the original tests. However, these gains come at a price: we lose structure-insensitivity because the tests get coupled to the interfaces of the new types.

This trade-off is the reason why we should independently test only the “problematic” types, i.e., the ones that produce painful testability problems. This is a sensible limitation. If we tested independently any internal or value that is not problematic, we’d be trading structure-insensitivity for nothing. This mistake would create unnecessary coupling between our tests and the structure of our code, and we’d be much worse off. The only reason we test any of them independently is to ease testability problems that are becoming too painful^[3].

3. Refactoring the tests.

As we said, this is done in two steps:

Testing “problematic” internals and values independently.
Refactoring the original tests.

Let’s go deeper into each step.

3. 1. Testing “problematic” internals and values independently.

We independently test any internal value that is causing painful testability problems. We don’t need to test all of them at once, instead we can do it incrementally as needed. As we saw, these new tests will ease most of the testability problems of the original tests. Once we have them in place, we can simplify the original composite object’s tests to make them easier to maintain.

3. 2. Refactoring the original tests.

Remember that, after applying a breaking out to improve cohesion, all the extracted collaborator objects are treated as internals. Promoting^[4] any of those internals to be a peer is a separate, explicit decision we have to take. This means that there are two options to refactor the original composite object’s tests, each with its own advantages and disadvantages:

Not promoting any “problematic” internal to be a peer.
Promoting “problematic” internals to be peers.

3. 2. 1. Not promoting any “problematic” internal to be a peer.

3. 2. 1. 1. How to do it?

If we take this option, what we can do to simplify the original composite object’s tests would be to remove most of the test cases addressing behaviours that are now being independently tested through closer, more appropriate interfaces. We are taking advantage of the improvement in composability that the tests through more appropriate interfaces provide.

Let’s see how doing this improves different testability problems.

3. 2. 1. 2. Consequences.

Writability and readability problems.

The size of the composite object’s tests is reduced, which makes them less unfocused 🚀. In a way, the pain caused by poor writability and readability is still there, but we don’t feel it so much because there are fewer test cases through the interface of the composite object.

Specificity problems.

These problems were already addressed by testing problematic types independently. We’ll still find tests that are checking the same behaviour from different interfaces, only that there are fewer because we have deleted some composite object’s tests. This overlap still causes that a regression can make several tests fail, however, it’s easier to diagnose the origin of the failures: if some composite object’s test cases and some more focused test cases fail, the problem is likely located in an internal or a value, whereas, if only the composite object’s tests fail, the problem is likely located in the composite object.

Composability problems.

Choosing not to promote any internal to be a peer when simplifying the composite object’s tests does not improve composability any further than what testing a problematic internal independently does. However, it forces a way of doing TDD when faced with hard composability problems: when we are not able to test-drive an object because we can’t find a way to decompose its behaviour in small increments, we go one level of abstraction down, test-drive an internal type with a smaller behaviour, and then use that inner behaviour as a stepping stone to test-drive the original behaviour more easily (this is what we would do in the classical style of TDD). Working this way is inside-out in nature, and, as such, is less YAGNI friendly than test-driving outside-in. To palliate this problem, we should be careful to only test-drive the internal behaviour that we need to make test-driving the whole behaviour possible, and no more.

3. 2. 1. 3. Some observations.

Finally, we’d like to add two observations:

Choosing not to promote any internal to be a peer when simplifying the composite object’s tests does not lower any further the structure-insensitivity. The loss of structure-insensitivity was already caused by independently testing problematic internals through their interfaces.
If specificity and/or composability problems are very painful, we may be better off promoting the internals causing the pain to be peers. However, if those problems aren’t so painful and we are still worried about structure-insensitivity, not doing it might be tolerable, because, as we’ll see in the next session, promoting them introduces a little more coupling.

3. 2. 2. Promoting some “problematic” internals to be peers.

3. 2. 2. 1. How to do it?

Let’s start by discussing what it takes to promote an internal to be a peer of the composite object:

Invert the dependency. This may involve refining the interface of the internal and, in the case of statically typed languages, extracting an interface.^[5].
Simulate the peer’s behaviour with test doubles in the composite object’s tests.
Inject the peer (previously an internal) into the composite object.

3. 2. 2. 2. When should we do it?

In our opinion, we should promote any internal that clearly matches a peer stereotype^[6]. They were already dependencies, strategies or notifications from the outset, but we decided to include their behaviour in the scope of our original tests because we weren’t sure about their interfaces. Now that we have learned more, promoting them to peers will greatly improve testability.

In the case of internals that don’t clearly match any peer stereotype, we should promote them to peers only if being a peer provides substantial testability benefits. In this case, we would be treating an actual internal into a peer, which means coupling to an internal detail, so we better be gaining significant improvements in readability, writability, specificity or composability to compensate for the loss in structure-insensitivity. The rich and complex behaviour of these internals is what leads to substantial testability benefits when they are promoted to peers, even though they don’t correspond to any of the object peer stereotypes. We argue that they belong to what Fowler calls “objects with interesting behaviour”^[7].

3. 2. 2. 3. Consequences.

Let’s see how choosing this option affects the test properties we have been discussing throughout the post:

Writability and readability.

On one hand, tests of the composite object that use test doubles verify only the composite’s own behavior, making them shorter and more focused. They also document the communication protocols between the composite object and its peers^[8].

On the other hand, the more focused tests written through the interfaces of the peers will check only their behaviour and document how they fulfill their roles (contracts).

Specificity.

It is much better with this option. Now, a failure can affect only either the composite object’s tests or a peer’s tests, so it’s straightforward to know where the problem is.

Composability.

It is addressed by simulating the behaviour of the peers (their roles) with test doubles while test-driving the behaviour of the composite object. Afterwards, we test-drive the implementation of the roles to verify that they behave according to their roles.

In the tests of the composite object we describe what we expect of the peer, the contract (or role) between the composite object and its peer, whereas in the tests of the peer we verify that it indeed fulfills that contract.

This is more outside-in and more YAGNI friendly than the approach required in the previous option.

Structure-insensitivity.

Now, both the tests of the peer and the composite object are coupled to the peer’s interface. The tests as a whole see the same set of interfaces as in the previous option, but the number of tests coupled to the peer’s interface increases. Therefore, this option increases the coupling between the tests and the production code. This higher degree of coupling might be attenuated using fakes or using hand-made spies and stubs, but we think this may introduce other maintainability problems on its own^[9].

4. Conclusions.

In this post, we addressed the questions we raised in our previous post devoted to the breaking out technique:

Question 1: Should we refactor the tests now or later?

After Applying a Breaking Out refactoring, the original tests still have poor readability, writability, specificity, and composability. Despite these disadvantages, such tests have high structure-insensitivity, meaning they are resilient to internal refactorings. We discussed the trade-off between keeping this structure-insensitivity and improving other properties. Testing the new internal types independently can ease many testability issues, but it also couples the tests to specific interfaces, making their refactoring more costly.

From that trade-off, we derived a key insight: the decision to refactor tests immediately or defer it depends on context. In volatile or poorly understood domains, deferring independent testing of the new types preserves flexibility and reduces refactoring costs, even if it temporarily worsens test quality. As our understanding of the domain grows and the design stabilizes or the testability pains grow, it becomes beneficial to refactor the tests.

Question 2: How do we refactor the tests?

This refactoring is done in two steps: first, we test “problematic” types independently, and then we simplify the original tests. Testing “problematic” types independently improves the readability, writability, specificity, and composability of the tests, though at the cost of greater coupling with the production code. Therefore, we should only test independently those internals or values that cause clear testability pain, thus avoiding introducing coupling for little benefit.

There are two ways to simplify the original composite object’s tests, depending on whether we decide to promote some problematic internals to peers or not. If we decide not to do it, we simplify the composite object’s tests by deleting some test cases; if we decide to do it, we simplify them by introducing test doubles. The first option doesn’t add much improvement over testing “problematic” types independently, but still reduces the degree of pain by having fewer test cases. Promoting “problematic” internals to peers enhances the desirable properties of tests even more, but introduces greater coupling, since the composite object’s tests also become coupled to the new interfaces.

Question 3: How do we decide if we should promote an internal object to be a peer?

We argued that all internals that match peer stereotypes should be promoted to peers to gain testability benefits. Seeing the decision of promoting an internal to a peer as a bet, promoting one that clearly matches a peer stereotype is a bet with good odds. In contrast, promoting a “problematic” internal that doesn’t match any peer stereotype has worse odds, so, to avoid increasing coupling for little or no gain, we need to be very confident that its promotion will provide clear testability benefits before doing it. We discussed what to assess to make a better decision. We also noted that evaluating these odds depends on both experience and the stability of the design.

Final words.

In summary, the key takeaway is that we have many options, and by identifying the trade-offs between different testability properties, we can judge them according to context and the maturity of the design. Balancing cohesion, testability, and flexibility is not a one-time decision but an evolving process.

Thanks for coming to the end of this post. We hope that what we explain here will be useful to you.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

5. Acknowledgements.

Finally, I’d also like to thank Ali Soheil for the photo.

6. References.

7. Notes.

[1] An extreme case of poor structure-insensitivity happens when we fall in the dangerous class-as-unit trap. Never go there, it’s a scenario full of pain.

Read The class is not the unit in the London school style of TDD, if you are using the London school style of TDD (or mockist TDD).

[2] Design decisions are always a bet against the future evolution of a system.

When we are assessing the quality of a decision, it’s important that we don’t take into account its result, which is a very common cognitive bias called “fielding outcomes” that impairs our learning loops.

So, we should assess a decision thinking if it had good odds to be successful given what we knew at the moment we took it, independently of its result.

You can read more about improving decision making in an uncertain world in Anne Duke’s wonderful Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts book.

This interview, Thinking in Bets for Engineers, is very interesting as well.

[3] We consider that thinking about testability benefits to decide whether to independently test new types introduced through refactoring or not is useful in the context of a breaking out. There could be other valid reasons to write those new tests. You can read the following two posts to go deeper into this topic:

Additional Testing After Refactoring, Kent Beck
Revise Tests While Refactoring? It Depends, Bill Wake
The Impact of Refactoring on Tests, Bill Wake

[4] “Promoting” is a refactoring that makes the role of an internal of an object seen by the rest of the system and the object’s tests. This means that it is treated as a peer of the object. The inverse refactoring of promoting is materializing which “demotes” a peer of an object to be an internal.

[5] We’d like to note some things about this:

- In statically typed languages.

We need to extract an interface because we have two implementations: one in the test context and another one in the production context. We shouldn’t simulate a concrete class with test doubles, even if the tool we use allows it. Simulating a concrete class leaves the relationship between the objects implicit. Read Test Smell: Mocking concrete classes for more details.

The meaning of “extracting an interface” depends on whether the language has an interface construct or not: for instance, we would extract an interface in Java or C#, but extract a class whose methods are all pure virtual functions in C++ (at least in the version I used to use).

- In dynamically typed languages.

We don’t need to extract an interface to invert the dependency.

In both cases we should work to avoid the peer’s API from leaking any implementation detail.

[6] For the GOOS authors the communication patterns between objects are more important than the class structure, (see section Communication over Classification in chapter 7: Achieving Object-Oriented Design).

[7] We commented how using test doubles in an object’s tests to simulate a collaborator that clearly matches a peer stereotype provides substantial testability benefits in our previous post Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.

If the behaviour of the object is very simple (cyclomatic complexity = 1), we may get by with a broad integration test.

[8] It appears in the section Classical and Mockist Testing of his post Mocks Aren’t Stubs:

“[…] always use a mock for any object with interesting behavior”.

[9] We plan to treat this topic in a future post.

Breaking out to improve cohesion (peer detection techniques)

2025-11-10T05:30:00+00:00

1. Introduction.

In previous posts^[1] we talked about the importance of distinguishing an object’s peers from its internals in order to write maintainable unit tests, and how the peer-stereotypes help us detect an object’s peers.

When we use the term object in this post, we are using the meaning from Growing Object-Oriented Software, Guided by Tests (GOOS) book:

Objects “have an identity, might change state over time, and model computational processes”. They should be distinguished from values which “model unchanging quantities or measurements” (value objects). An object can be an internal or a peer of another object.

This post presents three effective techniques for discovering values and object types, breaking out, budding off and bundling up; and then, goes deep into one of them: breaking out. We’ll cover the other two techniques in future posts.

2. Techniques to detect object and value types.

The GOOS book describes three techniques for discovering object types^[2], some of which might be peers:

Breaking out.
Bundling up.
Budding off.

These techniques identify recurring scenarios that indicate when introducing a new object improves a design.

We rely on both our ability to detect code smells, and on “listening to our tests” (using testability feedback to guide our design) to know when to apply a breaking out. The new object types are introduced through refactoring.

In the case of bundling up, we rely on “listening to our tests” to detect the need to apply it. Again the new object types are introduced through refactoring.

In contrast, we detect the need of applying a budding off by recognizing possible cohesion problems while writing a new failing test to drive new behaviour. In this technique we introduce the new object type from the test to prevent cohesion problems. Domain knowledge and previous experience are crucial to apply this technique well.

How we detect the need and the mechanism used to apply each of the techniques^[3].

GOOS also describes three techniques for discovering value types that share the same names: breaking out, bundling up, and budding off. The mechanisms to introduce new values are similar to the ones described above for object types.

For values, bundling up is used to eliminate existing data clumps through refactoring, whereas budding off introduces new values from the outset to prevent primitive obsession or data clumps. Breaking out introduces new values by refactoring to improve cohesion.

In this post we focus on the breaking out technique.

3. Breaking out.

According to the GOOS authors, this technique consists in splitting a large object into a group of collaborating objects and/or values^[4]. Let’s first describe the context in which we apply it.

3. 1. Context.

When starting a new area of code about which we don’t know much yet, we might temporarily suspend our design judgment for a while. We’d just test-drive the behaviour through the public interface of an object without imposing much structure. Doing this allows us time to learn more about the problem and its boundaries before committing to a given structure. We can see this decision as taking a deliberate, prudent technical debt^[5].

There are different approaches to get this “room” for learning, such as (from more to less structure-imposing):

We might prefer to consider as peers only those behaviours that we can clearly match with a peer stereotype, (dependencies, notifications or adjustments).
We might consider as peers only the dependencies which are required to be able to write unit tests (FIRS violations). This approach would result in test boundaries similar to the ones that the classic style of TDD produces^[6].
We might even decide to test-drive the behaviour using only integration tests^[7]. In this “extreme” approach, we might end with no peers at all, although we’ll likely need to at least isolate the tests from dependencies that violate the Repeatable and Self-validating properties form FIRS^[8].

3. 2. Signals that a breaking out is necessary.

After a short while, the object we are test-driving will become too complex to understand because of its poor cohesion^[9]. We’ll likely observe code smells like Divergent Change, Large Class, Data Clump, Primitive Obsession, or Feature Envy, etc.

This lack of cohesion may also manifest as testability problems (test smells). The tests are verifying many behaviours at the same time, which means they have a big scope and a lack of focus. This can lead to difficulties in testing the object’s behaviour^[10], or to test failures that become difficult to interpret. We’ll analyze these testability problems in more detail later.

Note that the impact of poor cohesion on testability may take longer to appear as test smells than as code smells in production code. Therefore, we should monitor the emergence of code smells, as they often serve as earlier indicators that a breaking out may be needed.

Once we detect a breaking out is needed, we should not wait long to apply it because the longer we defer it, the more friction we’ll face when adding new features and the more expensive applying the breaking out will become^[11]. These effects correspond to the recurring and accruing interests of technical debt, respectively. GOOS authors express their concern that if we defer this cleanup due to time pressure, we may have to assume it in a moment where we “could least afford it”. This may make us feel forced to defer the refactoring even more, making the tech-debt snowball even bigger.

3. 3. Applying a breaking out.

We apply it by splitting a large object into smaller collaborating objects and values that each follow the Single Responsibility Principle ^[12]. This refactoring improves overall cohesion by producing a composite object made up of the original object and the extracted objects and values that it now coordinates. After the breaking out, the original object serves as a façade for the extracted new types and, as the entry point to the composite object, it remains the only object visible to the tests and the rest of the system.

Before and after applying a breaking out.

3. 3. 1. What kind of objects were extracted?

Values are not objects by definition, so we don’t need to consider them. This focus the discussion on the object types introduced by the breaking out.

After a breaking out, only the original object is visible to the tests and the rest of the system. The new object types are only “seen” by the original object that owns them. Furthermore, we could inline them back into private methods of the original object without affecting the tests or any of its other clients. This means they are an internal detail of the original object, therefore, they are being treated as internals, not peers of the original object.

Some of those object types will remain as internals, whereas others may be “promoted” to peers. We explain the reasons that make us decide to promote an internal object to be a peer in our next post about breaking out.

3. 4. What about the tests?

After removing the cohesion problems from the production code, what should we do with the tests? They are still testing the behaviours of the original object and its collaborating objects and values through the interface of the original object. This means they are unfocused and likely large.

The newly extracted internal objects and values provide interfaces that let us test their behaviours independently. We could add more fine-grained and focused tests for them using those interfaces, but should we?

Not necessarily. We should only do it if it’s worth the effort. We may decide to defer testing the new types independently until it brings a clear benefit, or even decide not to test some of them if that doesn’t cause testability problems that are too painful.

Before deciding, we should take a closer look at the current tests. Let’s examine any testability problems we may find in them and see how they relate to the desirable test properties Kent Beck describes in his test desiderata.

We will specifically examine the following properties: readability, writability, specificity, composability and structure-insensitivity ^[13].

3. 4. 1. Disadvantages.

Poor readability and writability.

The size and lack of focus of the composite object’s tests in themselves can make them harder to understand, which causes poor readability.

In addition, the inputs and outputs we use in some of those tests might be very different from the ones used by some internal behaviour we’re trying to validate. This happens because the more distance from the entry point to the interface of the internal behaviour, the more likely it is that both input and output have been transformed by an intermediate behaviour. This difference in the inputs and outputs at both interfaces might make the test harder to understand, meaning an even poorer readability, and costlier to write (they take more effort), introducing writability problems.

Poor specificity.

Another test smell we usually find in unfocused tests are test failures that become difficult to interpret. This means they may also have poor specificity.

Poor composability.

When we compose two behaviours, and each behaviour can vary in multiple ways (e.g., different inputs, configurations, or states), the number of required test cases to exhaustively test all combinations is equal to the cardinality of the Cartesian product of their variations. As we compose more behaviors (or parameters), the total number of possible test cases grows multiplicatively, leading to a combinatorial explosion of test cases.

Composability is useful for avoiding this phenomenon. By composing different dimensions of variability that result from separating concerns, we can test each dimension separately and then have only a few tests that verify their combination. This allows the number of test cases to grow additively instead of multiplicatively, while still providing confidence that the tests are sufficient.

To test-drive complex behaviour, keeping a short feedback loop, we need to be able to break it into smaller increments of behaviour (different dimensions of variability). This ability is known as behavioural composition. Test-driving a complex behaviour through the composite object’s interface might make it difficult to apply behavioural composition, thereby impairing our ability to apply TDD^[14].

If we face difficulties in composing behaviours, it means that the original tests have low composability.

3. 4. 2. One advantage.

High structure-insensitivity.

Not all it’s bad about the original tests because not knowing anything about the internal details of the original object gives them a high structure-insensitivity which is advantageous to reduce refactoring costs.

Original tests properties.

In our next post we’ll use this analysis of test properties to identify the trade-offs involved in deciding whether we should refactor the tests now or later.

4. Conclusions.

In this post, we explained in depth the breaking out technique from Growing Object-Oriented Software, Guided by Tests (GOOS) belongs to a family of techniques (breaking out, budding off, and Bundling up) that helps discover both object and value types.

Breaking out is useful to fix the cohesion problems that may arise because of delaying design decisions until we learn more about the domain. This approach may prove useful when facing volatile and poorly understood domains. A breaking out becomes the way to pay that conscious technical debt. We also described how to recognize the need to apply it, using code smells and, in more severe cases, testability problems as indicators of poor cohesion.

Applying a breaking out splits the initial object into smaller collaborating internal objects and values. The new objects created through this refactoring are treated as internals rather than peers since they remain invisible to the tests and other system parts. After this refactoring, the original tests still have poor readability, writability, specificity, and composability. Despite these disadvantages, such tests have high structure-insensitivity, meaning they are resilient to refactorings affecting the interfaces of the new types.

Our next post will focus on when and how to refactor the original tests. It will be through that refactoring that new peers may appear in our design.

Thanks for coming to the end of this post. We hope that what we explain here will be useful to you.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

Acknowledgements.

I’d like to thank Emmanuel Valverde Ramos, Fran Reyes, Marabesi Matheus and Antonio de la Torre for giving me feedback about several drafts of this post.

Finally, I’d also like to thank icon0 for the photo.

References.

Notes.

[1] These are the posts mentioned in the introduction:

The class is not the unit in the London school style of TDD in which we commented, among other things, the importance of distinguishing an object’s peers from its internals in order to write maintainable unit tests.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness in which we explained how the peer stereotypes helped us identify an object’s peers.

[2] In a section titled Where Do Objects Come From?. We mention the section because we think that its title is important to understand the context of these techniques. It is located in chapter 7, Achieving Object-Oriented Design.

[3] This mind map comes from a talk which was part of the Mentoring Program in Technical Practices we taught last year in AIDA.

[4] The techniques for value types are explained in the section Value Types and the ones for object types are explained in subsection Breaking Out: Splitting a Large Object into a Group of Collaborating Objects from section, Where Do Objects Come From?. Both sections are in chapter 7 of GOOS book: Achieving Object-Oriented Design.

[5] See Martin Fowler’s post Technical Debt Quadrant.

[6] We talked about how this approach produces boundaries similar to the ones obtained applying the classic style of TDD in our post Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.

Steve Fenton’s posts My unit testing epiphany and My unit testing epiphany continued describe this approach well. His epiphany consisted in realizing the class is not the unit. His explanation is influenced by Ian Cooper’s 2013 influential talk TDD, Where Did It All Go Wrong and uses hexagonal architecture’s port concept. The following table expresses how he understood some concepts before his epiphany and how he understands them after it:

Test terminology in "My unit testing epiphany continued" blog post.

[7] In this discussion we consider integration tests as tests that check whether different units work together as expected, but remember that we don’t consider the class as the unit. Integration tests can, and usually, involve external systems, the ones you leave out to get isolated and faster unit tests (database, file, shared memory, etc.).

[8] We need integration tests to at least be Repeatable to avoid flakiness, and Self-validating to enable test automation. Have a look at the discussion about integration tests in our post “Isolated” test means something very different to different people!.

[9] This time might be shorter than we think. In the paper When and Why Your Code Starts to Smell Bad Tufano et al surprisingly found that the changes that were the root cause of cases of the code smell Blob class (a.k.a. Large Class) were introduced already upon the creation of those classes, and not due to their evolution with time as is widely thought. In any case, the more we wait to fix cohesion problems, the harder it will get to fix them.

[10] This code is an example of unfocused tests that are becoming too large to validate the object’s behaviour easily (it was used in a mentoring program we did last year in AIDA).

Only a couple of the test cases in UserAccountCreationTest serve to check the behaviour of UserAccountCreation. Most of them are actually testing the logic to validate the user’s document id. Since we still need to test-drive other behaviours to validate other parts of the user data, those tests will grow even larger and more unfocused. That’s why we think we should refactor these tests before we keep on developing.

It’s kind of difficult to create synthetic examples of tests that express this problem well. A real example might likely be much larger and complex than the example we showed you here. We hope the message, somehow, gets across.

[11] If the lack of cohesion has gone too far, reading Split Up God Class from Object-Oriented Reengineering Patterns, chapter 20 of Working Effectively with Legacy Code or the Splinter pattern from Software Design X-Rays might be helpful. You may also have a look at an interesting documented example of refactoring a large class: Refactoring: This class is too large.

These techniques won’t be necessary if we don’t defer the breaking out too much.

[12] We may get that splitting of responsibilities applying refactorings, such as, Extract Class, Replace Conditional Logic With Strategy, etc.

[13] There are many other desirable test properties in Beck’s test desiderata, but we considered that readability, writability, specificity, composability and structure-insensitivity were the most relevant to discuss the trade-offs involved in a breaking out.

[14] We think that composability is one of the test properties that have more impact on our ability to do TDD in short feedback loops (small behaviour increments). Sometimes the only way to be able to apply behavioural composition is to introduce a separation of concerns in the production code.

Nuestro flujo de decisión para refinar Historias de Usuario poco antes de empezar a desarrollarla

2025-10-08T00:00:00+00:00

Introducción.

En un post anterior exploramos el tamaño y el nivel de detalle adecuados que debe tener una historia de usuario, e identificamos dos momentos clave en los que conviene refinarlas, que a continuación mostramos en orden cronológico:

T_r, que ocurre poco antes de presentar una historia al equipo.
T_c, que ocurre poco antes del momento de empezar a desarrollar una historia, T_d.

En este post describimos el flujo de decisión que seguimos para facilitar el refinamiento de historias de usuario en el momento T_c.

Nuestro flujo de decisión para refinar historias de usuario poco antes de empezar a desarrollarlas.

T_c es un momento clave en el que podríamos plantearnos ciertas preguntas que nos permitirán refinar nuestras historias de usuario lo suficiente como para que podamos desarrollarlas de forma fluida. Estas preguntas^[1] se basan en los criterios INVEST ^[2] que nos ayudan a evaluar lo adecuada que es una historia de usuario.

En el siguiente diagrama mostramos el flujo de decisión que seguimos en T_c para cada una de las historias de usuario.

Flujo de decisión para refinar historias poco antes de comenzar su desarrollo

Para cada una de las historias que pensamos refinar, lo primero es preguntarnos si la historia cumple con los criterios INVEST.

Si la historia cumple todos los criterios INVEST, entonces quiere decir que está lista para ser desarrollada y podemos pasar a la siguiente.

En caso de no cumplir alguno de los criterios, tendremos que preguntarnos si el incumplimiento supone realmente un problema en nuestro contexto^[3].

En caso que el incumplimiento sí que sea un problema, hay que preguntarse si el problema es que la historia de usuario ha dejado de tener valor.

En caso de que ya no tenga valor, deberíamos descartarla y pasar a la siguiente. Eliminar historias sin valor del backlog es muy importante para no generar waste ^[4].

En caso de que la historia siga siendo valiosa debemos refinarla. La forma de refinarla dependerá del criterio INVEST que incumple.

Una vez refinada la historia de usuario, tendremos que volver a evaluarla para verificar si ahora sí que cumple con INVEST.

Cómo evaluar cada criterio y refinarlo si se incumple.

Para facilitar la evaluación de los criterios INVEST, hemos relacionado cada uno de ellos con preguntas clave que nos pueden ayudar a razonar si los estamos incumpliendo. Además, hemos añadido el refinamiento específico que puede corregir el incumplimiento de cada uno de los criterios.

Preguntas clave y refinamientos por criterio

¿Por qué nos resultan útiles estas preguntas clave y estos refinamientos para cada criterio INVEST en T_c?

Analicemos cada uno de los criterios por separado para entender mejor los motivos:

1. Independent (I).

Antes de empezar a desarrollar nos interesa que las historias de usuario sean independientes. Que una historia de usuario sea independiente de otras quiere decir que representa un aspecto funcional disjunto del sistema, y esto facilitará que se puedan comprender, implementar y probar de manera aislada. De modo que lograr que una historia sea independiente tiene un impacto directo en el desarrollo de su funcionalidad.

Consideraremos dos tipos de dependencia^[5]:

Solape.
Orden.

Esto significa que debemos hacernos las siguientes preguntas al evaluar el criterio de independencia:

¿Existe solape entre las historias de usuario?
¿Debemos hacer las historias en un orden determinado?

Dependencia por Solape.

Es la que suele ser más problemática ya que genera confusión y puede dar lugar a los siguientes problemas:

Que nos olvidemos de desarrollar alguna funcionalidad.
Que desarrollemos alguna funcionalidad más de una vez.
Que no podamos desarrollarlas en paralelo, lo que afectará a cómo se puede organizar el equipo.

El solape se puede eliminar reescribiendo las historias.

Pongamos un ejemplo de historias de usuario solapadas y veamos cómo se podría resolver.

Imaginemos que tenemos las siguientes historias.

Mostrar los trabajadores de la empresa y mostrar las ofertas laborales de la empresa.

Mostrar los trabajadores de la empresa y poder enviar un mensaje a la empresa.

Ambas historias incluyen la funcionalidad de “Mostrar los trabajadores de la empresa”. Tal como están escritas estas historias se podrían hacer en cualquier orden por lo que estamos ante un problema puramente de solape.

Una manera sencilla de resolverlo, sería separar la funcionalidad que es común^[6], quedando de la siguiente manera:

Mostrar los trabajadores de la empresa.

Mostrar las ofertas laborales de la empresa.

Enviar un mensaje a la empresa.

Dependencia de Orden.

Si tenemos dos historias de usuario A y B, y el desarrollo de B no puede empezar hasta que no hayamos desarrollado A, existe una dependencia de orden de desarrollo entre las historias A y B que denotaremos como A -> B.

Podríamos liberar esta restricción del orden de desarrollo simulando la funcionalidad de A. Simular la funcionalidad de A consistiría en crear la versión más simple posible de A que permita desarrollar B.

Veámoslo mejor con un ejemplo.

Si tenemos las siguientes historias:

Crear un factura.

Marcar la factura como pagada.

Necesitamos desarrollar “Crear una factura” antes que “Marcar la factura como pagada” porque debe existir una factura que se pueda marcar como pagada. Esto significa que existe una dependencia de orden entre ellas: “Crear factura” -> “Marcar factura como pagada”.

En este caso podríamos simular “Crear factura”, por ejemplo, hardcodeando los datos de una factura. Esto permitiría desarrollar “Marcar factura como pagada” antes que “Crear factura”.

Es importante darse cuenta de que no podríamos usar en producción “Marcar factura como pagada” hasta no haber desarrollado “Crear factura”.

Así que no se puede eliminar la dependencia de orden de la funcionalidad, pero sí que podemos eliminar la dependencia de orden del desarrollo.

Poder desarrollar las historias en cualquier orden puede ser beneficioso, porque nos permite priorizar, ya sea por valor o riesgo, la exploración de determinadas funcionalidades, y así maximizar nuestro aprendizaje:

Priorizar aquellas funcionalidades con más valor para los clientes para buscar feedback más temprano y validarlas.
Abordar cuanto antes los posibles riesgos.

Aunque no siempre es posible solucionar la dependencia de orden, esta suele generar menos problemas que la dependencia por solape ^[7].

2. Negotiable (N).

Las partes implicadas en crear un producto deberían colaborar para acordar qué funcionalidad es necesario desarrollar. Para que esta colaboración sea efectiva, debemos mantener nuestras opciones abiertas^[8].

Para evitar reducir nuestras opciones debemos evaluar si la historia está sobrespecificando la solución. Es decir, si está más centrada en el “cómo hay que hacerlo” que en el “qué hay que hacer”.

Fíjense que estamos eligiendo centrar la evaluación de la capacidad de negociar solo en el “cómo” y dejar fuera de la discusión el “qué”. Hemos decidido hacerlo así por pragmatismo^[9].

Si la historia estuviese sobrespecificada tendríamos que valorar y discutir alternativas para ampliar el horizonte de soluciones. Con esto quizás encontremos alternativas más baratas, eficientes y/o que no especifiquen detalles de implementación.

3. Valuable (V).

Todo incremento de funcionalidad debe aportar valor y, por tanto, siempre debemos cuestionar si una historia de usuario lo tiene^[10]. Además, debemos hacer este cuestionamiento de forma continua para entregar en todo momento el máximo valor posible.

Algunos motivos por lo que una historia podría perder valor son:

Se han dado argumentos que cuestionan su valor en alguna conversación.
El contexto ha cambiado (problema o prioridades).

Hay que tener en cuenta que el valor es relativo, siempre estamos comparando unas historias con otras. Esto significa que lo que solemos observar es que una historia pierde valor con respecto a otras.

Sin embargo, al disponer de recursos limitados, debemos priorizar las historias según su valor, y seleccionar algunas de las más valiosas para desarrollar a continuación.

Debemos hacernos dos preguntas con respecto al valor:

¿Tiene valor?
¿Todos perciben claramente el mismo valor?

Si no conseguimos verle valor a una historia, lo mejor es descartarla^[11].

Que no todos perciban el mismo valor podría deberse a un problema de comunicación. En ese caso, tendríamos que explicar mejor la historia para aclarar su valor.

4. Estimable (E).

Para poder estimar una historia primero tenemos que ser capaces de entenderla.

Lo verdaderamente útil de estimar una historia es identificar y examinar la incertidumbre que encierra, no asignarle una cifra al esfuerzo (tiempo) necesario para desarrollarla.

Reducir la incertidumbre nos ayudará a desarrollar una historia de forma más fluida, y al mismo tiempo, esto hará que su estimación será más precisa.

El origen de la incertidumbre puede venir del espacio del problema o del espacio de la solución. Por ejemplo, la incertidumbre causada por el desconocimiento del dominio vendría del espacio del problema, mientras que la incertidumbre causada por tener poca experiencia en alguna tecnología que necesitamos usar vendría del espacio de la solución.

Distintos miembros del equipo pueden percibir la incertidumbre de una historia de usuario de forma diferente. Esto hace que sea muy importante fomentar que todos los miembros del equipo participen en la discusión sobre la incertidumbre de la historia de usuario (su estimación).

Así que podríamos hacernos la siguiente secuencia de preguntas:

¿Hay incertidumbre en el espacio del problema?.
¿Hay incertidumbre en el espacio de la solución?.

El orden en que nos hacemos estas preguntas es importante, ya que definir mejor el problema podría aclarar la solución.

En caso de haya incertidumbre en el espacio de la solución debido a un desconocimiento de alguna tecnología podríamos reducirla o incluso eliminarla mediante una spike.

En otros casos “añadir más detalles” podría ser una buena forma de reducir la incertidumbre (en un próximo post profundizaremos en qué significa “añadir más detalles”).

5. Small (S).

En el momento T_c nos interesa que las historias sean lo más pequeñas posibles^[12] para poder:

Entregar valor lo antes posible.
Reducir riesgos.
Conseguir ciclos de feedback cortos que nos permitan ajustar prioridades y tomar mejores decisiones.

Debemos plantearnos si existe alguna partición de la historia de usuario que pueda ayudarnos a mejorar alguno de esos aspectos.

Nuestra recomendación es usar de forma sistemática catálogos de heurísticas de partición de historias que nos permitan explorar todas las opciones de partición existentes^[13]. Pensamos que esta recomendación puede ser valiosa tanto para equipos con poca experiencia en partir historias a los que les servirá de guía, como para equipos con experiencia que pueden usarlo para no depender exclusivamente de su memoria.

6. Testable (T).

Que una historia sea testeable nos sirve tanto para evitar malentendidos y suposiciones erróneas, como para saber cuándo está acabada y funcionando cómo se esperaba^[14].

Una historia se considera testeable si dados unos inputs determinados, podemos ponernos de acuerdo sobre el comportamiento esperado del sistema y/o sus efectos observables.

Para ello debemos eliminar cualquier ambigüedad que pueda contener la historia.

Creemos que añadir criterios de aceptación^[15] y ejemplos a una historia de usuario es la manera más efectiva de eliminar su ambigüedad. Así que tiene sentido preguntarnos:

¿Tiene criterios de aceptación suficientes?
En caso que sí, ¿son claros y contienen ejemplos?

Tanto si faltan criterios de aceptación, hay criterios que no son claros o les faltan ejemplos, debemos detallar más la historia para ayudar a aclarar lo que se necesita.

En un próximo post profundizaremos en qué significa detallar más una historia.

Resumen.

En este post hemos descrito y analizado el flujo de decisión basado en los criterios INVEST que seguimos para facilitar el refinamiento de historias de usuario antes de comenzar su desarrollo.

Este flujo usa una serie de preguntas clave para evaluar si una historia incumple alguno de los criterios INVEST, y en caso de incumplimiento nos indica los refinamientos adecuados para mejorarla.

Refinar una historia puede ayudarnos a entregar su valor lo antes posible, reducir riesgos, reducir retrabajo y tener ciclos de feedback más cortos.

Esperamos que este flujo de decisión, o los conceptos de los que les hemos hablado en este post, les puedan resultar útiles.

Serie Historias de Usuario.

Este post es parte de una serie sobre Historias de usuario:

¿Tamaño y nivel de detalle adecuados para una historia de usuario?.
Nuestro flujo de decisión para refinar Historias de Usuario poco antes de empezar a desarrollarla.
Detallando historias de usuario para acotarlas y reducir su ambigüedad.

Agradecimientos.

Quisieramos agradecer a Toño de la Torre y a Alfredo Casado por revisar y darnos feedback sobre el contenido de este post.

Finalmente, también quisieramos agradecer a cottonbro studio por su foto.

Notas.

[1] Las preguntas que nos planteamos en el flujo de decisión que presentamos están pensadas para ayudarnos a conseguir historias listas para ser desarrolladas. Nuestra intención no es buscar la perfección. Al aplicarlo debemos evitar caer en parálisis por análisis. Con este flujo solamente intentamos reducir problemas que la falta de refinamiento puede ocasionar durante el desarrollo, como, por ejemplo, dudas o malentendidos evitables que causan retrabajo y/o retrasan la entrega, aportar poco valor, etc.

[2] Los criterios INVEST nos han dado muy buenos resultados para refinar las historias de usuario y además están muy bien documentados. Si en el futuro encontramos otro conjunto de criterios que nos sean más útiles para el refinamiento de historias, los adoptaríamos. Es decir, nos centramos en INVEST porque es lo que hasta ahora nos ha sido más útil.

[3] La evaluación de estos criterios no ha de aplicarse de manera estricta como si fueran un conjunto de reglas a seguir. Es mejor verlos más bien como una guía.

[4] Si acumulamos historias de usuario sin valor en vez de descartarlas, invertiremos más energía de la necesaria en gestionar el backlog. En un caso extremo podríamos acabar en el antipatrón “Story card hell”, descrito por James Shore como “[…] when you have 300 story cards and you have to keep track of them all” en su post Beyond Story Cards: Agile Requirements Collaboration.

Nos gustaría hacer notar que en un post anterior explicamos cómo se podría llegar a este antipatrón por un motivo diferente: hacer todas las historias demasiados pequeñas en un momento alejado de T_r.

[5] William Wake nos habla de otro tipo de dependencia, containment dependency que ocurre cuando existe una organización jerárquica de varias historias de usuario. En nuestra experiencia las dependencias por solape y orden son más frecuentes así que preferimos ignorar la dependencia por containment en aras de la simplicidad.

[6] En algunas ocasiones, al intentar solucionar una dependencia por solape aparecerá una dependencia de orden.

[7] Algunos motivos por los que creemos que la dependencia de orden genera menos problemas que la dependencia por solape, son:

Cuando la propia naturaleza del problema lleva implícita un orden.
Cuando los participantes han asumido un orden, a veces debido a que han tenido experiencias en contextos similares.

Por ejemplo, las siguientes historias:

Envíar un mensaje.

Reenvíar un mensaje.

Tienen una dependencia de orden, pero por la naturaleza del problema es altamente probable que primero hagamos “Envíar un mensaje” antes que “Reenvíar un mensaje”. Los problemas ocurren cuando no es claro qué orden establecer.

[8] Martin Fowler habla del concepto de Decreed Stories para aquellas historias en las que no hay conversación. En contraposición está el concepto de Conversational Stories en la que la conversación es el núcleo de las historias y que recoge el criterio de Negotiable de INVEST.

[9] Tener capacidad de negociar “qué hay que hacer” puede tener un gran impacto en el trabajo con historias de usuario.

Sin embargo, conseguir poder negociar el “qué” puede implicar modificar el modelo de colaboración existente en un equipo, o incluso, una organización entera. Cambiar las dinámicas de una organización es un problema muy complejo que se sale del ámbito de la discusión del flujo de decisión para refinar historias que estamos presentando.

Por eso, preferimos centrarnos tan solo en “el cómo” (la sobrespecificación), al ser en nuestra experiencia, más accionable a la escala de una historia de usuario.

[10] En este post ampliamos el concepto de valor, normalmente acotado a la funcionalidad, para que también incluya aquellos trabajos de cuidado destinados a mantener la sostenibilidad del sistema.

En este otro post hablamos sobre la importancia de los atributos de calidad, a menudo denominados requisitos no funcionales (aunque esta etiqueta puede ser engañosa) y su relación con las historias de usuario.

[11] No ver valor en una historia de usuario podría estar causado porque falta la perspectiva de alguna parte interesada (stakeholder). Si fuera así, no deberíamos descartar la historia, sino tener una nueva conversación sobre ella en la que incluyamos a dicha parte interesada.

[12] El criterio de Small ha generado bastante confusión.

Bill Wake ahora prefiere usar el concepto Scalable, “I now use another S […]: Scalable”, porque cree que captura mejor la idea de que una historia debe cambiar en tamaño o escala para adecuarse al momento en el que se encuentre.

Para profundizar más lean su post Small – Scalable – Stories in the INVEST Model. Nuestro post ¿Tamaño y nivel de detalle adecuados para una historia de usuario? también habla de este aspecto.

En el post actual usamos Small en vez de Scalable porque estamos analizando el refinamiento que se da poco antes de empezar a desarrollar la historia, y ahí no cabe confusión posible: la historia de usuario debe de ser lo más pequeña posible.

[13] Hay varias heurísticas interesantes que nos pueden indicar posibles particiones. En este artículo hablamos sobre SPIDR, que puede ser un buen punto de partida. En el curso de Historias de Usuario nos basamos en el trabajo de Bill Wake.

[14] La confirmación es uno de los aspectos esenciales enunciados por Ron Jeffries en su post de 2001, Card, Conversation, Confirmation.

[15] Algunos autores usan otros términos para hablar de los criterios de aceptación. Por ejemplo, Mike Cohn prefiere hablar de conditions of satisfaction, mientras que en Example Mapping se utiliza el concepto de rules.

La clase no es la unidad en el estilo de TDD de Londres

2025-09-29T05:30:00+00:00

Este post es una traducción del post original en inglés: The class is not the unit in the London school style of TDD.

Introducción.

Una idea errónea y peligrosa: considerar que la clase es la unidad al escribir test unitarios.

Considerar que la clase es la unidad en los test unitarios tiene efectos terribles. Si seguimos esta idea, usaremos dobles de prueba para aislar la clase que estamos testeando de cualquier clase que colabore con ella (sus colaboradores). Esto producirá tests altamente acoplados a detalles de implementación y por tanto muy frágiles. Dichos tests serán muy sensibles a la estructura del código^[1].

Considerando la clase como la unidad...

Esta fragilidad hará que las refactorizaciones que afecten a interfaces a las que nuestros tests estén acopladas sean más caras (tomarán más tiempo^[2]), ya que nos veríamos forzados a cambiar también los tests. Este incremento en el coste puede convertirse en un obstáculo para refactorizar.

Muchos problemas al usar dobles de prueba son causados únicamente por esta idea errónea de considerar la clase como la unidad. Afortunadamente, esta idea parece estar retrocediendo, ya que cada vez más desarrolladores están empezando a entender que la unidad en los test unitarios debe ser el comportamiento y no la clase. Enteder esto ayuda a producir tests menos sensibles a la estructura que no obstaculizan la refactorización.

La clase no es la unidad.

Una idea errónea que persiste: considerar que la clase es la unidad en el estilo de TDD de la Escuela de Londres o estilo Mockist.

Recientemente, hemos notado muchos videos, publicaciones e incluso libros ^[3] que afirman que el llamado estilo mockist de TDD considera que la clase es la unidad en los test unitarios.

Desafortunadamente, esta otra idea errónea sigue estando muy extendida y está provocando que, o bien, algunos desarrolladores apliquen el estilo mockist de TDD de manera completamente incorrecta (probando cada clase en aislamiento de sus colaboradores), o bien, que decidan no usar dicho estilo en absoluto para evitar los problemas asociados a considerar que “la clase es la unidad” que describimos antes.

En el resto de esta post, mostraremos como el estilo mockist de TDD no considera que la clase sea la unidad en los test unitarios.

Durante todo el resto de nuestra discusión, usaremos el libro Growing Object Oriented Software, Guided by Tests (GOOS) de Steve Freeman y Nat Pryce como referencia.

La clase tampoco es la unidad en el estilo mockist de TDD.

Prueba 1: Valores y Objetos.

En la sección Values and Objects (capítulo 2: Test-Driven Development with Objects) del libro GOOS, sus autores distinguen entre dos conceptos:

Valores, que “modelan cantidades o mediciones inmutables” (piensa en Value Objects).
Objetos, que “tienen identidad, pueden cambiar de estado con el tiempo y modelan procesos computacionales”.

Cuando en el libro GOOS se usa la palabra “object”, se refieren solamente al segundo concepto.

¡No uses dobles de prueba para simular valores!

Como su mismo título indica, en la sección Don’t Mock Values (capítulo 20: Listening to the Tests) recomiendan no usar dobles de prueba para simular valores en los tests.

Los autores del GOOS dicen aún más:

“There’s no point in writing mocks for values (which should be immutable anyway). Just create an instance and use it.” (“No tiene sentido escribir mocks para valores (que de todas formas deberían ser inmutables). Simplemente crea una instancia y úsala.”)

Esta recomendación por sí sola demuestra que la idea de aislar la clase que estamos probando de todas las clases con las que colabora nunca ha formado parte del estilo mockist.

Es posible que la confusión existente haya surgido porque ambos conceptos, valores y objetos, se implementan usando la misma construcción de lenguaje en la mayoría de los lenguajes orientados a objetos: la clase.

Hay autores que aún reconociendo la distinción entre valores y objetos, siguen sosteniendo que la clase es la unidad en el estilo mockist de TDD^[4]. Como acabamos de mostrar dicha afirmación es una contradicción.

Hay más ideas en el libro GOOS que refutan la falsa creencia de considerar que la clase es la unidad en el estilo mockist de TDD.

Prueba 2: Objetos Internos frente a Pares^[5].

Para los autores del libro GOOS no todos los objetos que colaboran con un objeto son considerados de la misma menera.

En la sección Internals vs Peers (capítulo 6: Object-Oriented Style), distinguen dos tipos de colaboradores:

Pares (“verdaderos colaboradores”).
Objetos Internos.

Objetos Internos vs Pares de la charla Mock Roles Not Object States.

Lamentablemente, esta distinción entre objetos internos y pares es probablemente uno de los conceptos menos comprendidos del libro.

Reconociendo a los pares.

Los autores del libro GOOS consideran que los pares de un objeto son “objetos con responsabilidades únicas”, es decir, que siguen el principio de responsabilidad única, y que pueden clasificarse (de manera flexible) en tres tipos de relación.

Estereotipos de pares:

Dependencias: servicios que el objeto necesita de su entorno para poder cumplir con sus responsabilidades.
Notificaciones: otras partes del sistema que necesitan saber cuando el objeto cambia de estado o realiza una acción.
Ajustes o Políticas: objetos que ajustan o adaptan el comportamiento del objeto a las necesidades del sistema (piensa en el Patrón Estrategia).

Cualquier colaborador que no sea un par se consideraría un objetos interno.

Ellos solo consideran estos estereotipos como heurísticas para ayudarnos a pensar en el diseño, no como reglas estrictas. Más adelante en el libro, en la sección Where Do Objects Come From? (capítulo 7: Achieving Object-Oriented Design), explican otras heurísticas que podemos aplicar para descubrir los pares de un objeto: ”Breaking Out”, “Budding Off” y ”Bundling Up”. Hablaremos de estas técnicas en una publicación futura.

En su charla Mock Roles Not Object States, Freeman y Pryce ofrecen una excelente explicación de los conceptos de objetos internos y pares al discutir el test smell “The test exposes internal implementation details of my object”.

¡No uses dobles de prueba para simular objetos internos!

Identificar los pares de un objeto es crucial para minimizar el acoplamiento de los tests a los detalles de implementación, ya que los objetos internos no deben ser simulados en los tests:

“We should [only] mock an object’s peers—its dependencies, notifications, and adjustments […]—but not its internals” (“Deberíamos simular [solamente] los pares de un objeto, sus dependencias, notificaciones y ajustes […], pero no sus objetos internos”) (capítulo 7: Achieving Object-Oriented Design).

En nuestros tests solo usaremos dobles de prueba para simular los comportamientos (roles, responsabilidades) de los que depende el comportamiento que estamos probando, no las clases de las que depende. Esto está relacionado con la recomendación “mock roles, not objects”, y esos roles en los que dependen un objeto son sus pares.

En nuestra opinión, los objetos internos no deberían inyectarse desde fuera, sino que deberían instanciarse dentro de los constructores de los objetos a los que pertenecen.

La razón tanto de no usar dobles de prueba para simular objetos internos, como para instanciar los objetos internos en los constructores de los objetos a los que pertenecen, es evitar que los tests “sepan” que existen, y que así no estén acoplados con ellos.

Esta es una diferencia importante entre los objetos internos y los pares: los pares tienen comportamientos lo suficientemente interesantes como para ser “conocidos” y documentados en los tests, mientras que los tests ni siquiera “conocen” la existencia de los objetos internos.

¿Cuál es entonces la unidad en el estilo mockist de TDD?

Esperamos, al menos, haber logrado convencerlos de que la clase tampoco es la unidad en el estilo mockist de TDD.

Entonces, ¿qué se considera como unidad el estilo mockist de TDD?

Al igual que el estilo clásico de TDD, el estilo mockist de TDD considera el comportamiento como la unidad en los tests unitarios^[6]. Y, como hemos visto, un comportamiento puede ser implementado por 1 o N clases, pero esto último ya es solamente un detalle de implementación.

Conclusión.

El propósito de esta publicación era mostrar como una idea muy extendida sobre el estilo mockist de TDD es errónea.

En algunos casos, esta idea errónea proviene de no haber leído o no haber comprendido bien el libro GOOS.

En otros casos, creemos que, lamentablemente, esta idea de que la clase es la unidad se utiliza como un hombre de paja para criticar el estilo mockist de TDD, culpando al estilo mockist de TDD de todos los problemas de mantenibilidad al usar dobles de prueba que en realidad están asociados a considerar la clase como la unidad.

Esperamos, que haber desmentido esta idea errónea, pueda facilitar discusiones más racionales sobre los trade-offs del estilo mockist de TDD y también permitir que se aplique de forma más efectiva.

La serie sobre TDD, dobles de prueba y diseño orientado a objetos.

La clase no es la unidad en el estilo de TDD de Londres.
¡”Isolated” test significa algo muy diferente para distintas personas!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness, (aún por traducir).
Breaking out to improve cohesion (peer detection techniques), (aún por traducir).
Refactoring the tests after a “Breaking Out” (peer detection techniques), (aún por traducir).
Bundling up to reduce coupling and complexity (peer detection techniques), (aún por traducir).

Agradecimientos.

Quisiera agradecer a Fran Reyes, Alfredo Casado, Emmanuel Valverde Ramos, Fran Iglesias Gómez y Marabesi Matheus por darme freedback sobre varios borradores de este texto.

Finalmente, también quisiera agradecer a William Warby por su foto.

Referencias.

Notas.

[1] Cuando aislamos una clase de todas las clases con que colabora, los tests resultantes tendrán una sensibilidad a la estructura muy alta, cuando lo ideal sería que los tests sean insensibles a la estructura (ver Test Desiderata 2/12 Tests Should be Structure-Insensitive).

[2] Si aplicamos un parallel change, el test no fallará en ningún momento durante la refactorización, pero esta es más costoso que hacer una refactorización que no afecta a los tests.

[3] Busca en Internet y encontrarás múltiples ejemplos de la idea errónea que estamos desmintiendo en esta publicación.

[4] Esto ocurre en el libro Unit Testing Principles, Practices, and Patterns.

[5] Estamos sustantivando el primer significado del adjetivo “par” que es “igual o semejante totalmente” (ver par en la RAE).

Consideramos que es el que más se aproxima a “peer” que significa “a person of a similar age, position, abilities, etc. as others in a group” (ver peer en Cambridge dictionary).

Otra traducción adecuada de los “pares de un objeto” podría ser “los iguales de un objeto”. Mantuvimos “pares” porque se parece más a “peers”.

[6] Los autores del libro GOOS afirman que debemos “Unit-Test Behavior, Not Methods” (“Probar unitariamente el comportamiento, no los métodos”) (capítulo 5: Maintaining the Test-Driven Cycle).

Removing commented-out code

2025-09-08T05:00:00+00:00

This post is a translation of the original post in Spanish: Eliminando código comentado.

Introduction.

Dead Code is a smell classified within the Wake taxonomy^[1] under the Unnecessary Complexity category. It usually appears in the form of variables, parameters, fields, code fragments, functions or classes that are no longer executed.

The problem is that most of the time we are not sure whether a given piece of code is still used or not. Not knowing whether a piece of code is running or not increases our cognitive load because we have to take it into account and understand it, whenever we are making functional changes or fixing bugs. This unnecessarily increases the complexity of a change. To eliminate this complexity, it would be enough to eliminate dead code, but to do that, we must first be able to detect it.

There are several ways to detect dead code. The most effective ones rely on the use of tools; for example, most IDEs warn about elements that are no longer used. These tools reduce the cost that would otherwise come from having to detect dead code just by reading the code.

The tools available depend both on the language being used and on the language features employed in the code. In general, we can say that detecting dead code becomes more difficult the more dynamic the features we are using are.

In this post we will focus on a type of dead code that is perhaps the easiest to detect: commented-out code.

Problems with commented-out code.

We often find commented-out code interspersed with the rest of the code. This breaks the reading flow and forces us to make an effort to ignore the commented code. If the commented code blocks are large, sometimes we are forced to scroll in order to continue reading.

Long block of commented code.

In addition to the increase in cognitive load that any dead code generates, commented-out code can cause confusion when we take into account, whether with the intention of using it in the future or as an aid to understand the current code, because commented-out code quickly becomes outdated. Removing commented-out code is usually simple: we just delete the comment containing the code, and if removing it leaves a file empty, we delete the file as well

Common resistances to removing commented-out code.

One of the arguments we often encounter for not wanting to remove commented-out code is the belief that it will be needed at some point in the future. For example, sometimes people want to keep the code from a previous implementation that is complex to remember. A more practical way to allow recovery of a previous version of the code without maintaining commented-out code is to rely on the version control system we use.

A common argument against this solution is that it is much easier to recover commented-out code than to find a previous version in version control. Although it is true that finding a previous version in version control is more difficult, this friction is reduced if we improve our ability to navigate the version control history (either through the IDE or via the command line). In addition, we should consider two other factors against keeping commented-out code: Over time, the need to recover code from a previous version becomes increasingly unlikely because the code will diverge more and more from that past version.

The problem of unnecessary complexity, which will make evolving the code more costly until the commented-out code is removed.

Automatically removing commented-out code.

If commenting out code has been a widely used team practice for a long time, we can reach a situation where the cost of removing it is high, and we will have no choice but to live with it for some time, during which we will have to opportunistically delete commented-out code while we are delivering functionality. In such a situation, it may also be useful to explore tools that automatically remove commented-out code. There are multiple tools that could do this work for most languages. One way to narrow down the tool search is to start by understanding our IDE and taking advantage of its features. For example, we recently applied this strategy of automatic removal of commented-out code for a client working with Java and IntelliJ. IntelliJ has a code analysis tool that includes different types of inspections. Beyond the analysis itself, the most powerful feature of this tool is that it allows executing actions (“fixes”) on the detected issues.

Running inspections by name in IntelliJ.

The specific inspection for detecting commented-out code is ”Commented out code”. You can select the analysis scope, apply various filters, and set the minimum number of lines for comments to consider (which can be useful, for example, if we want to start with large blocks of commented-out code).

Options for running the 'commented-out code' inspection.

Next, we can select the detected elements we want and proceed to apply some of the fixes suggested by the IDE; in this case, we will apply Delete comment.

Proposed fixes to resolve commented-out code.

After making these changes, run your tests to ensure that the expected behavior has not been altered. Depending on your situation (test coverage, team confidence, etc.), it may also be useful to verify that the deletion was done correctly by reviewing the resulting code. However, if there are many changes, this can be very labor-intensive. In that case, you could plan the deletion in multiple phases, dividing it by file types, packages, or another division criterion that suits your situation.

Conclusion.

We have seen that commented-out code is one of the forms in which the Dead Code smell appears, and how this smell unnecessarily increases the complexity of our code.

We have presented the most common arguments (in our experience) for resisting the removal of commented-out code, and provided counterarguments to refute them.

Finally, when working with a codebase full of commented-out code, we have recommended an alternative to removing commented-out code through opportunistic refactoring: exploring the tools at your disposal to see if they offer functionalities to automatically remove dead code. This will allow you to eliminate a larger amount of commented-out code at a manageable cost.

Notes

[1] You can read about Wake taxonomy and others in our post On code smells catalogues and taxonomies.

Segregating a test builder applying the curiously recurring template pattern

2025-07-29T06:00:00+00:00

Introduction.

In this post we show the evolution of a test builder to support several parallel changes we made to evolve the design of the production code. This evolution degraded the design of the test builder until a point where we felt the need to refactor it to avoid potential problems.

The evolution of the test builder.

Step 1.

Initially, we had some data representing a claim. These data were what we call “travelling data”, which are data that are taken by the application from one of its edges to another without being transformed or having any influence on the execution flow or logic of the application. So, we kept them in a DTO, called ClaimData, and that’s what the test builder initially built (we elided some details for the sake of brevity):

Step 2.

Later in the development of the application, some requirements made it necessary to introduce new logic having to do with some claim data. So we introduced a domain object, Claim, which we mapped from ClaimData to encapsulate that logic.

Since they held nearly the same information, a slight change to our test builder allowed us to do the required parallel change smoothly. This the resulting code of the test builder (we elided some details for the sake of brevity):

Notice the two methods build and buildData() that are used to create different objects from the same data. They were very handy to smoothly migrate our tests to the new design.

Step 3.

Finally, a new change required to introduce two different states for a claim. So Claim became an interface implemented by two new classes: ReadyToOpenClaim and OpenButNotNotifiedClaim.

We tweaked again the test builder in order to support the refactoring to this new design (we elided some details for the sake of brevity):

This test builder can build instances of three classes: ClaimData (the DTO), ReadyToOpenClaim and OpenButNotNotifiedClaim.

The building of each kind of object shared most of the setters. However, there was a setter, withCompany, that was only used to build ReadyToOpenClaim objects, and two other setters, withOpeningListener and withReferenceInCompany, that were only used to build OpenButNotNotifiedClaim objects. This was confusing.

Notice also the conditional in the build method.

This test builder had too many responsibilities, so after finishing refactoring the production code, we needed to refactor it.

We wanted to split it into three test builders, one for each kind of object: ClaimData, ReadyToOpenClaim and OpenButNotNotifiedClaim, while still reusing as much code as possible.

We didn’t know the best approach to do this, so, outside of work hours, I explored refactoring it to various alternative designs to both solve the problem, and learn and practice.

Two failed designs.

Approach 1: Segregating interfaces.

First, I tried segregating interfaces and having a test builder that implemented all of them.

This design allowed reusing most of the setters and avoided the possibility of using a method that was not involved in creating a given kind of object. For instance, it avoided being able to use withOpeningListener and withReferenceInCompany when not building an instance of OpenButNotNotifiedClaim.

On the negative side, I couldn’t call the setters in any order anymore which made the experience of using the fluid interface less smooth.

Approach 2: Using inheritance.

I created an abstract Claimbuilder containing all the common fields and setters, and some abstract methods (build and buildData).

Then I made three concrete builders that inherited from Claimbuilder: ClaimDataBuilder, ReadyToOpenClaimBuilder and OpenButNotNotifiedClaimBuilder that created instances of ClaimData, ReadyToOpenClaim and OpenButNotNotifiedClaim, respectively.

This design also reused most of the setters and avoided the possibility of using setters that were not involved in creating a given kind of object.

In order to be able to call the setters in any order, the method that created the instances had to be declared as an abstract public method in Claimbuilder, and this meant two problems:

The method that created the instances of ClaimData could not be called build. This is because, in Java, method overloading is not allowed for methods that differ only in their return types (see Overloading methods with arguments of different types). So, I couldn’t have two methods with the following signatures: ClaimData build() and Claim build().
Because of the first problem. I had to declare two abstract public methods in Claimbuilder: ClaimData buildData() and Claim build(). This meant that each derived builder had both methods in their interface.

Finally a successful design!

I thought: “if only the return type of the setters was different for each type of builder”, and it came to me that the answer might be using generics.

So I created an initial version of Claimbuilder using generics to be able to use different return types for the setters:

I elided some details for the sake of brevity, but you can still notice in the setters how they return the generic type T.

Another improvement over the previous design was that buildData became protected.

The casts to T in the returns of the setters are unchecked which produces an unchecked-cast warning.

Having Claimbuilder I used it to create the following three derived builders:

ClaimDataBuilder:

ReadyToOpenClaimBuilder:

OpenButNotNotifiedClaimBuilder:

Notice how each of the concrete builders is specifying to itself the type used in the generic Claimbuilder base class.

This enables our previous stated desire: “if only the return type of the setters was different for each type of builder”. Now, the setters of each concrete builder return its own type, which solves all the problems I faced with the two previous designs.

Each derived builder defines methods that are only related to what it builds.

I can call the methods in any order, and only the methods involved in building instances of a given class are available.

Finally, I improved Claimbuilder bounding the kind of types that Claimbuilder can be specified with, so that only types that are derived from itself can be used.

Notice how I bounded the generic in the class declaration:

class ClaimBuilder<T extends ClaimBuilder<T>>

It turns out that what I had done is known as the Curiously recurring template pattern (CRTP), also known as F-bound polymorphism.

If I had known the pattern (its intent, applicability and consequences), I could have gotten to this design much faster… 😅 I’ll do it next time.

Finally, I also added a method self to encapsulate the unchecked cast to T (advised by IntelliJ’s AI assistant), and annotated it to suppress the warning.

Summary.

This post chronicles the evolution of a test builder through multiple stages of development, highlighting how the initial simple design gradually became more complex as new requirements emerged. From a basic DTO builder for claim data, it evolved to also create a claim domain object, and eventually to support the creation of multiple claim states. This evolution led to a test builder with too many responsibilities.

I refactored the test builder to several alternative designs. The first approach using interface segregation compromised the fluid interface’s flexibility, while the second one using inheritance ran into Java’s type system limitations with method overloading.

Those failed attempts led me to explore a more sophisticated approach using generics, that unknowingly applied the Curiously recurring template pattern, in which a class X derives from a generic class instantiation using X itself as a type argument.

The resulting design addressed my requirements because it enabled chaining setter methods in any order while restricting available methods to only those relevant for building each specific claim type.

Acknowledgements.

I’d like to thank my colleague Fran Reyes for giving me feedback about this post.

I’d also like to thank Carlos Miguel Seco for giving us the opportunity to work with him on a very interesting project.

Finally, I’d also like to thank mariofcomeh61 for the photo.

Convirtiendo tests no paramétricos en paramétricos con la IA (e intentando generar ejemplos)

2025-07-18T06:00:00+00:00

Introdución.

Una de las cosas para las que suelo usar la IA con muy buenos resultados, es para pasar un test de no paramétrico a paramétrico.

Suelo introducir tests paramétricos en muchos contextos diferentes para quitar duplicación y subir el nivel de abstracción de la descripción del test, de forma que describa más directamente una regla de negocio o un comportamiento.

Ejemplo 1.

Veamos un ejemplo de cómo el asistente de IA de IntelliJ me permite hacer este cambio muy rápidamente:

Empecé seleccionando el test que quería cambiar y escogí la opción de abrir un nuevo chat de IA con la selección.

Una vez en el chat le pedí que me conviertiera el test seleccionado en un test paramétrico:

User: convert to parametric test passing as parameter a word and an expectedKey, in this case they are “A” and “a”, respectively

El asistente me lo hizo sin problema:

Assistant: I’ll help you convert the test to a parametric test using Jest’s test.each. Here’s the converted test: This test uses Jest’s test.each which allows you to: [… explica un montón de cosas sobre Jest, los tests paramétricos, cómo funciona todo, etc.]

El código generado tenía buena pinta por lo que le dije que lo insertara en el lugar donde tenía el cursor (caret), y después ejecuté los tests.

Como los tests pasaron, hice commit. Si los tests no hubieran pasado, hubiera hecho una “retirada honrosa”^[1]. Debo decir que esto último aún no me ha pasado al transformar tests a parámetricos.

Después de tener el test paramétrico, como el motivo para pasar a tests paramétricos era que quería triangular sin generar duplicación, le pedí al asistente que me generase un ejemplo más:

User: generate another example

Assistant: Based on the domain of the application (text processing with case insensitivity), I’ll generate one more test case that cover a different scenario:

Además el asistente me propuso una implementación obvia del código de producción, (que yo tenía “fakeado” para pasar el primer ejemplo a verde), que hacía que ambos tests pasaran:

Si el motivo para pasar a tests paramétricos hubiese sido que quería añadir más casos de tests para un código ya escrito (es decir, fuera de un flujo de TDD), también se le podría pedir que genere varios ejemplos más. En este caso, el asistente no sólo los genera, sino que además explica qué criterios usó para elegir cada ejemplo.

Assistant: Based on the domain of the application (text processing with case insensitivity), I’ll generate more test cases that cover different scenarios:

These test cases cover:

Single uppercase letter

Capitalized word

All uppercase word

Mixed case word

Alternating case

Word from the domain example

Alphanumeric string

String with whitespace

String with special characters

String with non-ASCII characters

Each test case verifies that the input string is converted to its lowercase equivalent, which is the expected behavior of the CaseInsensitiveWordToKey class.

En este caso concreto, muchos de los ejemplos no eran necesarios y sólo introducían ruido, por lo que eliminé la mayoría de ellos.

La generación de nuevos ejemplos con la IA no es algo que vaya demasiado bien, y, dependiendo del contexto, puede generar muchos ejemplos redundantes.

Encuentro que conociendo conceptos como particiones de equivalencia y análisis de valores de frontera puedo generar yo mismo ejemplos más significativos de manera más eficiente (o guiar a la IA para que lo haga mejor)^[2].

En el siguiente ejemplo veremos otro tipo de problema que se puede dar cuando generamos ejemplos para tests con la IA.

Ejemplo 2.

Hasta ahora hemos visto un caso muy sencillo. El siguiente ejemplo en C# y Nunit es algo más complicado.

En este ejemplo estaba probando el asistente de IA para añadir tests a un código ya existente que validaba los datos personales de un usuario para decidir si abrirle una cuenta en el sistema o no.

User: pass to parametric test passing a validDNI, add several examples, don’t add what comments [la última parte del prompt me evita las, al menos para mí, molestas líneas de comentarios con Given, When y Then, (o la versión alternativa de comentarios con Arrange, Act y Assert)]

Assistant: Based on the code, I’ll help convert the test to use parametric testing with multiple valid DNI examples. Looking at the existing test structure and other tests in the file, here’s how we can modify it: I’ve added multiple test cases with valid Spanish DNI formats. Each DNI follows the pattern of 8 digits followed by a control letter. You can remove the original non-parametric test since this parametric version covers the same functionality with more test cases.

Después de insertar este test donde tenía el cursor, lancé los tests y resultó que dos de los DNI “válidos” generados no eran válidos según el código de producción: “72841539P” y “23456789T”.

Como estábamos testeando un código a posteriori, en ese momento no podíamos saber si estos fallos se debían a que los DNI generados como válidos por la IA eran realmente inválidos, es decir la IA los había “alucinado”, o si, por el contrario, los ejemplos generados por la IA eran correctos y habíamos descubierto algún error en el código de producción.

Para averiguar cuál de las dos razones estaba provocando los fallos utilicé dos herramientas de validación online^[3] y resultó que los dos valores generados por la IA que hacían fallar el test eran realmente inválidos. Esto quería decir que la IA se había equivocado.

Como aproveché estos ejemplos de DNI inválido alucinados para el test paramétrico Cannot_Create_User_Account_When_Invalid_Dni_Is_Provided, la alucinación no me fue tan mal 😅.

En cualquier caso, este ejemplo debería servir como recordatorio de que hay que tener mucho cuidado al generar casos de test directamente con una IA porque puede alucinar y generarnos ejemplos erróneos. Tengo que decir que en este experimento de añadir tests a posteriori a la validación de DNI, NIE y CIF la IA se equivocó (alucinó) muchísimo.

Nuestro conocimiento sobre el dominio, o, como en este caso, disponer de herramientas de validación alternativas, nos puede ayudar a evaluar si los ejemplos generados por la IA son correctos.

Una alternativa más lenta, en este caso, hubiera sido generar los ejemplos nosotros mismos a partir de una especificación.

Otra alternativa, aún más interesante, hubiera sido usar una técnica de desarrollo como TDD para desarrollar el código, que nos permite generar los tests y el código de producción de forma incremental, y nos puede dar más confianza de que estamos convergiendo hacia una solución que realmente funciona.

Conclusión.

Hemos mostrado en diferentes contextos como un asistente de IA nos puede ser muy útil para pasar un test de no paramétrico a paramétrico de forma muy eficiente.

También hemos visto cómo la generación de ejemplos de test con IA puede ser problemática debido a:

la generación de casos de test erróneos debidos a “alucinaciones”.
la generación de casos de test redundantes.

Conocer técnicas de testing^[4] como particiones de equivalencia y análisis de valores de frontera puede ayudarnos, respectivamente, a eliminar casos de test redundantes y a añadir casos de test relevantes que nos falten.

Sin embargo, generar casos de tests erróneos debido a alucinaciones es un problema más fundamental, y no les quedará otra que revisar muy bien los tests generados por la IA. Por ahora, sólo podemos recomendarles que tengan mucha precaución si usan la IA para generar tests a posteriori.

Creemos que hay otras técnicas existentes que les pueden dar mejor resultado:

a. Si están testeando código legado, técnicas como characterization testing o sampling + golden master (o su mejora con herramientas, approval testing) en combinación con mutation testing.

b. Si están testeando código a posteriori que acaban de escribir, y que por tanto no es código legado porque aún no da valor a ningún usuario, lo indicado sería escribir tests que chequeen que ese código hace lo que debería hacer, es decir, que chequeen que el código cumple con su especificación (specification-based testing). A continuación, podrían completar y mejorar los tests resultantes aplicando structural testing y/o mutation testing.

En ambos casos podríamos usar la IA como asistente para facilitarnos parte del trabajo.

¿Están usando IAs para generar tests? ¿Cómo están siendo sus experiencias?

Agradecimientos.

Me gustaría darle las gracias a Fran Reyes por revisar y darme feedback sobre el primer borrador de este post.

También me gustaría agradecer a Olia Danilevich por la foto suya que usamos para este post.

Notas.

[1] La “retirada honrosa” (“honourable retreat”) es una de las técnicas descritas por Joshua Kerievsky en su charla The limited red society en la que introduce y demuestra tres técnicas para reducir el tiempo que tus tests están en rojo mientras refactorizas: “honourable retreat”, “narrowed change” y “parallel change”. En nuestra formación Code Smells & Refactoring profundizamos en ellas y las practicamos en varias katas.

[2] Profundizamos en estos conceptos y los practicamos en nuestras formaciones Cambiando Legacy, TDD y Técnicas de Testing para desarrolladores, desde puntos de vista liegeramente diferentes.

[3] Usé https://andresledo.es/herramientas/validar-dni-nif-cif-online/ y https://testingdatagenerator.com/doi.html.

[4] En este post hemos mencionado varias técnicas de testing que pueden ser muy útiles tanto si trabajamos con una IA como si no.

La siguiente tabla muestra en cuáles de nuestras formaciones se explican y practican en profundidad estas técnicas de testing (el énfasis y el punto de vista pueden variar un poco según el curso).

Técnica / Formación	Cambiando Legacy	Técnicas de Testing para desarrolladores	TDD
Particiones de equivalencia	❌	✅	✅
Análisis de valores de frontera	✅	✅	✅
Characterization testing	✅	✅	❌
Sampling + Golden Master	✅	✅	❌
Approval testing	✅	✅	❌
Mutation testing	✅	✅	✅
Specification-based testing	❌	✅	✅
Structural testing	✅	✅	❌

Using prompt patterns to enhance how you learn about prompt patterns

2025-07-14T06:00:00+00:00

Introduction.

I’m learning about prompt engineering which is the practice of designing effective inputs (prompts) to guide AI models toward producing accurate, useful, or creative outputs.

To that purpose I’m free auditing Coursera’s Prompt Engineering for ChatGPT course by Jules White.

As part of this course, I read the paper A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT which presents a structured approach to prompt engineering using patterns, much like design patterns in software engineering.

The paper identifies 16 prompt patterns, grouped into 5 main categories:

Input Semantics: Meta Language Creation
Output Customization: Output Automater, Persona, Visualization Generator, Recipe and Template.
Error Identification: Fact Check List and Reflection.
Prompt Improvement: Question Refinement, Alternative Approaches, Cognitive Verifier and Refusal Breaker.
Interaction: Flipped Interaction, Game Play and Infinite Generation.
Context Control: Context Manager.

According to the authors, “prompt patterns are essential to effective prompt engineering” because “[they] document successful approaches for systematically engineering different output and interaction goals when working with conversational LLMs.”

Using prompting patterns to create retrieval practice exercises about prompting patterns.

Previously I had audited another related Coursera course, Accelerate Your Learning with ChatGPT by Jules White and Barbara Oakley which explores how to enhance your learning using generative AI tools, integrating insights from neuroscience, cognitive psychology, and AI^[1].

Retrieval practice, which involves recalling to-be-remembered information from memory, is one of the most effective learning methods discovered to date. This technique works especially well when you subsequently check your answers against your study materials. According to Jules White and Barbara Oakley, generative AI can be a great way to create retrieval practice exercises.

After reading the paper, I wanted to do some retrieval practice to learn the contents in the paper more deeply, so I decided to use what I remembered from reading the paper to prompt ChatGpt to create a retrieval practice game. Doing this, I was not only applying what I had read about prompting patterns (an example of retrieval practice in itself), but also, taking advantage of generative AI to get more opportunities to do retrieval practice and receive immediate feedback on my attempts.

Creating and playing a prompt pattern learning game.

This is part of my raw interaction with ChatGPt, which shows how I prompted it to create a prompt pattern learning game, and how I did retrieval practice by plaing the game (I’ve added some thoughts and comments that were not part of the interaction between square brackets):

After uploading the A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT paper PDF on ChatGpt:

Me: If you were this PDF how would you create a game to help me learn about you? [I was informally using the Persona and the Game Play patterns from the paper]

ChatGpt:

Me: Guess the Pattern [I started with the multiple-choice quiz because I think it’s much easier than the other kind of exercises in the game.]

ChatGpt:

Me: b

ChatGpt:

ChatGpt gave me feedback about my answer and explained a bit why it was right. Then it asked me a new question.

For the sake of brevity, I’ll skip a big part of my retrieval practice, and jump to a moment where, after having done several multiple-choice quizzes, I changed to a different kind of exercise that I considered a bit more challenging:

ChatGpt:

Me: Fix the Prompt (remind me the mechanics of the quest, at the beginning, please) [I choose the Fix the Prompt challenge, I also ask ChatGpt to remind its mechanics because I had forgotten them after a lot of Guess the Pattern exercises.]

ChatGpt:

Me: [After a while, because, at least for me, analyzing and creating is much harder than the pattern matching required in a multiple-choice quiz.]

ChatGpt:

Notice how ChatGpt’s feedback was much more detailed in this last exercise. It told me that my prompt worked and that the patterns that I was trying to use were there, and how explicit they were (which is where the prompt could have been better). Then, it suggested an improved version of my prompt which is great feedback for my learning. Finally, it prompted me to keep on playing.

Conclusions.

In this post, we’ve shared a bit of our journey exploring prompt engineering, demonstrating a practical application of this technique. It began with insights from a Coursera course and a key research paper that introduced us to several useful prompt patterns which provide structured approaches for enhancing interactions with AI models.

To deepen our understanding of these concepts, we turned to retrieval practice, a proven learning technique that involves actively recalling information. We decided to put our incipient knowledge about prompt patterns to practical use by working with ChatGPT to create an interactive learning game, which allowed us to both apply and reinforce what we had learned about prompt patterns.

We showed you part of the interactive exercises that ChatGPT prompted us to solve. Through those exercises, we progressed from basic quizzes to more challenging exercises, with ChatGPT providing us valuable feedback to deepen our understanding at each step.

We think that this application of the Persona and Game Play patterns might be used for enhancing your learning of many different topics. We encourage you to try them. We’d love to hear about your experiences!

References.

A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, Jules White.
Prompt Engineering for ChatGPT course materials, Jules White.
Accelerate Your Learning with ChatGPT course materials, Jules White and Barbara Oakley.
Retrieval Practice.
Prompt Engineering Guide

Notes.

[1] Use this prompt to ask to some generative AI tool about the course:

What is the course “Accelerate Your Learning with ChatGPT” by Barbara Oakley and Jules White about?

Mejorar nuestros rojos

2025-07-10T06:00:00+00:00

Este post es una mejora, actualización y traducción del post original en inglés: Improve your reds.

“Mejorar nuestros rojos” es un sencillo consejo que dan Steve Freeman y Nat Pryce en su maravilloso libro Growing Object-Oriented Software, Guided by Tests.

Se trata de una pequeña variación del ciclo de TDD en la que observamos los mensajes de error que obtenemos cuando un test falla y nos preguntamos si la información que nos da haría más sencillo diagnosticar el origen del problema en caso de que ese error apareciera en el futuro como un error de regresión. Si la respuesta es que no, deberíamos mejorar el mensaje de error antes de hacer que el test pase a verde.

De Growing Object-Oriented Software de Nat Pryce y Steve Freeman.

Invertir un poquito de tiempo en mejorar nuestros rojos es una manera muy sencilla de aumentar nuestra productividad futura y la de nuestros compañeros. En caso de que se produzca ese error de regresión, mejorar nuestros rojos nos ayudará mucho porque entre más claro sea el mensaje de error más contexto tendremos para poder arreglar el problema eficientemente.

Además en el momento en que estamos haciendo TDD es cuando más contexto tenemos para poder crear un buen mensaje de error porque el problema está aún fresco en nuestra cabeza. A lo que se suma que, en la mayoría de ocasiones, mejorar nuestros rojos sólo requiere un pequeño esfuerzo adicional.

Esta práctica no es solamente aplicable en el contexto de TDD. También es muy interesante aplicarla cuando se está testeando un código a posteriori a partir de su especificación (specification-based testing), o cuando estamos caracterizando un código legacy (characterization testing).

Como simple demostración de su aplicación, mostraremos un ejemplo escrito en Java.

Fíjense en la siguiente aserción y el mensaje de error que obtenemos cuando falla:

assertThat(new Fraction(1,2).add(1), is(new Fraction(3,2)));

java.lang.AssertionError:
Expected: is <Fraction@2d8e8c3a>
 	but: was <Fraction@2d8e84b8>

¿Qué está fallando? ¿Creen que este mensaje de error nos ayudará en el futuro a diagnosticar qué está pasando?

La respuesta es claramente que no.

Pero con muy poco esfuerzo podemos añadir un poquito de código que puede aclarar muchísimo el mensaje de error. En este caso bastaría con implementar el método toString() en la clase Fraction (que de hecho muchos IDEs pueden generar automáticamente).

@Override
public String toString() {
  return "Fraction{" +
	"numerator=" + numerator +
	", denominator=" + denominator +
	'}';
}

Ahora el mensaje de error que obtenemos para el fallo anterior sería:

java.lang.AssertionError:
Expected: is <Fraction{numerator=3, denominator=2}>
 	but: was <Fraction{numerator=1, denominator=2}>

Este mensaje de error es muchísimo más claro que el anterior y nos ayudará a ser más efectivos si, o cuando, este error vuelva a ocurrir en el futuro.

Aclarar los mensajes de error nos ayuda incluso mientras hacemos TDD (o testing a posteriori) porque nos puede confirmar que el rojo que estábamos obteniendo es justo el que esperábamos, es decir, que tiene la causa que esperábamos y no otra. Si no hacemos esto corremos el riesgo de “programar por coincidencia”^[1].

Esta práctica te puede ser útil incluso si le pides a una IA que escriba los tests por ti, ya que te da otro criterio para evaluar los tests que la IA genera, y una manera sencilla de mejorarlos para que le sean más útiles a las personas que tengan que trabajar en el futuro con ellos.

No desaprovechemos estas mejoras de productividad que podemos obtener con muy poco esfuerzo. Introduzcamos este pequeño hábito en nuestra práctica y ¡empecemos a mejorar nuestros rojos!

Agradecimientos.

Gracias a Fran Reyes por revisar la actualización en castellano de este post.

Notas.

[1] Programming by Coincidence es el título de uno de los topics que se tratan en el libro The Pragmatic Programmer (topic 31 en la primera edición y topic 38 en la edición del veinte aniversario). Textualmente, los autores dicen: “We should avoid programming by coincidence—relying on luck and accidental successes— in favor of programming deliberately”.

Experiencia en la Pamplona Software Crafters 2025

2025-07-07T05:00:00+00:00

El pasado 26 y 27 de junio mi compañero Toño y yo estuvimos en la octava edición de la Pamplona Software Crafters, un evento que reúne a personas interesadas en desarrollar software con éxito.

Nuestra experiencia en el evento fue maravillosa: temas, conversaciones y gente interesantes, un espacio increíble, un ambiente acogedor y una comida excelente.

El evento tiene una parte de charlas preestablecidas pero también cuenta con un Open Space, de manera que parte del contenido del evento está abierto. Yo me animé a presentar dos propuestas en el Open Space y que, por suerte, salieron elegidas.

La primera propuesta que presenté se tituló “Una ayuda para trabajar con Historias de Usuario”. En ella compartí una pequeña guía visual diseñada para ayudar a formular preguntas adecuadas según el momento en que se encuentre la historia de usuario. Esta guía relaciona el uso de INVEST, como criterio para evaluar buenas historias de usuario, y con las técnicas de splitting que nos ayudan a descomponer de forma efectiva.

Escribimos sobre parte de lo que hablé en nuestro post ¿Tamaño y nivel de detalle adecuados para una historia de usuario?. En breve publicaremos un segundo post que completa lo que expusimos en la conferencia y que creemos puede ser útil para aclarar el proceso de refinamiento de las historias de usuario.

La segunda propuesta, titulada “Priorizar deuda técnica”, estuvo centrada en explorar diferentes técnicas que pueden facilitar nuestra toma de decisiones cuando tenemos que priorizar deuda técnica, y que forman parte de nuestro curso Cambiando Legacy.

Una de las técnicas consiste en analizar la evolución del sistema a partir del historial de cambios del repositorio de control de versiones. Esto nos permite tener una visión más dinámica y contextual de qué partes de nuestra deuda técnica nos afectan más, y así nos ayudan a priorizarla. Además, este tipo de análisis, conocidos como behavioral code analysis, nos ayudan a identificar patrones sobre cómo los desarrolladores interactúan con su base de código. Herramientas como Code Maat o CodeScene nos permiten realizar este tipo de análisis, y pueden ser un grán complemento a la hora de priorizar la deuda técnica, e incluso de priorizar historias de usuario.

Quiero aprovechar para agradecer a todos los asistentes la generosidad de sus aportaciones. También quiero darle las gracias, en especial, a mi compañero Toño por su apoyo durante toda la conferencia, que facilitó mucho que pudiera contribuir al contenido del evento.

Para finalizar, quiero agradecer a los compañeros de 540 su labor como organizadores de la Pamplona Software Crafter. Hacen un trabajo excelente año tras año y, aunque quizás de manera algo diferente, estoy seguro de que seguirán haciéndolo en el futuro.

Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness

2025-07-03T05:30:00+00:00

Introduction.

In our previous post, The class is not the unit in the London school style of TDD, we talked about the distinction that the authors of the GOOS book make between the peers (real collaborators^[1]) and the internals of an object, and how this distinction was crucial for the maintainability of unit tests.

We commented how in the tests we write, we should only rely on test doubles to simulate the peers of an object because they align with the behaviours (roles, responsibilities^[2]) that the behaviour under test directly depends on, not the classes it depends on. This practice is consistent with the recommendation: “mock roles, not objects”^[3]. This helps us focus on testing behaviour rather than implementation details.

We also commented that test doubles should not simulate internal objects (any collaborator that is not a peer of the object under test), as they represent implementation details. Using test doubles for them can result in tests that are tightly coupled to structure rather than behaviour.

So, in order to reduce the coupling of our tests to implementation details, it’s crucial that we correctly identify the peers of an object.

Finally, we commented about the object peer stereotypes which are heuristics presented by the GOOS authors to help us think about our design and identify peers.

In this post, we’ll discuss different heuristics that we may apply to detect the peers of an object, or, in other words, to determine the boundaries of the unit under test. We’ll also examine the relationships between them.^[4].

Heuristics to determine the boundaries of the unit under test.

Heuristic 1: Object peer stereotypes.

According to the GOOS book an object’s peers are cohesive objects^[5] that can be loosely categorized into three types of relationship:

Dependencies: “services that the object needs from its environment so that it can fulfill its responsibilities. The object cannot function without these services. It should not be possible to create the object without them.”
Notifications: “objects that need to be kept up to date with the object’s activity. The object will notify interested peers whenever it changes state or performs a significant action. Notifications are “fire and forget” (the object neither knows nor cares which peers are listening).”
Adjustments: “objects that tweak or adapt the object’s behaviour to the needs of the system. This includes policy objects that make decisions on the object’s behalf (think Strategy Pattern), and component parts of the object if it’s a composite.”

These peer stereotypes should be considered as heuristics to help us think about our design, not as hard rules.

They help us define the unit’s boundaries because dependencies, notifications and adjustments should be outside the unit.

Next, we will introduce two more general heuristics that produce coarser-grained units and explain how these heuristics relate to one of the object peer stereotypes: dependencies.

Heuristic 2: FIRS-ness.

The FIRS properties (Fast, Isolated, Repeatable, Self-validating),^[6] provide an interesting guideline for delineating the boundaries of a unit.

According to this idea, any code that adheres to the FIRS properties (i.e., exhibits FIRS-ness) belongs within the unit, while any code that violates any of these properties is an awkward collaboration (a dependency that impairs testability), and should be pushed outside the unit.

We can push FIRS-violating code (i.e., awkward collaborations) outside the unit by applying the Dependency Inversion Principle (DIP). This allows us to control how the unit depends on the awkward dependencies, and enables the use of test doubles in our test to simulate the behaviour of the awkward dependencies, thereby avoiding the testability problems^[7] (i.e., FIRS violations) they introduce.

Heuristic 3: Detecting effects.

Another guideline to determine unit boundaries is inspired by the separation of effectful^[8] and non-effectful (pure) code in functional programming. From this perspective, unit boundaries emerge “wherever an effect needs to be performed”.

If state mutation isn’t considered an effect, the unit boundaries defined using the FIRS-ness concept and the isolating-non-effectful code guideline would mostly align. This isn’t surprising, as FIRS violations are usually caused by effects (except in the case of really slow computations).

So far, we’ve looked at three heuristics that lead us to unit testable designs.

We already commented that the unit boundaries defined using the FIRS-ness concept and the isolating-non-effectful code guideline would mostly align because FIRS violations are usually caused by effects.

Furthermore, we believe that the unit boundaries, derived from applying the FIRS-ness concept or detecting effects, closely align with those identified when using the “dependencies” peer stereotype. Remember that this stereotype is defined as “”services an object needs from its environment to fulfill its responsibilities”.

Additionally, these unit boundaries align with those in the classic style of TDD, where test doubles are primarily used as isolation tools to avoid effects or FIRS violations in tests.

Notice that we have focused on the “dependencies” peer stereotype as the heuristic that defines unit boundaries similar to those derived from applying the FIRS-ness and detecting effects heuristics. Later in this post, we will explore how the two other object peer stereotypes, adjustments and notifications, contribute to achieving finer-grained units and more maintainable tests.

FIRS-ness and detecting effects heuristics will delineate boundaries where our application is testable independently of its context, making them a useful starting point for defining the ports of our application. Where they fall short, though, is in expressing the ports’ interfaces in terms of the application, using only these two heuristics, we could end up with port interfaces that are not aligned with the application’s domain language^[9].

In contrast, using the dependencies peer stereotype provides an advantage over the previous two heuristics by leading to better-designed port interfaces. Recall that this stereotype is defined as “services an object needs from its environment to fulfill its responsibilities”. As a result, the port interfaces created using this approach align more closely with the ports & adapters pattern because they will reflect the language and concepts defined by the application itself.

Moreover, we can also apply the other two other object peer stereotypes, adjustments and notifications, to design finer-grained, context-independent units. This approach may result in unit boundaries that align with those produced by a generalization of the ports & adapters pattern (remember that this pattern only applies at the application boundaries). Alistair Cockburn recently referred to this generalization as the Component + Strategy pattern.

What heuristics do we usually apply to determine the boundaries of the unit under test?

All of them.

In the context of retrofitting tests into legacy code, we focus primarily on detecting *effects** and FIRS-ness violations to determine where to introduce seams, while keeping in mind that the interfaces coupled to the resulting tests are likely too low-level and not well-suited for the application, suffering from the Mimic Adapter antipattern ^[10].

Once the tests are in place, we will refactor toward more cohesive and higher-level interfaces, using the object peer stereotypes and the Component + Strategy pattern as guiding principles to improve modularity and design clarity.

When doing TDD, identifying the suitable unit boundaries and interfaces can be more challenging because we must infer them from the requirements. In this case, we use all three heuristics to determine the boundaries and interfaces, and produce a testable design.

We identify awkward collaborations by detecting effects or FIRS-ness violations in the specification. Additionally, we use object peer stereotypes, especially the dependencies peer stereotype, to define interfaces in terms of the unit we are test-driving.

What about the two other peer stereotypes: “notifications” and “adjustments or policies”?

So far we have only talked about using the dependencies peer stereotype to delimit the boundaries of the unit under test.

There are two other object peer stereotypes, notifications and adjustments, what about them?

In the following sections, we’ll see how these two other object peer stereotypes can further separate concerns and keep cohesion, leading to finer-grained units and more maintainable code and tests.

“Adjustments” peer stereotype.

When variants for some part of an object’s behaviour exist from the outset, or when a part of an object’s behavior begins to evolve at a different pace than the rest, there are various ways to adjust the code to accommodate these behavioral variations.

Some available options are the parametric option, the polymorphic option and the compositional option.

Not all options have the same benefits and liabilities. We think that the compositional option one is usually the best suited in object-oriented code.^[11].

If we choose to add these variations through composition, we need to encapsulate it first in a separate abstraction to maintain the object’s cohesion. This new abstraction would be an adjustment. In this way adjustments can be used to tweak or adapt the object’s behaviour to the needs of the system by using composition.

To achieve this separation, we apply the dependency inversion principle, to ensure the object depends on the new abstraction rather than a specific implementation of it. We then use dependency injection to decide which concrete implementation of the adjustment we want to use.

The resulting object’s code will be protected from changes in the concrete adjustments^[12].

Furthermore, separating adjustments from the object not only results in better design but also enables us to write more maintainable tests.

On one hand, we can write tests focused solely on the object’s core behavior by using test doubles to simulate any adjustments. This approach ensures the object is tested independently of concrete implementations of its adjustments.

Then, we can write separate tests that check the behaviour of each concrete variant of the adjustment.

This testing approach makes the object’s tests more focused and maintainable. By decoupling them from specific adjustments, we ensure they remain unaffected by changes in or additions of new adjustment implementations.

“Notifications” peer stereotype.

Sometimes there are secondary behaviours associated with an object’s state changes or significant actions. Adding these secondary behaviors directly to the object violates the single responsibility principle (SRP) and introduces temporal coupling^[13] between the object’s core behavior and its associated secondary behaviours.

To maintain SRP, the associated secondary behaviors can be encapsulated in separate collaborators.

However, now the object becomes tightly coupled to all those collaborators. We haven’t removed the temporal coupling.

This tightly coupled design introduces significant difficulties in development, maintenance, and testing. Each time a new secondary behavior is added, the object and its tests must be modified, increasing the risk of bugs and making the codebase more expensive to maintain.

Furthermore, this kind of design often results in brittle tests, which break frequently as the system evolves. This brittleness is commonly blamed on test doubles, instead of recognizing the underlying design flaws^[14]. We should instead “listen to our tests”^[15] and improve the design flaws using notifications.

Notifications act as a decoupling mechanism, preventing temporal coupling between the object’s behavior and the secondary behaviors encapsulated in its collaborators.

Through notifications the object merely signals interested peers (if any) whenever it changes state or performs a significant action.

These notifications are “fire and forget” commands^[16], i.e., the object neither knows nor cares which peers might be listening. This ensures loose coupling between components, making the design much more flexible and adaptable to change.

Once notifications are in place, we should avoid checking the object’s behaviour along with all its associated secondary behaviours.

The reason is that including associated secondary behaviors in the object’s tests would require creating test doubles for both the peers of the object and the peers of the notified collaborators, resulting in complex test setups that are difficult to maintain. This difficulty increases as the number of secondary behaviors grows.

Instead, we can both simplify our tests and avoid the brittleness described earlier by taking advantage of notifications.

First, we write tests solely focused on verifying that the object’s behaviour correctly triggers the appropriate notifications. We use test doubles^[17] to simulate the notifications in these tests.

Next, we write separate tests to confirm that a notification triggers the desired secondary behaviors in its listeners. These tests are decoupled from the object that produces the notifications.

This approach makes the object’s tests more focused and maintainable because it decouples them from changes or additions to associated secondary behaviors.

Summary.

This post explores three different heuristics for defining unit boundaries that can be applied both when retrofitting tests in legacy code and when doing TDD: GOOS book’s object peer stereotypes, FIRS-ness and detecting effects.

We explore how these three different approaches often lead to similar unit boundaries, how they can complement one another. Boundaries identified through FIRS-ness or detecting effects often are very similar to the ones derived from the “dependencies” peer stereotype.

We also highlight that the advantage of the “dependencies” peer stereotype is its focus on what “the object needs”. This focus leads to interfaces expressed in the language of their client.

Additionally, we explain how these heuristics can aid in defining application boundaries, drawing a connection with the Ports & Adapters pattern. Again the “dependencies” peer stereotype’s emphasis on the object’s explicit needs results in better interfaces, helping prevent the mimic adapter antipattern.

Finally, we see how the adjustments and notifications peer stereotypes, both reduce coupling, improve cohesion, and result in more maintainable and focused test suites.

In future posts, we’ll discuss other techniques for detecting peers that are based on detecting test smells, leveraging domain knowledge, or design patterns.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

Acknowledgements.

I’d like to thank Fran Reyes, Emmanuel Valverde, Fran Iglesias, Marabesi Matheus, Manu Tordesillas and Alfredo Casado for giving me feedback about several drafts of this post.

Finally, I’d also like to thank Petra Nesti for the photo.

References.

Notes.

[1] Any object that helps a given object to fulfil its responsibilities is called a collaborator. It seems that this etymology comes from Class-responsibility-collaboration cards originally proposed by Ward Cunningham and Kent Beck as a teaching tool in their paper A Laboratory For Teaching Object-Oriented Thinking.

In that paper, they write “the last dimension we use in characterizing object designs is the collaborators of an object. We name as collaborators objects which will send or be sent messages in the course of satisfying responsibilities.”

In our previous article, The class is not the unit in the London school style of TDD, we explained that according to the GOOS book the collaborators of an object belong to one of two categories: peers (real collaborators) and internals (implementation details).

[2] The OO style described in the GOOS book is influenced by Rebecca Wirfs-Brock’s Responsibility-driven design.

[3] From Mock roles, not objects by Steve Freeman, Nat Pryce, Tim Mackinnon and Joe Walnes.

[4] This post originated from a response to a comment on the post The class is not the unit in the London school style of TDD.

[5] Following the single responsibility principle, i.e., objects that are cohesive. See section Object Peer Stereotypes in chapter 6, Object-Oriented Style, of the GOOS book.

[6] In our post “Isolated” test means something very different to different people!, we explain what each of the FIRS properties means for us.

We also comment about the origin and history of the FIRST acronym, citing original sources.

Finally, we explain how we interpret isolated differently than the authors of the the FIRST acronym, our definition is more aligned with Beck’s interpretation of isolated.

[7] Isolated violations can also be avoided by using fixtures, but this may lead to slower tests that violate Fast.

With the advent of technologies such as Testcontainers, tests that were traditionally classified as integration tests can now adhere to the FIRS properties. Using Testcontainers helps maintain isolation, ensuring the tests run independently and are repeatable regardless of the developer’s local setup.

[8] Effectful code performs effects, but what are effects? Let’s try to informally explain it.

Any code that uses any input that isn’t in its argument list (or is injected through its constructor in the case of objects), or does anything that isn’t part of its return value is considered effectful, and those hidden inputs and outputs are effects.

Most people call the hidden inputs and outputs side-effects, but some people use the term side-effect only for the hidden outputs, and the term side-causes for the hidden inputs (like Kris Jenkins in his post What Is Functional Programming?) to highlight their different nature.

According to that distinction, a side-effect is something a program does to its environment, and a side-cause is something a program requires from its environment.

Effectful code is much harder to test and understand than pure code.

[9] According to Alistair Cockburn, port interfaces should be expressed in the language of the application:

“Every interaction between the app and the outside world happens at a port interface, using the interface language the app itself defines” (in page 12 of the preview edition of his book Hexagonal Architecture Explained).

We observe that the interfaces that arise from looking for FIRS violations or detecting effects tend to have more risk of presenting a too low level of abstraction, falling in the mimic adapter antipattern. The object peer stereotypes help in alleviating that risk.

[10] Since dependency-breaking techniques carry some risk as they are applied without tests, we try to reduce this risk by introducing very thin layers that isolate the minimum possible amount of code to get isolation. Therefore, they will most likely be at a lower level of abstraction than what our application requires and will not align with the terms of our application. They are mimic adapters which, in this context, is not an antipattern, it’s exactly what we need to reduce risks and introduce tests.

However, if, once we have tests in place, we don’t refactor these low level interfaces, we may face excessive coupling problems in our tests (see our post An example of wrong port design detection and refinement).

[11] In the chapter Deriving Strategy Pattern of his book Flexible, Reliable Software Using Patterns and Agile Development, Henrik Bærbak Christensen describes and analyses in depth four options, which he calls proposals, to accommodate an object-oriented design to this kind of behavioral variations: source tree copy proposal, parametric proposal, polymorphic proposal and compositional proposal.

The compositional proposal has many interesting benefits and a few liabilities. Read the whole analysis there.

[12] This has the interesting property of changing behavior by adding new production code instead of modifying existing one. This property is characterized as Change by Addition (in Henrik Bærbak Christensen book), Open-Closed Principle, or Protected Variations.

I prefer the last description.

[13] “When two actions are bundled together into one module just because they happen to occur at the same time.” See the entry about Coupling in Wikipedia.

[14] Another example of blaming a tool or technique rather than our design or how we use the tool or technique.

[15] By interpreting difficulties in testing as feedback signaling that our design might need improvement.

Have a look at this interesting series of posts about listening to the tests by Steve Freeman. It’s a raw version of the content that you’ll find in chapter 20, Listening to the tests, of their book.

In fact, according to Nat Pryce mocks were designed as a feedback tool for designing OO code following the ‘Tell, Don’t Ask’ principle. You can read more about this in this conversation in the Growing Object-Oriented Software Google Group.

The feedback usually comes in the form of “pain” 😅.

[16] See Command Query Separation.

[17] Since notifications are commands, we may use either mocks, fakes or spies.

¿Tamaño y nivel de detalle adecuados para una historia de usuario?

2025-06-24T00:00:00+00:00

Introdución.

Uno de los aspectos que genera más confusión a la hora de entender las historias de usuarios es su tamaño. Esto se debe a que no hay un único tamaño adecuado para una historia de usuario, sino que este depende de la distancia en el tiempo al momento de desarrollar la historia.

El tamaño de una historia de usuario es proporcional a la cantidad de funcionalidad que abarca (alcance), y por tanto también es proporcional a la cantidad de riesgo e incertidumbre que contiene.

Otro aspecto confuso es el nivel de detalle de la historia de usuario. Este está relacionado con lo precisa que necesita ser la historia de usuario, ya que los detalles acotan y aclaran los límites de la historia. Aquí ocurre un fenómeno similar al que comentamos para el tamaño, es decir, no existe un único nivel de detalle adecuado para una historia de usuario, sino que este cambiará según nos acercamos al momento de desarrollar una historia.

En este post vamos a intentar arrojar un poco de luz sobre estos dos aspectos de las historias de usuario,

¿Cómo deberían variar el tamaño y el nivel de detalle adecuados de una historia de usuario?

Según nos acercamos al momento de desarrollar la historia, nos interesa que ocurran los siguientes fenómenos:

Que su tamaño disminuya.
Que su nivel de detalle aumente.

Tamaño y nivel de detalle adecuados frente al tiempo, donde el tamaño de los cuadros ilustra el tamaño de las historias

Relaciones entre la evolución del tamaño y el nivel de detalle.

Existe una curiosa relación entre el tamaño y el nivel de detalle.

Si miramos con atención como acotamos el alcance de una historia de usuario^[1], podemos observar que detallar la historia siempre es un paso previo para reducir el tamaño de la historia.

Vamos a poner un ejemplo, dada esta historia de usuario:

Quiero ordenar productos.

Si detallamos lo que significa ordenar, nos quedaría:

Quiero ordenar productos

* Por fecha de compra.

* Por coste del producto.

que, obviamente, tiene el mismo tamaño pero más nivel de detalle.

Si decidimos partir esta historia en dos, nos podrían salir las siguientes historias:

Quiero ordenar productos por su fecha de compra.

Quiero ordenar productos por su coste.

Ahora cada una tiene menor tamaño pero conservando el nivel de detalle de la inicial. Por tanto, vemos que existe una relación entre detallar una historia de usuario y reducir su tamaño, ya sea partiéndola o no^[2].

¿Por qué dependiendo del momento el tamaño y el nivel de detalle adecuados varían?

Hay al menos dos momentos del tiempo dónde debería cambiar el tamaño de las historias para que sea eficiente trabajar con ellas.

El primer momento, T_r, ocurre poco antes de presentar una historia al equipo en, la que suele denominarse, sesión de refinamiento. El segundo momento es poco antes de T_d. T_d, como indica la gráfica, es el momento en que desarrollamos la historia.

Idealmente no debería pasar demasiado tiempo entre T_r y T_d.

Analicemos cada uno de ellos.

Nivel de detalle adecuado dependiendo del momento.

Desde su creación, (T₀), hasta antes del momento (T_r).

Detallamos poco principalmente porque queremos evitar tanto malgastar tiempo (waste) como descartar posibles opciones interesantes.

Hay varias formas en las que podemos incurrir en waste. En este caso concreto, se podrían presentar dos formas de waste:

Trabajo innecesario. Cuanto más alejados estamos de T_r mayor es la incertidumbre sobre qué historias de usuario acabarán desarrollándose o no, por tanto, si invertimos mucho tiempo en detallarla en este momento, la probabilidad de desperdiciar tiempo y energía en un trabajo innecesario es alta^[3]. La inversión en detallar se materializaría como trabajo innecesario si al final no se acaba desarrollando la historia^[4].
Recuperación de contexto como forma de retrabajo. Si ha pasado mucho tiempo desde la última vez que se trabajó en la historia, necesitamos volver a hacer un esfuerzo para recordar qué aspectos se discutieron tiempo atrás^[5].

En cuanto a mantener las opciones abiertas, nos referimos a no tomar decisiones que puedan descartar opciones antes de tener suficiente información, ya que si las tomamos prematuramente existe una mayor probabilidad de que estas sean erróneas ^[6]. Por tanto, para mantener nuestras opciones abiertas lo mejor es no decidir hasta el último momento responsable.

En T_r.

En este caso el detalle que vamos a añadir tiene como finalidad hacer la historia más pequeña. Hablaremos sobre esto en la sección de relacionada con el tamaño adecuado de una historia de usuario.

Poco antes de T_d.

Finalmente, en este momento necesitamos detallar mucho más porque queremos eliminar cualquier posible ambigüedad en las historias de usuarios para desarrollarlas sin malentendidos y suposiciones erróneas.

Los criterios de aceptación^[7] y los ejemplos sirven para detallar mejor una historia de usuario y aumentar su claridad.

La razón por la que queremos ganar claridad es para asegurar uno de los aspectos más importantes de las historias de usuario, la confirmación^[8]. Es decir, queremos ser capaces de determinar cuándo una historia de usuario está acabada y funcionando como se esperaba.

El uso de ejemplos en las historias de usuario juega un papel muy importante porque clarifican los criterios de aceptación que normalmente están en un nivel de abstracción mayor.

Por ejemplo, dada una historia relacionada con el registro de usuarios en una site internacional de venta de bebidas con bajo contenido alcohólico podríamos tener el siguiente criterio de aceptación:

Debe ser mayor de edad.

Si agregamos unos cuantos ejemplos podríamos aclarar la complejidad que ese criterio de aceptación podría estar ocultado para algunos de los participantes en la sesión de refinamiento.

Dado que resido en Japón y tengo 18, cuando intento registrarme, me indica que soy menor de edad y no me deja finalizar el registro.

Dado que resido en Alemania, tengo 18 y he rellenado correctamente los otros datos del formulario, cuando finalizó el registro, veo un mensaje de agradecimiento por el registro.

Al escribir ejemplos podrían emerger varios escenarios. Por tanto, los ejemplos no sólo clarifican, sino también pueden ayudar a preguntarnos sobre otros escenarios posibles^[9].

Siguiendo con el caso expuesto, podríamos preguntarnos: ¿Qué escenario no me permite registrarme si resido en Alemania? ¿Cuántos países tenemos que tener en cuenta?.

Es importante además que todas las partes involucradas en las historias de usuario (Producto, Devs, QAs, etc) estén de acuerdo sobre los criterios de aceptación. Esta claridad compartida ayuda a que todos los participantes comprendan mejor la situación y reduce la posibilidad de que se produzcan diferentes interpretaciones sobre lo que cada uno espera de la historia de usuario.

Tamaño adecuado dependiendo del momento^[10].

Desde su creación, (T₀), hasta antes del momento (T_r).

Las historias pueden tener un tamaño muy grande, y esto es lo adecuado, ya que nos interesa que su tamaño sea grande porque, como explicamos más arriba, aún no tenemos información suficiente para reducir su tamaño.

Además existe mucha incertidumbre sobre qué historias acabarán desarrollándose o no, y por tanto, la probabilidad de desperdiciar tiempo y energía intentando reducir su tamaño es muy alta.

Por ejemplo podríamos plantear una historia de usuario como la siguiente:

Marketing necesita informes para evaluar el impacto de las acciones realizadas.

Aunque esta historia abarca mucha funcionalidad, al menos deja abierta los tipos de informes que podrían aportar más valor. Así, si más tarde cambian las necesidades o se descubren otros informes que aportan más valor, ese cambio de decisión no afecta a la historia.

De hecho, si, de antemano, reducimos todas las historias lo más posible acabaremos en lo que se conoce como el “user story card hell”^[11].

En T_r.

En este momento se da una tensión entre dos necesidades.

Por un lado queremos reducir el tamaño de la historia de usuario para que las reuniones con el equipo sean lo más efectivas posible, pero, no queremos reducirlo demasiado para no cerrar opciones antes de examinarla en la reunión de refinamiento.

El riesgo de reducir demasiado el tamaño de la historia de usuario antes de la reunión de refinamiento es que podríamos crear un efecto de framing en el equipo, que reduciría su capacidad para proponer alternativas más creativas o económicamente más interesantes.

Acertar con el tamaño adecuado en el momento, T_r, es a veces complicado porque hay que equilibrar los dos objetivos en tensión, conseguir una reunión eficiente y no cerrar demasiado las opciones. Nuestro consejo es no preocuparse en exceso para no caer en parálisis por análisis. Con el tiempo iremos aprendiendo a equilibrar ambos objetivos.

Por ejemplo, la anterior historia podría convertirse en la siguiente:

Como usuario del Departamento de Marketing, quiero generar informes de los cambios de planes de nuestros suscriptores para evaluar el impacto de las campañas.

Lo que reduciría el tamaño de la historia de usuario pero dejando aún algunas opciones abiertas.

Poco antes de T_d.

En este momento, el contexto cambia de manera radical. Ahora lo que buscamos es que las historias sean lo más pequeñas posibles.

Los motivos por los que tratamos de reducir las historias de usuario lo más posible son:

Entregar valor lo antes posible, de forma que el usuario pueda obtener beneficio de una parte lo antes posible. En este sentido las historias de usuario representarían posibles incrementos de valor.
Reducir riesgo. Con incrementos pequeños de funcionalidad se reduce el riesgo de desviarnos de lo que espera el usuario, al tiempo, que se reduce el riesgo de incurrir en retrabajo y el de introducir errores.
Ciclos de feedback cortos. Los incrementos pequeños de funcionalidad nos permiten experimentar, aprender, ajustar nuestras prioridades y tomar mejores decisiones.

Siguiendo con el ejemplo anterior, la historia puede convertirse en la siguiente:

Como usuario del Departamento de Marketing, quiero generar un informe de los aumentos de planes contratados en los últimos 30 días para evaluar el impacto de las campañas mensuales”.

* Mostrar fecha del informe.

* Mostrar la cantidad total de planes que han aumentado.

En este ejemplo se reduce el tamaño de la historia al detallar que sólo nos preocupa cuándo hay un aumento de planes contratados (y no un descenso), la fecha del informe y la cantidad total de planes contratados en ese periodo.

En futuras versiones, podríamos plantearnos refinar este aspecto pero ahora Marketing ya está obteniendo al menos un informe que le proporcionará una buena parte del valor que inicialmente necesitaba.

Conclusión.

Hemos visto cómo tenemos que ajustar el tamaño y nivel de detalle de las historias de usuario a medida que nos vamos acercando al momento en que se desarrolla una historia.

Desde su creación, (T₀), hasta antes del momento (T_r), cuando hay mayor incertidumbre, las historias son más grandes y menos detalladas, lo que permite mantener opciones abiertas y evitar esfuerzos innecesarios.

Poco antes de una reunión de refinamiento (T_r), las historias que vamos a presentar en ella deben ajustarse en tamaño y detalle lo suficiente como para fomentar discusiones efectivas, pero evitando cerrar nuestras opciones prematuramente.

Finalmente, al llegar al momento del desarrollo (T_d), las historias deben ser pequeñas y bastante detalladas para eliminar ambigüedades, reducir riesgos y permitir entregas incrementales de valor. También vimos una relación importante, que detallar una historia de usuario es lo que permite reducir su tamaño, ya que el detalle aclara el alcance y esto facilita dividirla, si fuera necesario, en historias más pequeñas sin perder claridad. En futuros posts seguiremos profundizando en este tema dando heurísticas que pueden ayudarnos a escribir historias de usuario adecuadas para dos de los momentos importantes que hemos comentado en este post: antes de presentar la historia en una una reunión de refinamiento (T_r), y justo antes de empezar a desarrollarla, (T_d).

Serie Historias de Usuario.

Este post es parte de una serie sobre Historias de usuario:

¿Tamaño y nivel de detalle adecuados para una historia de usuario?.
Nuestro flujo de decisión para refinar Historias de Usuario poco antes de empezar a desarrollarla.
Detallando historias de usuario para acotarlas y reducir su ambigüedad.

Agradecimientos.

Nos gustaría darle las gracias a Ivan Samkov por la foto del post.

Notas.

[1] Este paso no tiene porque ser realizado de manera explícita pero es un paso implícito que se produce cuando intentamos hacer la historia más pequeña. Podríamos acabar con una sóla historia y a la vez implícitamente estar descartando otras opciones que podrían estar presentes en la historia inicial.

[2] Sería posible que sólo nos preocupara ordenar por fecha de compra y entonces la historias quedaría directamente como “Quiero ordenar productos por fecha de compra”.

[3] También es posible que haya un cambio de prioridad pero la probabilidad de que esto ocurra es mayor cuanto más alejado estamos de T_d.

[4] Un efecto, que hemos observado, que puede estar escondiendo el posible desperdicio generado, es caer en el sesgo del coste hundido para no tirar a la basura la inversión que ya hemos hecho, aunque haya otra solución mejor.

[5] Es curioso observar que para reducir el problema del olvido, se suele anotar más detalles. Eso provoca que aumente el tiempo invertido en un momento en el que la incertidumbre es mayor y por tanto aumentan las posibilidades de haber hecho trabajo innecesario.

[6] El principio del último momento responsable, También es un problema tomar decisiones de manera tardía porque pueden generar pérdida de oportunidades y retrabajo para terceros.

[7] Algunos autores usan el concepto de condiciones de satisfacción o rules para hablar de los criterios de aceptación por diferentes motivos. Mike Cohn prefiere utilizar condiciones de satisfacción y en Example Mapping se utiliza el concepto de Rules.

[8] Card, Conversation, Confirmation son 3 aspectos esenciales enunciados por Ron Jeffries en su artículo de 2001

[9] Liz Keogh documenta una serie de patrones conversacionales al trabajar con ejemplos que pueden ser muy útiles para explorar los ejemplos en Conversational patterns in BDD.

[10] Si bien existen criterios para juzgar si el tamaño de una historia es adecuado, como por ejemplo INVEST, no todos los criterios son aplicables, o si lo son, no con el mismo peso en cada uno de los momentos, t₀, t_r y t_d. Además, si fuera necesario, hay diversas técnicas para dividir historias de usuario, o, en algunos casos, incluso fusionarlas.

[11] “Story card hell is when you have 300 story cards and you have to keep track of them all” from Beyond Story Cards: Agile Requirements Collaboration.

Usando conjuntamente ApprovalsJs y StrykerJS en WebStorm

2025-06-06T05:30:00+00:00

Introducción.

En un post anterior mostramos como integrar ApprovalsJS con WebStorm.

Para poder aplicar la técnica de Golden Master necesitamos generar nuestro golden master mediante un proceso de muestreo (sampling)^[1].

Una vez tenemos escritos los tests aplicando golden master, (o approval testing que como dijimos en el post anterior, facilita la aplicación de la técnica de Golden Master) debemos evaluar lo bien que estos tests protegen el comportamiento existente contra posibles regresiones.

Para ello usaremos herramientas de cobertura y de mutation testing^[2] que son capaces de detectar posibles debilidades de nuestros tests que nos lleven a refinarlos hasta que consigamos proteger el comportamiento contra regresiones de forma satisfactoria (el significado de “de forma satisfactoria” dependerá tanto del comportamiento como del tipo de aplicación en cuestión).

La siguiente figura resume este proceso de refinamiento:

Refinando los tests de golden master (del material del curso Cambiando Legacy).

Por tanto, es muy recomendable usar herramientas de approval testing y mutation testing de manera conjunta.

En el caso que se aborda en este post necesitábamos aplicar estas técnicas para caracterizar un código escrito en TypeScript.

Como ya describimos en un post anterior usamos ApprovalsJS para escribir nuestros tests de golden master.

Para mutation testing en TypeScript la herramienta que más nos gusta usar es StrykerJS. En este post, veremos cómo configurar estas dos herramientas para que trabajen juntas de manera eficiente, dentro de WebStorm.

El problema.

Como ya explicamos, en un approval test cada vez que se produce una diferencia entre el resultado aprobado (esperado) y el obtenido durante el test, ApprovalsJS lanza una herramienta de comparación visual para que el desarrollador pueda evaluar más fácilmente la discrepancia entre los dos resultados^[3].

Esto, sin embargo, se vuelve un problema cuando usamos la técnica de mutation testing que se basa en introducir mutaciones (básicamente regresiones) deliberadas en el código fuente para comprobar si los tests fallan como se espera.

Una herramienta de mutation testing generará un montón de copias del código introduciendo una mutación en cada copia (el mutante), y luego ejecutará nuestros tests contra cada una de esas copias.

Funcionamiento de una herramienta de mutation testing (del material del curso Cambiando Legacy).

Si los tests fallan al ejecutarlos contra un mutante es que nos protegen contra ese tipo de regresión, si no fallan puede que hayamos descubierto una debilidad en nuestros tests^[4].

Cuando usamos una herramienta de mutation testing, si nuestros tests no son terribles de partida, para la mayoría de los mutantes nuestros tests deberían fallar.

El problema es que, si resulta que el test que falla es un approval test lanzará la herramienta de diff que hayamos configurada y se parará la ejecución hasta que interactuemos con dicha herramienta. Por tanto, el flujo de un approval test de lanzar un diff tool cuando el test falla no es compatible con mutation testing y se convierte en un obstáculo.

Hay que decir que este posible problema ya esta resuelto de entrada cuando hemos usado approval testing junto con mutation testing en Java y .Net, pero, por desgracia, no es así cuando usamos ApprovalsJS y StrykerJS con WebStorm.

Cuando ejecutamos una herramienta de mutation testing debemos evitar que se lance la herramienta de diff cada vez que un test de approval falle nos interesa para que el proceso pueda ejecutarse sin intervención humana.

Nuestra solución.

Para resolver esta incompatibilidad entre mutation testing y approval testing necesitaremos informar de alguna manera al Reporter del contexto en que se están ejecutando los tests, básicamente, saber si estamos usando mutation testing o no.

Consultando en el código fuente de ApprovalsJS la clase GenericDiffReporterBase de la que extendimos para crear nuestro reporter para WebStorm, WebStormReporter, vemos que tiene un método público isReporterAvailable(): boolean que se usa como clausula de guarda en el método canReportOn(fileName: string): boolean de la interfaz Reporter^[5], si isReporterAvailable devuelve false canReportOn también devolverá false, y eso evitará que abra la ventana de la herramienta de diff de WebStorm.

Sabiendo esto sobreescribimos el método isReporterAvailable(): boolean en WebStormReporter:

Para que funcione como queremos sólo nos faltaría setear la variable de entorno de node MUTATION_TESTING a true cada vez que ejecutamos StrykerJS. Esto se puede conseguir utilizando la propiedad "command" del objeto "commandRunner" en el fichero stryker.conf.json, que configura StrykerJS, de la siguiente manera:

Con esta modificación de la configuración de StrykerJS y con el cambio en WebStormReporter que mostramos más arriba se consigue que la herramienta de diff nunca se lance mientras se ejecutan los tests de mutación.

La variable de entorno MUTATION_TESTING sólo existirá mientras dure la ejecución de los tests de mutación, de forma que, si, en cualquier momento, ejecutamos tests que no sean de mutación recuperamos el comportamiento de lanzar la herramienta de diff configurada cada vez que un test de approval falle.

Conclusión.

Utilizando tests de mutación con StrykerJS en WebStorm para intentar refinar unos tests de golden master que usaban ApprovalsJS nos encontramos la sorpresa de que la herramienta de diff se lanzaba cada vez que los tests fallaba, lo cuál ocurría casi para cada uno de los mutantes generados haciendo que en la práctica la ejecución de los tests de mutación dejara de ser automática.

Para resolverlo tuvimos que consultar el código fuente de ApprovalsJS para saber como modificar nuestra implementación de Reporter para WebStorm, y modificar la configuración de StrykerJS para introducir una variable de entorno de Node que informara a nuestro Reporter de que los tests de approval se estaban ejecutando en el contexto de una ejecución de los tests de mutación.

Esperamos que esta solución les pueda servir para no caer en el mismo problema en que caímos nosotros.

Agradecimientos.

Nos gustaría agradecer a las empresas que hasta ahora han confiado en nosotros para ayudar a sus equipos a mejorar cómo trabajan con su código legacy. Ya hemos dado cuatro ediciones del curso Cambiando Legacy que han tenido muy buen feedback y nos han permitido refinar su contenido.

Por último, también nos gustaría darle las gracias a Erik Mclean por la foto del post.

Notas.

[1] Existen diferentes estrategias de sampling para generar nuestro golden master (input y output). Las principales estrategias de sampling son:

a. Faking input & recording output.

b. Generating random input & recording output.

c. Recording production input & output.

Profundizamos en el refinamiento en nuestro curso Cambiando Legacy.

[2] En nuestro blog puedes encontrar otros posts interesantes sobre mutation testing.

[3] En Integrando ApprovalsJS con WebStorm explicamos cómo hicimos para que ApprovalJs usará la herramienta de diff de WebStorm.

[4] No siempre es así, hay mutantes supervivientes (para los que nuestros tests no fallan) que no son relevantes para mejorar los tests, sino que podrían ser debidos, o bien, a código muerto, o bien, a código innecesario. Para profundizar en esta idea lee nuestro post Mutantes relevantes.

[5] Ver el código de isReporterAvailable y canReportOn en la clase GenericDiffReporterBase, y la interface Reporter.

"Isolated" test means something very different to different people!

2025-06-03T05:30:00+00:00

Introduction.

A concept that we find very useful both when we do TDD and when introducing tests into legacy code are the FIRS properties (Fast, Isolated, Repeatable, Self-validating), which are used to describe an ideal unit test. This concept originates from the FIRST acronym, which describes ideal unit tests in the context of TDD, where the T stands for Timely^[1].

This is what we mean by Fast, Isolated, Repeatable and Self-validating tests:

Fast: they should execute so quickly that we never feel the need to delay running them.
Isolated: they should produce the same results regardless of the order in which they are executed. This means they do not depend on one another in any way, whether directly or indirectly.
Repeatable: they should be deterministic, their results should not change if the tested behavior and environment remain unchanged.
Self-validating: they should pass or fail automatically, without requiring human intervention to determine the outcome. This property is essential for enabling test automation.

In the distinct contexts of TDD and retrofitting tests in legacy code, the same FIRS properties fulfill different roles, guiding us in designing testable units in the former and uncovering testability problems in the latter^[2].

When retrofitting tests in legacy code, violations of FIRS properties highlight dependencies that impede testing, referred to as awkward collaborations^[3]. These awkward collaborations point to the dependencies we need to break using dependency-breaking techniques^[4] to enable the introduction of unit tests.

In the case of integration tests, it is sufficient to focus on violations of the Isolated, Repeatable and Self-validating properties. Dependencies that violate the Repeatable and Self-validating properties require dependency-breaking techniques to address them, whereas violations of the Isolated property can often be alternatively resolved through other approaches, such as test-specific fixtures or configuration changes.

In the context of TDD, violations of the FIRS properties are a key heuristic to identify the collaborations that we need to push outside the unit under test. These awkward collaborations will be simulated with test doubles in our unit tests.

Notice that, when doing TDD, identifying awkward collaborations is more challenging because we must infer them from the requirements. In contrast, in legacy code, we can identify them more easily since they are visible in the code and manifest through the testability problems they cause.

Identifying awkward collaborations is, therefore, an important skill for designing testable code. In this sense, FIRS properties serve as a valuable guideline for defining the boundaries of a unit, helping us develop testable code.

It seems “isolated test” means something very different to different people!

If you read the original definition of isolated from Agile in a Flash: F.I.R.S.T. you will notice that it is different from what we expressed in the previous section.

We said that for us isolated meant that “the test should produce the same results regardless of the order in which they are executed. This means they do not depend on one another in any way, whether directly or indirectly”.

In the definition of isolated from Agile in a Flash: F.I.R.S.T., the flash card states:

“Isolated: Failure reasons become obvious.”

Later, in the explanation, they elaborate on what this means (the emphasis in bold was added by us):

Isolated: Tests isolate failures. A developer should never have to reverse-engineer tests or the code being tested to know what went wrong. Each test class name and test method name with the text of the assertion should state exactly what is wrong and where. If a test does not isolate failures, it is best to replace that test with smaller, more-specific tests.

A good unit test has a laser-tight focus on a single effect or decision in the system under test. And that system under test tends to be a single part of a single method on a single class (hence “unit”). Tests must not have any order-of-run dependency. They should pass or fail the same way in suite or when run individually. Each suite should be re-runnable (every minute or so) even if tests are renamed or reordered randomly. Good tests interfere with no other tests in any way. They impose their initial state without aid from other tests. They clean up after themselves.”

Tim Ottinger’s FIRST: an idea that ran away from home summarizes this as:

“Isolated - tests don’t rely upon either other in any way, including indirectly. Each test isolates one failure mode only.”^[5].

For us isolated, in the context of identifying awkward collaborations, means that tests should be isolated from each other, which, in practice, means that they can not share any mutable state or resource. Our definition is less restrictive than Ottinger’s one. We are choosing to consider only one aspect of their definition, that “tests interfere with no other tests in any way”, and not the other one, “tests have a single reason to fail”, (we’ll comment more about this other aspect below).

We think that what we mean by isolated aligns with the definition Kent Beck provides in his book Test Driven Development: By Example. In the section Isolated Test (page 125) of the chapter Test-Driven Development Patterns, he writes:

“How should the running of tests affect one another? Not at all.”

“[…] the main lesson […] tests should be able to ignore one another completely.”

“One convenient implication of isolated tests is that the tests are order independent.”

Moreover, in his more recent work Test Desiderata he defines isolated as:

“tests should return the same results regardless of the order in which they are run”^[6].

Having said that, there is another desirable property for tests in Test Desiderata which is interesting for this discussion, specificity, which Kent Beck explains as:

“Specific: if a test fails, the cause of the failure should be obvious.”

We think that, the second aspect of isolated in Ottinger’s definition, having a single reason to fail, corresponds to the highest possible level of Beck’s specificity. It seems that what Ottinger means by isolated includes two of the desirable properties of tests described by Beck’s Test Desiderata:

the property of returning the same results regardless of the order in which they are run (being isolated).
the property of test failures having an obvious cause” (being specific).

Having a single reason to fail is still a highly desirable property which we also take into account while writing test cases. It can help to compose independent behaviours and to avoid overspecifying some tests^[7].

However, in the context of identifying awkward collaborations, we have found Beck’s definition of isolated to be more useful, in order to avoid the considering-the-class-as-the-unit trap, and to teach the use of test doubles as isolation tools, which is how they are mostly employed in the classic style of TDD.

Summary.

We showed how the FIRS properties can be valuable in both TDD and retrofitting tests in legacy code, guiding developers toward creating more testable and maintainable code.

We explored how the concept of isolated tests differs depending on the author. While Kent Beck’s definition emphasizes independence between tests, ensuring they produce consistent results regardless of execution order, the definition from F.I.R.S.T in Agile in a Flash also states that tests should have a single reason to fail. We believe this intertwines Beck’s definition of isolation with another test property: specificity, with having a single reason to fail representing the highest level of specificity.

We think that, both Beck’s and Ottinger’s definitions of isolated are valuable. However, Beck’s version aligns more closely with what we mean by isolated in the context of identifying awkward collaborations. For us, Beck’s definition has proven especially useful while identifying awkward collaborations, to avoid the trap of considering the class as the unit, and to teach how to use test doubles as isolation tools.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

Acknowledgements.

I’d like to thank Fran Reyes, Emmanuel Valverde Ramos, Fran Iglesias Gómez, Marabesi Matheus and Antonio De La Torre for giving me feedback about several drafts of this post.

Finally, I’d also like to thank imgflip for their Inconceivable Iñigo Montoya Meme Generator.

References.

Notes.

[1] See also Jay Bazuzi’s post “pure unit test” vs. “FIRSTness” to learn more about categorizing tests according to their FIRSness (removing the T) which can be useful when working with legacy code, or when testing after.

[2] We delve into this topic in depth in our TDD training and our Changing Legacy Code training.

[3] See Fowler’s article Mocks Aren’t Stubs to see where the term awkward collaboration comes from.

[4] See our post Classifying dependency-breaking techniques.

[5] Aside from summarizing very well what “Isolated” means to them, FIRST: an idea that ran away from home dives into the history of how the FIRST properties came about and how their meaning has blurred over time. Plus, it includes a list of sources that discuss FIRST, highlighting changes made by each source, like in the telephone game, and noting that some don’t even give credit to the original authors.

It also refers to another article published by Pragmatic Programmers as the origin of the acronym Unit Tests Are FIRST: Fast, Isolated, Repeatable, Self-Verifying, and Timely, which we believe explains FAST better and even includes code examples.

Finally, it explains the value of writing tests first and criticize writing them afterwards.

[6] Ian Cooper, in his talk TDD, where did it all go wrong states that:

“For Kent Beck, [a unit test] is a test that runs in isolation from other tests.”

“[…] NOT to be confused with the classical unit test definition of targeting a module.”

”A lot of issues with TDD is people misunderstanding isolation as class isolation […]”

We talked about this frequent misunderstanding in our post The class is not the unit in the London school style of TDD.

[7] We may write about this in a future post.

Integrando ApprovalsJS con WebStorm

2025-05-16T05:30:00+00:00

Contexto.

En nuestro curso Cambiando Legacy exploramos diferentes maneras de caracterizar código legado. Una de las que explicamos es approval testing.

Approval testing facilita la aplicación de la técnica de Golden Master, aportando una herramienta que nos ayuda con algunos de los pasos más complicados y/o engorrosos de la técnica de Golden Master:

la comparación entre el resultado real y el aprobado (golden master),
la visualización de las diferencias entre ellos (si las hay), y
el proceso de aprobación de un nuevo resultado válido (actualización del golden master).

Flujo de approval testing (del material del curso Cambiando Legacy).

En una edición reciente del curso que tuvo Typescript como lenguaje conductor, utilizamos la librería Approvals JS para demostrar cómo aplicar approval testing^[1].

Approvals JS es la versión para Node de la herramienta Approvals que está disponible en varios lenguajes, siendo probablemente la de Java la más popular y mantenida.

El problema o, más bien, nuestras necesidades.

Aunque también se puede usar Visual Studio Code en el curso, el IDE que utilizamos para nuestras demos es WebStorm porque es el que nosotros solemos usar para desarrollar.

Cuando existe una diferencia entre el resultado real y el resultado aprobado, Approvals JS lanza una diff tool para facilitarnos la detección de las diferencias entre ambos resultados, y así ayudarnos a determinar el origen de dichas diferencias.

Approvals define una abstracción para esta responsabilidad de facilitar la detección de diferencias entre los resultados real y aprobado: el Report^[2]. Dicha abstracción se implementa con adaptadores concretos que utilizan diferentes herramientas de diff.

Approvals JS viene configurado con una lista de Reports que usa de manera priorizada, es decir, empieza por intentar ejecutar el primer Report de la lista, si lo encuentra y todo va bien usa ese, y si no pasa a intentar ejecutar el siguiente de la lista, y así sucesivamente.

En nuestro caso, no nos interesaba utilizar (ni siquiera las teníamos instaladas) ninguna de las herramientas de diff configuradas por defecto, (BeyondCompare, Diffmerge, P4merge, Tortoisemerge, etc.), sino que queríamos usar la propia herramienta de diff de WebStorm para no tener que cambiar de contexto y tener una experiencia de desarrollo más fluida^[3].

El problema es que no existía un Report por defecto para trabajar con Webstorm.

La solución: escribir un Report para WebStorm.

Para cubrir nuestras necesidad de usar la propia herramienta de diff de WebStorm y tener una experiencia de desarrollo más fluida no nos quedó otra que escribir un adaptador de la abstracción Report que use la herramienta de diff de WebStorm.

Este es el código de nuestro WebStormReporter:

Approvals JS actualmente puede integrarse con dos runners, Jest y Mocha. Nosotros nos limitamos a hacer funcionar nuestro WebStormReporter con Jest porque es el runner que utilizamos en el curso. Si necesitas utilizar WebStorm con Mocha mira la documentación para ver cómo modificarlo.

Ventana de diff de WebStorm abierta por WebStormReporter.

Para usar WebStormReporter, basta con llamar en los tests a la función verifyAsJson^[4] que exportamos en vez de la función que proporciona Jest.

Conclusión.

Hemos mostrado cómo, gracias a la abstracción Report de Approvals, se puede conseguir integrar de manera sencilla Approvals JS con Webstorm.

En un futuro post, hablaremos de qué tuvimos que hacer para poder combinar approval testing y mutation testing de forma integrada dentro Webstorm.

Agradecimientos.

Nos gustaría agradecer a las tres empresas que hasta ahora han confiado en nosotros para ayudar a sus equipos a mejorar cómo trabajan con su código legacy. Ya hemos dado cuatro ediciones del curso Cambiando Legacy que han tenido muy buen feedback y nos han permitido refinar su contenido.

Por último, también nos gustaría darle las gracias a Markus Spiske por la foto del post.

Notas.

[1] Usamos la versión 7.2.3. Para que no falle la compilación hay que añadir al tsconfig.json la opción ìnclude indicando que sólo chequee los tipos en ficheros dentro de src, porque hay varios ficheros en Approvals JS que no pasan el chequeo de tipos.

[2] Approvals define toda una serie de abstracciones fundamentales (Writer, Reporter, Namer..) que permiten extender su comportamiento y adaptarla en caso de que sea necesario.

[3] Además estamos acostumbrados a ella porque la usamos regularmente para resolver conflictos en merges o visualizar cambios en la Local History.

[4] JestApprovals tiene otros métodos como verify y verifyAll. Nosotros utilizamos verifyAsJson porque necesitábamos comparar objetos y nos resultaba más cómodo hacerlo usando el formato JSON. Es por esto que sólo nos hemos preocupado de proporcionar una versión de verifyAsJson que use nuestro WebStormReporter.

Mutantes relevantes

2025-04-25T05:30:00+00:00

Este post es una traducción al español con algunas mejoras y actualizaciones del post original en inglés Relevant mutants.

1. Introducción.

Usar mutation testing nos da información sobre la capacidad de detección de errores de nuestros tests, es decir, sobre si las aserciones contenidas en dichos tests son lo suficientemente buenas como para detectar regresiones.

La técnica de mutation testing se basa en inyectar intencionalmente una regresión en una copia del código, “el mutante”, para después ejecutar los tests contra dicho mutante y verificar si alguno de los tests falla:

Si falla algún test, todo va bien, “los tests han matado al mutante”. Esto significa que nuestros tests nos protegen de ese tipo de regresión.
Si no falla ningún test, “el mutante sobrevive”, y esto podría no ser bueno. Que un mutante sobreviva quiere decir que nuestros tests no nos protegen de que ocurra esa regresión. Es posible que hayamos encontrado algo que debemos mejorar en nuestros tests.

Uso de mutation testing.

Sin embargo, cuando aplicamos mutation testing no todos los mutantes supervivientes son una señal de debilidades en los tests, este fenómeno es aún más significativo en código legacy.

Por un lado, es posible que algunos de los supervivientes estén relacionados con la existencia de código muerto, mientras que otros podrían indicar código que es innecesario para producir el comportamiento esperado y, por lo tanto, podría simplificarse^[1].

Es por esto, que debemos analizar cada mutante superviviente para determinar si es relevante o no, y sólo en caso de serlo, escribir nuevos tests para eliminarlo.

Veámoslo con un ejemplo.

2. Análisis de los mutantes supervivientes en la kata Crazy Portfolio.

La kata Crazy Portfolio es una kata para practicar con código heredado que publicamos no hace mucho. Esta kata es compleja porque el código de la clase Portfolio además de tener muchas responsabilidades y una lógica condicional compleja, utiliza fechas y zonas horarias y produce side-effects. Por si esto fuera poco existen muchas particiones con sus correspondientes fronteras y algunas invariantes de clase implícitas^[2].

En el código que utilizaremos en este ejemplo ya habíamos escrito tests de caracterización que lograban la máxima cobertura de rama posible. La cobertura de rama no puede ser del 100% porque hay una rama inalcanzable en el código de producción, y porque las costuras que introdujimos usando Extract and Override Call para romper dependencias y poder testear el código, por supuesto, no se ejecutan en los tests.

Dependiendo del refactoring que deseemos hacer, podría ser que una cobertura de rama alta no fuera suficiente para comenzar a refactorizar con confianza. Por este motivo decidimos aplicar mutation testing usando Stryker.

El resultado de aplicar mutation testing fue que 36 de 160 mutantes sobrevivieron, con lo que, parecía que tendríamos mucho trabajo de mejora en nuestros tests agregando nuevos casos de test para eliminar todos esos mutantes, y quizás algunos de ellos no serían fáciles de eliminar.

Si analizamos los mutantes supervivientes, veremos que realmente no había tantos mutantes que eliminar.

Los mutantes supervivientes se pueden clasificar en las siguientes categorías:

Mutantes en código muerto.
Mutantes en costuras.
Mutantes en código que no se utiliza desde los tests debido a las costuras.
Mutantes en código superfluo que no indican debilidades en los tests.
Mutantes que sí indican debilidades en los tests.

Analicemos las distintas categorías una por una.

2. 1. Mutantes en código muerto.

Esta categoría incluye todas las mutaciones contenidas en la rama no accesible que está en la línea 60, que ya habíamos identificado cuando escribimos los tests de caracterización.

Los mutantes supervivientes en código muerto son irrelevantes.

Estos mutantes supervivientes son obviamente irrelevantes.

2. 2. Mutantes en costuras.

Todos los mutantes supervivientes dentro de las costuras que introdujimos al romper dependencias para poder testear el código, como por ejemplo, el método createDate que se muestra en el siguiente fragmento del informe de Stryker, no son relevantes porque el código incluido en las costuras no se ejecuta en los tests.

Los mutantes supervivientes dentro de costuras son irrelevantes.

Lo mismo sucede con los mutantes que sobreviven dentro de las otras costuras: los métodos protegidos: formatDate, getAssetLines, displayMessage y getNow.

2. 3. Mutantes en código que no se utiliza desde los tests debido a las costuras.

En este grupo encontramos la mutación que sobrevive dentro del constructor de la clase Portfolio,

Los mutantes supervivientes en código que no se utiliza desde los tests debido a las costuras son irrelevantes.

Como introdujimos una costura para poder obtener los activos del portafolio sin tener que leer el archivo en los tests unitarios, getAssetLines, el campo portfolioCsvPath no se utiliza para nada, por lo tanto, el mutante superviviente mostrado en la figura anterior no es una mutación relevante.

Sobre las categorías que hemos analizado hasta ahora.

Los mutantes supervivientes en las tres categorías que hemos visto hasta ahora se pueden ignorar de forma rápida y segura porque no proporcionan ninguna pista sobre cómo mejorar los tests o el código de producción. Se trata de mutantes supervivientes código no ejercitado por los tests.

Las cosas no son tan sencillas con el resto de mutantes supervivientes, que caen en las dos categorías que nos falta por analizar.

Tendremos que examinarlos uno por uno para ver si realmente indican debilidades en nuestros tests, o si apuntan a código de producción superfluo que podría simplificarse.

Veamos las dos categorías restantes.

2. 4. Mutantes en código superfluo que no indican debilidades en los tests.

Analicemos los ejemplos más interesantes:

Caso 1: Mutaciones que sobreviven en la línea 29.

Observen esta mutación que cambia un operador de división por un operador de producto:

Mutación superviviente que cambia un operador / por un operador * en la línea 29.

o esta otra mutación que cambia un operador de producto por un operador de división:

Mutación superviviente que cambia un operador de producto por un operador de división en la línea 29.

Hay varias mutaciones similares más en la misma línea.

Estas mutaciones que reemplazan el operador de división por el operador de producto parecen muy confusas y, al principio, pueden resultar incluso desconcertantes. ¿Por qué sobreviven?

Para comprenderlo, debemos analizar con más detalle la condición que se está mutando y su significado.

Al hacerlo, vemos que lo único relevante para que la condición Math.floor(asset.getDate().getTime() - now.getTime() / (1000 * 60 * 60 * 24)) < 0 sea verdadera o falsa es el signo de la diferencia entre los dos tiempos en milisegundos: asset.getDate().getTime() - now.getTime(). El resto de la expresión, (1000 * 60 * 60 * 24), es simplemente un número positivo (se trata un factor de conversión para pasar de milisegundos a días) que no cambiará el signo de dicha diferencia de tiempo, y, por lo tanto, no cambiará la evaluación de la expresión booleana completa, Math.floor(la_diferencia_de_tiempos / el_numero_positivo) < 0.

Esto quiere decir que todos esos mutantes que cambian los operadores / por * no están señalando ningún tipo de debilidad en nuestros tests. Lo que realmente indican es la existencia de código de producción innecesario, en este caso la conversión de milisegundos a días, que podríamos simplificar^[3], quedando la siguiente condición: Math.floor(asset.getDate().getTime() - now.getTime()) < 0.

Esta simplificación (que sólo haríamos una vez tuviésemos tests más fuertes que ya eliminen todos los mutantes relevantes) sería suficiente para eliminar todos los mutantes relacionados con código superfluo en la línea 29.

Case 2. Mutaciones que sobreviven en la línea 27.

Mutación superviviente en la creación de un value object en la línea 27.

Esta mutación superviviente hace que nunca se creen objetos de la clase PricelessValue (la condición es sustituida por un false), y aún así los tests siguen pasando. ¿ Cómo puede ocurrir esto?

Que estos mutantes sobrevivan quiere decir que, o bien, tenemos alguna debilidad en los tests, o bien, que la clase PricelessValue no es necesaria para el comportamiento que los tests están protegiendo. Para entender qué opción es la correcta debemos preguntarnos cómo es que estas mutaciones han sobrevivido.

Si miramos con atención el código, nos daremos cuenta de que estas mutaciones sobreviven porque la clase derivada PricelessValue no se utiliza en absoluto en el código. En el código de producción sólo se está utilizando el getter de la clase base de la jerarquía, MeasurableValue, y por lo tanto, toda la jerarquía de herencia es superflua. La causa detrás de este problema es la feature envy contra la clase Asset que existe en el código actual, es más Asset es una data class.

De nuevo, estos mutantes no son relevantes para mejorar nuestros tests y no tenemos que perder el tiempo intentando matarlos ahora.

Cuando ya tengamos mejores tests que eliminen todas las mutaciones relevantes, podremos refactorizar el código para eliminar la feature envy rampante contra la clase Asset, y decidir si es necesario mantener o no la jerarquía MeasurableValue. Por tanto, una buena asignación de responsabilidades eliminaría las mutaciones de la línea 27 que hemos comentado.

5. Mutantes que sí indican debilidades en los tests.

Sólo uno de los mutantes de la línea 29 es relevante para mejorar nuestros tests, el que cambia el operador < por el operador <=:

Mutante superviviente en la línea 29 que cambia el operador < por el operador <=.

La supervivencia de este mutante nos está indicando que nuestros tests no están ejercitando correctamente los valores alrededor de una frontera entre diferentes comportamientos o particiones.

Hay otros mutantes supervivientes similares al anterior que también indican problemas al testear valores alrededor de una frontera, por ejemplo los de las líneas 32 y 46 que se presentan a continuación:

Mutante superviviente en la línea 32 relacionado con problemas al probar valores alrededor de una frontera.

Mutante superviviente en la línea 46 relacionado con problemas al probar valores alrededor de una frontera.

Otro ejemplo de un mutante superviviente que puede indicar una debilidad en nuestros tests es el de la línea 22 que se muestra a continuación:

Mutante superviviente en la línea 22 relacionado con no chequear el mensaje de una excepción.

Si examinamos los test, veremos que lo que estamos comprobando es si se lanza una excepción cuando la fecha tiene un formato incorrecto, pero no estamos comprobando el mensaje de la excepción. En este caso, para eliminar este mutante habría que hacer que los tests se acoplen al texto concreto ”wrong date”.

En nuestra opinión, el mensaje concreto de error es un detalle volátil y acoplar los tests a él sería una especificación excesiva que aumentaría innecesariamente la fragilidad de los tests. Para evitarlo decidimos ignorar dicho mutante.

Conclusiones.

Hemos mostrado un ejemplo de cómo no todos los mutantes supervivientes indican debilidades en nuestros tests. De los 36 mutantes supervivientes originales, solo 13 acabaron siendo relevantes para mejorar nuestros tests^[4] (optamos por ignorar el mutante superviviente relacionado con el mensaje de error). En este caso, los 13 mutantes relevantes están relacionados con fronteras entre comportamientos que los tests no están chequeando correctamente.

Como los mutantes supervivientes, a veces, no son fáciles de eliminar^[5], está muy bien saber identificar aquellos que no son relevantes para mejorar los tests.

Matar 13 mutantes es una tarea mucho menos abrumadora que matar a 36, pero tuvimos que invertir tiempo en analizar los 36 mutantes para ver si eran relevantes o no. Lo bueno es que la mayoría de los mutantes descartados e irrelevantes fueron fáciles de identificar: los relacionados con la existencia de código muerto^[6] y los relacionados con la introducción de costuras.

También discutimos otra categoría de mutantes supervivientes que, si bien no señalan la necesidad de mejorar los tests, son una señal de código que podría ser innecesario para lograr el comportamiento deseado. Esta información puede ser muy interesante para guiar refactorizaciones posteriores, una vez hayamos mejorado los tests eliminando los mutantes relevantes.

Espero que este ejemplo detallado les pueda resultar útil al analizar los resultados de aplicar mutation testing.

Agradecimientos.

Me gustaría agradecer a Fran Reyes y Rubén Díaz por revisar borradores de este post.

También agradecemos a los desarrolladores de Audiense por haber sido los beta testers de la kata Crazy Portfolio como parte de las sesiones de práctica deliberada que llevamos haciendo desde hace unos años. Siempre es un placer trabajar con ustedes.

Por último, también me gustaría darle las gracias a Carlos Machado por la foto del post.

Notas.

[1] Estos dos tipos de falso positivo (mutantes irrelevantes) están directamente relacionados con los code smells Dead Code y Speculative Generality que William Wake clasifica bajo la categoría Unnecessary Complexity. Ver nuestro post De taxonomías y catálogos de code smells.

[2] Solíamos usar una versión simplificada de esta kata en nuestro curso Cambiando Legacy Code, pero al final decidimos cambiarla por otra kata un poco más sencilla.

[3] Ya hablamos de mutantes supervivientes que señalan código redundante en un post anterior: Mutando para simplificar.

[4] Los 13 mutantes supervivientes relevantes se encuentran en las líneas 29 (1), 32 (2), 46 (2), 70 (1), 71 (2), 76 (1), 77 (2) y 83 (2).

Los mutantes supervivientes en las líneas 32, 46, 77 y 83 señalan fronteras entre comportamientos que los tests están ignorando por completo (por ese motivo puede sobrevivir una mutación que elimina completamente la condición), mientras que los mutantes supervivientes en las líneas 29, 70 y 76 indican fronteras entre comportamientos que los tests sólo están probando parcialmente.

[5] Probar bien las fronteras entre diferentes comportamientos y, por lo tanto, eliminar mutantes relacionados con ellas se vuelve mucho más fácil si se conocen los conceptos de on-point y off-point de una frontera. Este conocimiento proporciona un método sistemático para eliminar este tipo de mutantes. En el material actualizado de nuestra formación de TDD enseñamos a analizar y testear correctamente valores de frontera.

[6] Nuestra recomendación es que, antes de usar una herramienta de mutation testing, utilicen una herramienta de cobertura para detectar código no cubierto por los tests y código muerto, ya que, los resultados de las herramientas de cobertura son mucho más fáciles de analizar que los resultados de las herramientas de mutation testing.

Sprouting or wrapping?

2025-03-14T05:30:00+00:00

Introduction.

In situations in which we really don’t have time to cover & modify, we can use techniques that allow us to write tested code somewhere else and use it from existing code doing minimal changes to it. These techniques must be used carefully because, even though they enable us to add tested code, its usage is not tested. This is not ideal but it’s still much better than giving up and using edit & pray^[1].

There are two such techniques: wrapping and sprouting.

We have noticed that sometimes people find it difficult to know when to apply one or the other.

This post will only focus on discussing when to apply each technique^[2].

Sprouting or wrapping?

We choose either sprouting or wrapping depending on the location where the requested change needs to be applied.

When to use sprouting.

If after identifying where we need to add a new behaviour, the change point is in the middle of an existing behaviour, we will use sprouting.

Changes for which we use sprouting (figure from Changing Legacy Code training).

When to use wrapping.

If the new behaviour happens either before or/and after an existing behaviour, i .e., the change point is before or/and after an existing behaviour, we will use wrapping.

Changes for which we use wrapping (figure from Changing Legacy Code training).

Summary.

In this short post we have discussed when to apply wrapping or sprouting.

We’ve seen how we will apply wrapping or sprouting depending on in which part of the existing behaviour the new one is going to happen.

Once we identify the change points, if they are before or/and after the existing behaviour, we’ll use wrapping. If not, it means that the change point is in the middle of the existing behaviour, and then we’ll use sprouting.

Decision flow to choose wrapping or sprouting (figure from Changing Legacy Code training).

Remember, wrapping and sprouting are techniques that allow placing changes in new tested code without having to cover existing behaviour. As such, they are shortcuts for when we don’t have enough time to cover & modify. This is not ideal but it’s still much better than giving up and using edit & pray.

Acknowledgements.

I’d like to thank Antonio de la Torre and Fran Reyes for revising drafts of this post.

I’d also like to thank Greta Hoffman for the photo.

References.

Working Effectively with Legacy Code book, Michael Feathers

Notes.

[1] If you are not familiar with the terms cover & modify, edit & pray, wrapping or sprouting, you may want to read Working Effectively with Legacy Code book or have a look at our Changing Legacy Code training.

[2] If you don’t know how to apply them, have a look at the following links for quick recipes, wrap method, wrap class, sprout method and sprout class, or, even better, read chapter 6, “I Don’t Have Much Time and I Have to Change It” of Working Effectively with Legacy Code book.

The class is not the unit in the London school style of TDD

2025-03-03T05:30:00+00:00

Introduction.

A dangerous misconception: considering that the class is the unit in unit testing.

Considering that the class is the unit in unit testing has terrible effects. If we follow this idea, we’ll use test doubles to isolate the class under test from any class that collaborates with it (its collaborators). This will produce tests that are highly coupled with implementation details, and therefore very brittle (high structure-sensitiveness)^[1].

Considering the class as the unit...

This brittleness will make those refactorings affecting interfaces to which our tests are coupled more expensive (they will take more time^[2]), as we’d be forced to change the tests as well. This increase in cost will hinder refactoring.

Many problems when using test doubles are caused solely by this misconception. Thankfully it seems to be receding, as more developers are starting to understand that the unit in unit testing is the behavior and not the class. This understanding helps to produce less structure-sensitive tests which don’t hinder refactoring.

The class is not the unit.

The surviving misconception: considering that the class is the unit in the London School or Mockist style of TDD.

Recently, we have noticed many videos, posts and even books ^[3] that affirm that the, so called, mockist style of TDD considers that the class is the unit in unit testing.

Unfortunately this other widespread misconception is making developers, either apply the mockist style of TDD completely wrong (testing every class in isolation from its collaborator), or choose not to use it altogether to avoid the class-is-the-unit problems we described before.

In the remainder of this post, we will show that the mockist style of TDD does not consider the class is the unit in unit testing.

In our discussion below, we will use the book Growing Object Oriented Software, Guided by Tests (GOOS) by Steve Freeman and Nat Pryce as the reference for the mockist style of TDD.

The class is not the unit in the mockist style of TDD.

Exhibit 1: Values & Objects.

In the section Values and Objects (chapter 2: Test-Driven Development with Objects) of the GOOS book its authors distinguish between two concepts:

Values, which “model unchanging quantities or measurements” (think of Value Objects).
Objects, which “have an identity, might change state over time, and model computational processes”.

When the word “object” is used in the GOOS book, they refer only to the second concept.

Don’t double values!!

As its title says, the section Don’t Mock Values (chapter 20: Listening to the Tests) recommends that we do not use test doubles to simulate values in tests.

The GOOS authors say even more:

“There’s no point in writing mocks for values (which should be immutable anyway). Just create an instance and use it.”

This recommendation in itself shows how the idea of isolating each class by using test doubles of every class that collaborates with the class under test has never been a part of the mockist style.

Likely, the confusion may have arisen because both concepts, values and objects, are implemented by the same language construct in most OO languages: the class.

Even though some authors acknowledge the distinction between values and objects, they still that the class is the unit in the mockist style of TDD^[4]. However, we view this claim as a contradiction.

There are more ideas in the GOOS book that refute the false belief of considering the class is the unit in the mockist style of TDD.

Exhibit 2: Internals vs Peers.

For the GOOS book authors not all the collaborators of an object are considered “real collaborators”.

In the section Internals vs Peers (chapter 6: Object-Oriented Style), they distinguish two types of collaborators:

Peers (“real collaborators”).
Internals.

Internals vs Peers from Mock Roles Not Object States talk.

Sadly, this distinction between internals and peers is probably one of the less understood concepts in the GOOS book.

Recognizing peers.

The GOOS book authors consider that an object’s peers are “objects with single responsibilities”, i. e., following the single responsibility principle, that can be categorized (loosely) into three types of relationship.

Peers (real collaborators) stereotypes:

Dependencies: services that the object needs from its environment so that it can fulfill its responsibilities.
Notifications: other parts of the system that need to know when the object changes state or performs an action.
Adjustments or Policies: objects that tweak or adapt the object’s behaviour to the needs of the system (think Strategy Pattern).

Any collaborator that is not a peer would be considered an internal.

They only consider these stereotypes as heuristics to help us think about the design, not as hard rules. Later in the book, in the section Where Do Objects Come From? (chapter 7: Achieving Object-Oriented Design), they explain other heuristics that we can apply to discover an object’s peers: ”Breaking Out”, “Budding Off” and ”Bundling Up”. We’ll talk about these techniques in a future post.

In their talk Mock Roles Not Object States, Freeman and Pryce provide an excellent explanation of the concepts of internals and peers when discussing the “The test exposes internal implementation details of my object” test smell.

Don’t use test doubles for internals!!

Identifying an object’s peers is crucial to minimize the coupling of tests to implementation details, since internal objects are not intended to be simulated in tests:

“We should [only] mock an object’s peers—its dependencies, notifications, and adjustments […]—but not its internals” (chapter 7: Achieving Object-Oriented Design).

In our tests we will only use test doubles to simulate the behaviors (roles, responsibilities) that the behavior we are testing depends on, not the classes it depends on. This is related to the recommendation “mock roles, not objects”. And those depended-on behaviors are the peers of an object.

In our opinion, internals should not be injected from the outside; instead, they should be created within the constructors of the objects they belong to.

The reason to both not using test doubles to simulate internals, and creating them within the constructors of the objects they belong to is to avoid tests “knowing” they exist, thus removing any coupling between them.

This is an important difference about internals and peers: peers have behaviours interesting enough to be “known” and documented by the tests, whereas internals are not even “known” by the tests.

What is the unit in the mockist style of TDD then?

We hope that, by now, we have managed to show that the class is not the unit in the mockist style of TDD. What does the mockist style of TDD TDD consider the unit then?

Just like the classic style of TDD, the mockist style of TDD also considers behavior as the unit in unit testing^[5]. And, as we have seen, a behaviour might be implemented by 1 or N classes, but that is only an implementation detail.

Conclusion.

The purpose of this post was to dispel a common misconception about the mockist style of TDD that states that the class is the unit in the mockist style of TDD.

In some cases, this misconception comes from not having read or not having understood the GOOS book well.

In some other cases, we think that, sadly, this idea of the class-is-the-unit is used as part of a straw men intended to criticize the mockist style of TDD by saying that, all the maintainability problems associated with the class being the unit, are produced by using the mockist style of TDD.

In any case, by dispeling this common misconception, we hope to facilitate better discussions about the mockist style of TDD trade-offs and enable its more effective application.

Update 2025/09/29:

Added another distinction between internals and peers: tests know about peers, whereas they ignore that internals exist.

The TDD, test doubles and object-oriented design series.

This post is part of a series about TDD, test doubles and object-oriented design:

The class is not the unit in the London school style of TDD.
“Isolated” test means something very different to different people!.
Heuristics to determine unit boundaries: object peer stereotypes, detecting effects and FIRS-ness.
Breaking out to improve cohesion (peer detection techniques).
Refactoring the tests after a “Breaking Out” (peer detection techniques).
Bundling up to reduce coupling and complexity (peer detection techniques).

Acknowledgements.

I’d like to thank Fran Reyes, Alfredo Casado, Emmanuel Valverde Ramos, Fran Iglesias Gómez and Marabesi Matheus for giving me feedback about several drafts of this post.

Finally, I’d also like to thank William Warby for the photo.

References.

Notes.

[1] When we test classes in isolation, the resulting tests will have a high structure-sensitiveness as opposed to the ideal of tests being structure-insensitive (see Test Desiderata 2/12 Tests Should be Structure-Insensitive).

[2] If we apply a parallel change the test will not break at any moment during the refactoring, but this is more costly than doing a refactoring when the tests are not affected.

[3] Search the internet and you will find multiple examples of the misconception we are addressing in this post.

[4] This happens in the book Unit Testing Principles, Practices, and Patterns.

[5] The authors of the GOOS book state that we should “Unit-Test Behavior, Not Methods” (chapter 5: Maintaining the Test-Driven Cycle).

A case of Shotgun Surgery

2025-02-03T05:30:00+00:00

This post is an English translation of the original post: Un caso de Shotgun Surgery.

The context.

Some time ago we were collaborating with a client whose product relied heavily on Search engine optimization (SEO). In general, SEO is usually an important area to focus on, but for this client, SEO represented a significant source of income and was therefore critical to their success.

When search engines analyze a page, there are two key aspects our system needs to determine, the indexing and the canonical of that page:

Indexing: it determines whether a page should be indexed or not by the search engine.
Canonicalization: it specifies the canonical URL of similar pages to avoid penalties for duplicate content.

For that product, SEO was not only a significant source of revenue but also quite complex. Decisions about indexing and canonical URLs depended on factors such as location, search types, and the number of results. This complexity was inherent to the domain problem, i. e., its essential complexity.

The code

In that legacy system, SEO rules were located in two areas of the application: the IndexingCalculator and the CanonicalCalculator classes.

Clients viewed these two functionalities through the following interfaces shown below:

The problem.

At first glance, based on the names of the interfaces, and, it seemed that the responsibilities were neatly separated. There was one place for deciding whether a page should be indexed, IndexingCalculator, and another for calculating its canonical URL, CanonicalCalculator. Both came with their own suite of tests that verified their respective behavior independently.

However, when asked to modify the canonical calculation rules, we were forced to consider and likely modify both the implementation of IndexingCalculator and CanonicalCalculator. The same happened when we had to modify the indexing rules. The problem was that changes to one component often required changes to the other.

Although the interfaces were designed to separate responsibilities and their names aligned with domain concepts, their implementation was not cohesive. Some indexing logic had leaked into CanonicalCalculator, and some canonical logic had leaked into IndexingCalculator^[1]. The code exhibited a clear case of a code smell known as Shotgun Surgery which is a violation of the Single Responsibility Principle (SRP). This was a source of accidental complexity.

In this specific case, there was a lack of cohesion at the implementation level. Although the axes of change had been correctly identified at the interface level, the responsibilities were scattered across both implementations.

A case of shotgun surgery...

To fix this case of Shotgun Surgery we needed to segregate responsibilities by moving all the indexing logic to IndexingCalculator, and all the canonical logic to CanonicalCalculator so that we no longer violate the SRP.

Segregating the Rules.

If the canonical and indexing logics could be executed in any order, moving the rules would simply involve moving test cases between the tests of each implementation and moving the corresponding code using Move Function.

Moving rules would be easy if the order of execution of the canonical logic and the indexing logic did not matter.

However, in this case, fixing the shotgun surgery was much more difficult because the order in which the SEO rules had to run was neither in IndexingCalculator nor in CanonicalCalculator but in client code that wasn’t even tested. This meant that there was no way to determine whether moving some logic from one class to the other was preserving the behavior.

Considering, as already explained, that SEO represented a significant source of revenue for the product, we could not accept the level of risk involved in refactoring without tests that protected all SEO behaviour.

To reduce the risk of altering the behavior, our strategy was to introduce a new class called PageSEO, whose responsibility was to coordinate the indexing and canonical calculations. PageSEO explicitly owned the sequence of operations. By centralizing this orchestration logic, we eliminated the implicit, fragile dependencies embedded in the client code.

Next, we created a new suite of tests for PageSEO. This new suite not only included the test cases of both CanonicalCalculator and IndexingCalculator, but also new previously missing test cases that protected the order in which the indexing and canonical rules were applied. In this way, we were testing not only each component individually but also the integration between them.

New tests for the new abstraction that encapsulates the order in which indexing and canonical logics are executed.

These tests for PageSEO gave us enough confidence to start refactoring.

One rule at a time, we started moving responsibilities to their rightful owners, the indexing logic that had leaked into CanonicalCalculator back to IndexingCalculator, and the canonical logic that had leaked into IndexingCalculator back to CanonicalCalculator. We deleted tests that were testing logic that was located in the wrong places and used the Move Function refactoring on the logic.

Once we finished segregating responsibilities, we removed the redundant tests that were only addressing each separate responsibility (the tests directly against CanonicalCalculator and IndexingCalculator).

Now we can move the rules with confidence. Once the responsibilities are segregated, we delete the initial tests.

After applying this refactoring, we achieved the following:

Cohesive Objects: CanonicalCalculator and IndexingCalculator handled only their own responsibilities.
Centralized Coordination: The order of execution was neatly encapsulated within PageSEO. The calculations remained independent, but their interaction was controlled and tested.

The SEO code adhered to the SRP.

Conclusion.

We have presented a real case of Shotgun Surgery and explained how we refactored it to achieve a more cohesive design.

In simpler situations, addressing Shotgun Surgery might only involve moving logic and tests. But in this context, the untested execution order of the rules, domain complexity, and the high business value of SEO forced us to take a more careful approach. By introducing an intermediate coordinator, PageSEO, we reduced risk and provided a single place to test and reason about SEO’s behavior.

If you find yourself in a similar situation, perhaps you can apply some aspects of this solution to reduce risks.

I hope this explanation was clear and helpful. Feel free to reach out for guidance if you encounter similar challenges or need assistance in improving the design of your project!

Notes.

[1] The reason why the responsibilities became mixed might lie in the design of the interfaces, but this issue may be addressed in a future post.

An example of wrong port design detection and refinement

2024-10-03T05:30:00+00:00

1. Introduction.

As part of the Intensive Technical Mentoring Program that we recently did for AIDA, we worked on the Legacy Security Manager kata. This is a great kata to practise dependency-breaking techniques and how to test and refactor legacy code.

2. Introducing tests.

In order to be able to introduce unit tests, we first used the Extract Call & Override dependency-breaking technique, to create two seams, one to spy what was being written on the console, and another one, to control the user input received through the console.

Breaking those dependencies allowed us to write the following unit tests:

3. Separating core logic from infrastructure.

With those tests in place, the pairs started refactoring the code until they were finally able to separate infrastructure from core logic using the “Move Function to Delegate” refactoring^[1] to control the awkward dependencies by inverting them and making them explicit. This is the code after the refactoring:

Notice the two ports, Notifier and InputReader. These ports are the result of directly applying the “Move Function to Delegate” refactoring to the previously existing seams: the methods protected virtual string Read() and protected virtual void Notify(string message) shown in the previous section.

This is how SecurityManagerTest looks after the refactoring:

4. Some test smells pointing to a design problem.

But, if you look closer at the tests, there’s a smell that is pointing to problems in the current design.

Notice inside the helper method VerifyNotifiedMessages how, in order to avoid regressions, we need to enforce the order of the calls to Notifier’s Notify method so that they coincide with the order in which stubbed values are returned by InputReader’s Read method. If we wouldn’t do this, we might change the code in ways that would break the behaviour but not the tests, thus allowing regressions.

Having said that, it shouldn’t be necessary to enforce this order concordance between the stubbed calls to the InputReader and the calls to the Notifier. This is an overspecification that makes the tests more fragile, for instance, changing the order of some of the input requests would break the tests, even though the observable behaviour wouldn’t be changed.

Another signal that something is amiss is the duplication in the verification of the first four calls to the Notifier which we introduced the helper method, VerifyNotifiedMessages, to avoid. This duplication is caused by a leak of implementation details because only the last notification is related to the observable output of the system, and thus, is the only one required to verify the behaviour. We should not need to check the other previous four notifications. The helper method, VerifyNotifiedMessages, is removing this duplication and hinting that we are only interested in the last notification, which is better than leaving the duplication, but this only addresses the symptom but not the cause.

The underlying problem that is causing all this accidental complexity in the tests is that the ports are not well designed.

5. How did we get to this point?

When applying Extract Call & Override it’s advisable to change the code as little as possible because this technique is applied without tests^[2]. Sometimes this may produce seams that are not a good abstraction and are too low level, but that’s ok at that stage, because the goal is to introduce tests assuming as few risks as possible.

The current ports come directly from applying the “Move Function to Delegate” refactoring to the seams that we used when we broke the dependencies that were stopping us from introducing unit tests. Many times this is just fine, and seams directly become ports, but this is not always the case, like in the current example.

The current ports are leaking an implementation detail: that we need to call two methods in sequence in order to get the user input.

6. Fixing the design.

If we think about the purpose or the role of each of the messages written to the console, we may see that they fall in two different categories: some are requests to the user to introduce some specific input, and others are straight away notifications. We may also see that calling two methods in sequence to get the user input is an implementation detail, what the client (SecurityManager) needs is just getting the user input, the two calls in sequence is how we get the user input.

Thinking in those different roles we may refactor the code (applying a parallel change) to use the following new interfaces for the Input and Notifier ports:

This the new code of SecurityManager^[3] using the new ports:

And these are the resulting tests:

Notice how this improved design has made disappear the two smells that were present in the previous version of the tests:

We don’t need to coordinate the order of the stubbed values and the order of the corresponding user input requests anymore.
We only notify and verify the message that informs about the result of the operation.

7. Conclusions.

We have seen how badly designed ports may lead to smells in how test doubles get used in the tests, in the example shown in this post, duplication and overspecification of the order of the calls. Such overspecification, in particular, makes the tests more fragile.

Those badly designed ports came from blindly applying “Move Function to Delegate” refactoring to every seam directly. In most cases, applying “Move Function to Delegate” to seams it’s perfectly ok, but sometimes, it might lead to ill designed ports.

We saw how thinking about the role or purpose of each interaction led us to better designed ports, and how this new improved design just made the problems in the tests disappear.

8. Acknowledgements.

I’d like to thank Fran Reyes and Alfredo Casado for revising drafts of this post.

Also thanks to the participants in the Intensive Technical Mentoring Program that we recently did for AIDA who worked through the whole kata, and to Audiense’s developers which also worked on a version of the kata that starts with the ill designed ports to practise their detection from test smells and refactoring using parallel change to fix the design. It was a pleasure to work with all of you.

Finally, I’d also like to thank Steve Johnson for the photo.

9. Notes.

[1] Documented by Nicolas Carlo in his book Legacy Code: First Aid Kit.

[2] In fact, dependency-breaking techniques are applied in order to be able to introduce tests.

[3] Keep in mind that SecurityManagers code reflects a snapshot in time while solving the kata. We didn’t want to divert the focus of the post to anything other than the detection of problems in the tests that led to detecting problems in the port interfaces, and how we refined those interfaces. As such SecurityManagers design is still a work in progress. There are still many issues that would be worked later in the kata, such as, for instance:

Where should the responsibility of deciding if the user input is valid or not be? Maybe UserDataRequester would be a better place.
Finding a better place for the password encryption responsibility, which now is located in a static method in SecurityManager (being static is a hint that it doesn’t belong there). Not representing the user password with a string would attract that behaviour and, probably, the password length validation.

But those are material for another story…

Atributos de calidad e historias de usuario en Agile Sur

2024-09-30T11:00:00+00:00

El 28 de agosto tuve la oportunidad de hablar sobre atributos de calidad e historias de usuario en Agile Sur.

Los atributos de calidad son una problemática, de la que creemos, se habla poco pero que tiene mucha importancia a la hora de desarrollar software.

Los atributos de calidad definen cómo de bien un sistema realiza alguna acción y, por tanto, guardan relación con la arquitectura. Las historias de usuario, por otro lado, nos ayudan a comunicar con negocio lo que es necesario hacer. En esta charla exploramos cómo comunicamos los atributos de calidad.

A continuación dejo la grabación que también puede encontrarse en nuestra sección de publicaciones (pestaña videos).

Las slides se pueden encontrar aquí.

Para finalizar, me gustaría agradecer a Agile Sur y en especial a Rafael Sobrá Hidalgo su esfuerzo y generosidad para organizarla.

Relevant mutants

2024-07-22T05:30:00+00:00

1. Introduction.

Mutation testing gives us information about the fault detection capability of a test suite, whether the assertions that its tests make are good and strong enough to capture regressions.

The idea behind it is to purposefully inject a regression in a copy of the code, “the mutant”, run the test suite against this mutant and check if the test suite breaks:

If it does, everything is fine, “the mutant is killed”. This means that the test suite protects us from that kind of regression.
If it does not, “the mutant survives”. This means that the tests don’t protect us from that regression happening. We may have found something to improve in the tests.

How mutation testing is used.

However, when we apply mutation testing to legacy code, not all surviving mutants are a signal of weaknesses in the test suite. Some of the survivors may be related to the existence of dead code, and others may be indicating code that is unnecessary to produce the expected behaviour, and, as such, could be simplified. That is why we must analyse each of the surviving mutants to decide if it is relevant or not, and only if it is so, write new test cases to kill it.

Let’s see it with an example.

2. Analyzing the surviving mutants in the Crazy Portfolio kata.

The Crazy Portfolio kata is a kata to practise working with legacy code that we recently published. This kata is complicated because the code of the Portfolio class, not only has many responsibilities and complex conditional logic, but also, uses dates and time zones, and has side-effects, many boundary conditions between partitions and some implicit invariants^[1].

In the code used for this example we had already written characterization tests achieving the maximum possible branch coverage, which is not 100% because there is an unreachable branch in the code, and because of the seams we introduced using Extract and Override Call, which, of course, are not executed in the tests.

Depending on the refactoring we plan to do, it might not be enough to have high branch coverage to start refactoring with confidence, so we applied mutation testing using Stryker and the results were that 36 out of 160 mutants survived.

Apparently, we would need to kill a lot of mutants by adding new test cases in order to improve our test suite, and perhaps some of the mutants might not be so easy to kill.

If we analyse the surviving mutants, we’ll see that there really aren’t that many mutants to kill.

The surviving mutants fall into the following categories:

Mutants in dead code.
Mutants in seams.
Mutants in code not used in the tests because of the seams.
Mutants in superfluous code that don’t point to weaknesses in the test suite.
Mutants that do point to weaknesses in the test suite.

2. 1. Mutants in dead code.

This category includes all the mutations in the non-accessible branch in line 60 that we identified when we wrote the characterization tests.

Surviving mutations in dead code are irrelevant.

These surviving mutants are obviously irrelevant.

2. 2. Mutants in seams.

All the mutants in the seams that we introduced, as for instance, the createDate method seen in the following fragment of the Stryker report, are not relevant because the seams’ code is not executed in the tests.

Surviving mutations in seams are irrelevant.

The same happens for the mutants inside the other seams, the protected methods: formatDate, getAssetLines, displayMessage and getNow.

2. 3. Mutants in code not used in the tests because of the seams.

In this group we find the mutation that survives in the constructor of the Portfolio class,

Surviving mutations in unused code due to seams are irrelevant.

Since we introduced a seam to get the assets without actually reading the file in the unit tests, the portfolioCsvPath field is not used. Therefore this mutant survival is related to the getAssetLines seam that we introduced, and this means that it is not a relevant mutant.

About the categories we have seen so far.

The surviving mutants in the three categories we’ve seen so far can be quickly and safely ignored because they don’t provide any hints on how to improve the test suite or the production code.

We’ll need to examine one by one the rest of the surviving mutants to see if they actually point to weaknesses in our tests or production code that may be simplified. Let’s see the two remaining categories.

2. 4. Mutants in superfluous code that don’t point to weaknesses in the test suite.

Let’s look at the most interesting examples:

Case 1: Mutations surviving in line 29.

Have a look at:

Surviving mutation changing / operator to * operator in line 29.

or at:

Another surviving mutation changing * operator to / operator in line 29.

There are several more similar mutations on the same line.

These mutations that replace the division operator with the product operator, and viceversa, seem very confusing and may, at first, be baffling. Why do they survive?

To understand it, we need to look closer at the condition and what it means. The only relevant thing to make the condition true or false is the sign of the difference of the two times in milliseconds: asset.getDate().getTime() - now.getTime(). The rest of the expression, (1000 * 60 * 60 * 24), is just a positive number that is dividing the previously mentioned difference, but it will not change its sign, and therefore, it will not change the evaluation of the boolean expression Math.floor(difference / positive_number) < 0 .

These mutants, that change / operators to * operators, and viceversa, therefore, are not pointing to weaknesses in our tests. What they are indicating, instead, is production code that we don’t need, and, which we could simplify^[2], writing the following condition instead: Math.floor(asset.getDate().getTime() - now.getTime()) < 0.

This simplification (that we’d do only once we have stronger tests that eliminate all the relevant mutants) would be enough to eliminate all the related mutants.

The only surviving mutant in line 29 that is relevant to improve our tests is the one that changes the < operator to the <= operator.

Surviving mutation changing < operator to <= operator in line 29.

This surviving mutant indicates that our tests are not correctly exercising a boundary condition that exists between two partitions of the values that the difference between the date of the assets and the date the portfolio value is being calculated can take.

Case 2. Mutations surviving in line 27.

Surviving mutation when mapping to value object in line 27.

The survival of those mutations means that the PricelessValue class is not necessary to achieve the behaviour that the tests are protecting. How do they survive?

These mutations survive because the derived PricelessValue class is not used at all in the code. The only thing that is used is the getter of the base object of the hierarchy, MeasurableValue, and therefore the entire inheritance hierarchy is superfluous. The root cause of this problem is the feature envy against the Asset class present in the current code.

Again these mutants are not relevant to improve our tests and we do not have to waste time trying to kill them.

Once we have stronger tests that eliminate all the relevant mutants, we can refactor the code to eliminate the rampant feature envy, and decide if we need to keep the hierarchy or not. These mutants would disappear then.

5. Mutants that do point to weaknesses in the test suite.

We’ve already seen an example in line 29 of a mutant that was indicating that our tests are not correctly exercising a boundary condition. This surviving mutant is changing the < operator to <=.

Surviving mutation changing < operator to <= operator in line 29.

There are other surviving mutants similar to the previous one that also indicate problems testing boundary values, for instance the ones in the lines 32 and 46 presented below:

Surviving mutation in line 32 related to problems testing boundary values.

Surviving mutation in line 46 related to problems testing boundary values.

Another example of a surviving mutant that may point to a weakness in our test suite is the one in line 22 showed below:

Surviving mutation in line 22 related to not checking an exception message.

If we examine the test suite, we’ll see that we are testing that an error is thrown when the date is badly formatted, but we are not checking the error message. In this case, depending on if we want the tests to be coupled with the ”wrong date” string or not, we may decide to kill this mutant or not. We decided to ignore this mutant to avoid coupling the tests to the exception message.

Conclusions.

We’ve shown an example of how not all surviving mutants point to weaknesses in our test suites. Of the original 36 surviving mutants, only 13 of them were relevant to improve our tests suite^[3] (we chose to ignore the one related to the error message). Those 13 mutants are related to boundary conditions that are not being properly exercised by the test suite.

Having to kill 13 mutants is a much less daunting task than killing 36 of them. A nice thing is that most of the discarded, not relevant mutants were easy to identify: the ones related to the existence of dead code^[4] and to the introduction of seams. This is great because, sometimes, surviving mutants might not be so easy to kill^[5].

We also saw another category of surviving mutants that, even though, do not point to improvements in the test suite, are a signal of code that may be unnecessary to achieve the desired behaviour. We may decide to take advantage of these hints in later refactorings once the test suite has improved by killing the relevant mutants.

I hope this detailed example may prove useful to you when you analyse mutation testing results.

Acknowledgements.

I’d like to thank Fran Reyes and Rubén Díaz for revising drafts of this post.

Also thanks to Audiense’s developers for being the beta testers of the Crazy Portfolio kata as part of our deliberated practice sessions. It is always a pleasure to work with you.

Finally, I’d also like to thank Carlos Machado for the photo.

Notes.

[1] We use a simplified version of this kata in our Changing Legacy Code training.

[2] We already talked about surviving mutants pointing to redundant code in a previous post: Mutando para simplificar.

[3] The 13 relevant surviving mutations are in lines 29 (1), 32 (2), 46 (2), 70 (1), 71 (2), 76 (1), 77 (2) and 83 (2).

The surviving mutations in lines 32, 46, 77, and 83 point to boundary conditions which are completely ignored by the test suite (that’s why one of the surviving mutations can completely remove the condition), whereas the surviving mutations in lines 29, 70 and 76 point to partially tested boundary conditions.

[4] We advise using a coverage tool to detect uncovered and dead code before running a mutation testing tool, because coverage tools results are easier to analyze than the mutation testing tools’ ones.

[5] Testing boundary conditions, and, hence, killing mutants related to them becomes much easier if you know about boundaries’ on and off points. These knowledge provides you a systematic way if killing this kind of mutants. We teach these concepts in our revamped TDD training material.

"Move seam to delegate" refactoring

2024-05-09T05:30:00+00:00

We’d like to document a refactoring that we usually teach to teams we work with: the Move seam to delegate refactoring.

Move seam to delegate.

Motivation.

Sometimes we want to move some code to a delegate but that code contains a protected method we’re overriding in our tests in order to sense or separate^[1]. That method is an object seam.

The tests (the violet eye) are coupled to the seam.

Our current tests are anchoring that method because if we move it, all the tests will fail.

Let’s see an example.

Have a look at the BirthdayGreetingsService class:

We’d like to move the logic that sends greetings by email to a different class in order to decouple the infrastructure logic from the domain logic.

The problem is that we can’t move the protected sendMessage method because, if we do it all the tests would fail.

This method was introduced by applying the Extract & Override Call^[2] dependency-breaking technique in order to test BirthdayGreetingsService, and it’s being overridden in our tests.

That seam allowed us to spy which emails were going to be sent, and to avoid the undesired side-effect of actually sending emails every time we run the tests.

If we want our tests to allow us moving the logic that sends the email to a different class, we’ll first need to move the seam to that class. Let’s see how we can perform this Move seam to delegate refactoring safely.

Mechanics.

We’ll do a parallel change of the tests in order to move the seam to the delegate where we’d eventually like to move the code. These are the steps to do it:

1. Expand.

a. Create the delegate class if it doesn’t exist yet, and initialise a field with its type in the constructor of the class being tested. Use Parameterize Constructor^[3] to inject the delegate in the class.

b. Copy the overridden method in the delegate and make it public^[4].

c. Subclass & Override^[5] the delegate class in the tests, and do in its overridden method exactly what the class under test overridden method was doing (stubbing or spying).

d. Inject an instance of the delegate’s subclass in the class under test.

Let’s see how the code of our example looks at the end of the expand phase:

a. This is the code of the delegate we created, EmailGreetingsSender, where we copied the sendMessage method:

b. This is the change we did in BirthdayGreetingsService, by introducing an EmailGreetingsSender field, initialising it in the constructor and applying Parameterize Constructor in this case using the Introduce Parameter refactoring which was automated by the IDE we were using^[6]:

c. Finally this is the change in the setUp method of the tests of BirthdayGreetingsService. Notice how we are applying Subclass & Override to EmailGreetingsSender’s sendMessage method, and how both seams do exactly the same:

2. Migrate.

Change the production code so that it calls the public method in the delegate instead of the originally overridden protected method. The tests should keep passing.

In our example, the migration phase involves just changing the place in BirthdayGreetingsService where the protected sendMessage method is called, So that it calls the sendMessage method in EmailGreetingsSender:

sendMessage(msg); changes to greetingsSender.sendMessage(msg);

All the tests should keep passing after doing that change.

3. Contract.

In this phase we delete all the resulting dead code.

First, we delete the dead code in the tests: the method that was overriding the seam, and, if possible, also the subclass of the class under test used for testing purposes. After doing these the tests should still pass.

Finally, we also remove the dead code in production: the overridden protected method that originally provided the seam.

In our example, we first delete the anonymous class that was overriding BirthdayGreetingsService for testing purposes, which it’s not needed anymore.

And then, delete the protected sendMessage method in BirthdayGreetingsService.

After applying this parallel change to the tests, the seam is now located in the delegate, and we can freely move the code that uses the seam.

Now the tests (the violet eye) are coupled to the seam in the delegate and we can freely move there the logic that sends greetings by email.

Conclusion.

We have described the Move seam to delegate refactoring mechanics. We hope this refactoring technique might be useful to you when working with seams in legacy code.

Acknowledgements

I’d like to thank Fran Reyes for revising and giving feedback about this blog post.

Finally, I’d also like to thank Engin Akyurt for the photo.

Notes

[1] Generally, when we break dependencies to get tests in place, we do it for either sensing or separating:

Sensing is about being able to know values that our code computes, but we can’t access.
Separating is about avoiding side-effects that don’t even let us run a piece of code in a test harness.

The seam in the example we use throughout the post is used to sense the emails sent by the code.

[2] Michael Feathers describes the Extract & Override Call dependency-breaking technique in chapter 25 of his book, Working Effectively with Legacy Code. It’s a variation of the Subclass & Override dependency-breaking technique^[5].

[3] Parameterize Constructor is another dependency-breaking technique described in Working Effectively with Legacy Code, in which you safely add a new parameter to a constructor in order to introduce an object seam.

[4] If the protected method has some dependencies on other fields or methods of the class, you’d need to do more work. However, these dependencies on the class are likely a sign that the extraction to create the seam was too coarse-grained. A finer-grained seam with just the code that calls the awkward dependency and that receives any required class data as parameters would be much safer.

[5] Subclass & Override is another dependency-breaking technique described in Working Effectively with Legacy Code, in which we use inheritance to override the behaviour of a method (our seam) in order to sense or separate, without affecting the behaviour we’d like to test. In the example we use throughout the post, we used it to sense the emails sent by the delegate.

[6] You can find an explanation of how to apply this automated refactoring with IntelliJ Idea in this video.

Experiencia en el AOS Tenerife 2024

2024-05-07T07:00:00+00:00

El 4 y 5 de mayo algunos de mis compañeros y yo estuvimos en Agile Open Space que tuvo su edición en Tenerife. La experiencia del evento fue fantástica ya que la organización puso todo su empeño para que fuera todo un éxito. Las propuestas, el espacio, la comida y las sorpresas fueron un acierto.

Los que fuimos de Codesai estuvimos activos participando, proponiendo charlas y debates.

Mi compañero Toño de la Torre propuso una charla “polémica” a la que llamó “Agile se ha disuelto ¿Qué quedó de Agile?” que tuvo bastante acogida y en la que hubo debates y puntos de vista diferentes y enriquecedores.

Yo me animé a hacer tres propuestas. La primera fue “¿Qué historias te cuentan?” en la que quería que hablásemos sobre las historias de usuario y si estás eran más escritas que contadas. Ya hace tiempo que percibimos que la conversación es la gran ausente en las historias de usuario, lo cuál atenta contra su propia esencia. Además también hablamos de heurísticas que nos pueden ayudar a que las historias de usuario no se nos atraganten.

La segunda fue “El Legacy que nos acecha” en la que intenté iniciar un debate sobre cómo nos enfrentamos con ese gran reto desde tres aspectos: la aptitud, las técnicas y la estrategia. Los asistentes estuvieron muy colaborativos aportando diferentes puntos de vista sobre lo que es Legacy, modos de atacar el legacy y diferentes experiencias con el mismo.

En la tercera y última titulada “Cómo las prácticas técnicas nos ayudan a eliminar waste” exploramos cómo diferentes prácticas técnicas nos ayudan a evitar los siete tipos de waste descritos en Implementing Lean Software Development. Este ejercicio es una parte de una introducción a Lean que hemos dado en la primera edición del Programa de Mentoring Intensivo en Prácticas Técnicas que estamos haciendo con AIDA. Para guiar y explicar algunos aspectos partí de estas slides.

Finalmente me gustaría agradecer a todos los asistentes al AOS Tenerife su participación y especialmente a la organización por todo su esfuerzo y generosidad.

Si quieres saber como fue en el AOS de Tenerife sigue el hashtag en twitter o en LinkedIn.

Classifying dependency-breaking techniques

2024-03-27T07:00:00+00:00

In his book Working Effectively with Legacy Code, Michael Feathers describes 24 dependency-breaking techniques. They are listed in chapter 25.

We are using the following classification of dependency-breaking techniques:

Classification of dependency-breaking techniques.

We think that this classification may create meaningful chunks of information that will help us learn, understand and remember these dependency-breaking techniques better. These chunks give more cohesion to the material than the list.

We created this classification, after reading the descriptions of the techniques, and thinking about how we could teach them. We think that some techniques are more related to each other than to other techniques, but those relationships were not explicitly expressed in the structure of chapter 25 of the book. Moreover, some techniques are useful only for some languages.

This classification is part of a legacy code training that we are launching next month.

Would you classify the dependency-breaking techniques in a different way? Any feedback and suggestions about this classification would be more than welcome.

I hope this might be useful for you.

Acknowledgements

I’d like to thank Fran Reyes for preparing this legacy code training with me.

Finally, I’d also like to thank Vinur for the photo.

The Crazy Portfolio kata, a short kata to practice breaking dependencies, testing and refactoring legacy code

2024-03-21T07:00:00+00:00

We created this short legacy code kata to practice dependency breaking, testing and refactoring techniques. It’s called the Crazy Portfolio kata.

It is part of a legacy code course that we are launching next month. We’re currently working on this kata on the deliberate practice sessions we are doing with Audiense’s developers.

The kata has many things to make legacy-code lovers happy: side effects, nasty nested conditionals, no documentation, lots of duplication, dead code and interesting boundary conditions.

This is the TypeScript’s code to whet your appetite:

The Crazy Portfolio Legacy kata can be used to practice techniques, such as, dependency breaking, characterization testing, structural testing, approval testing, mutation testing and, of course, refactoring.

You can find the whole code in this repository: Crazy Portfolio kata. Soon, we’ll add versions for other languages. Pull requests are more than welcome.

I hope you enjoy solving it.

Acknowledgements

I’d like to thank Fran Reyes for facilitating this kata with me.

Also thanks to Audiense’s developers for being the beta testers of this kata. It is always a pleasure to work with you.

Finally, I’d also like to thank Josue Miranda for the photo.

Using code smells to refactor to more OO code (an example with temporary field, solution sprawl and feature envy)

2024-03-14T05:00:00+00:00

Introduction.

During our deliberate practice program^[1], we were working on a modified version of the CoffeeMachine kata ^[2]. After some sessions we had implemented the following functionality documented by the tests:

Tests describing the behaviour of the coffee machine.

which was implemented by the following code in the CoffeeMachine class:

and the OrderProcessing class:

Most of the logic to create the Order that is later passed to the DrinkMakerDriver has been moved to the OrderProcessing class. This class originally started as an OrderBuilder (see Builder design pattern) with the idea that it would gradually build an Order as the user selected how they wanted their drink to be. At some point, we decided not to use the name of the pattern to name the class, and we came up with the idea of calling it OrderProcessing, although, in essence, it was still a builder.

One thing that didn’t fit, though, was that there was a case of Temporary Field code smell in OrderProcessing: the value of the selectedDrink field was not being set on the constructor of the class and it remained undefined until the selectDrink was called. Moreover, the value of the selectedDrink field is used to control the flow of the processing of an Order because an Order can’t be placed until a drink has been selected (if the user tried to make a drink before selecting it, the user was notified that it was not possible and a drink should be selected first). Besides, not all drinks can be extra hot. There was no clear way to remove this Temporary Field.

A Temporary Field code smell is usually telling us that there might be a missing abstraction, but knowing which one is not so easy. In this case, there were two separate stages in the processing, one before selecting a drink and another one after selecting the drink. Those two stages of the order processing might be modelled using the following state machine:

State machine for the processing of an order.

See how the transition between the first state and the second one is caused by the first time a drink is selected, and the transition from the second state to the first one is caused by making a drink.

In the code part of the order processing logic was leaking into the makeDrink method of the CoffeeMachine class instead of being instead of being wholly contained in the OrderProcessing class:

Notice how we had to add the isOrderReady predicate to ask OrderProcessing if an order is ready to be placed. This predicate was required to alleviate the missing abstractions representing the two phases of the order processing we mentioned before. makeDrink was also using other two methods of OrderProcessing: the isThereEnoughMoney predicate to ask if there’s enough money to pay for the order, and the createOrder method of OrderProcessing to create an Order object. So, there was a Feature Envy code smell because the makeDrink method manipulated more features of the OrderProcessing class than from its own.

Besides, since the responsibility of making a drink was sprawled across the CoffeeMachine and OrderProcessing classes, there was a Solution Sprawl code smell^[3] as well.

OrderProcessing, even though it was an interesting abstraction, was not well designed.OrderProcessing was not an honest name yet.

The refactoring.

Tell don’t ask.

We wanted to refactor our original code to an explicit state machine using the state design pattern. The problem to do that was to find a common interface for both states.

The interface of OrderProcessing was in the way. OrderProcessing had some methods following a typical builder’s interface (some methods that incrementally configure the object that we want to create plus a method that returns the built object) and the two predicates that we mentioned before, isOrderReady and isThereEnoughMoney, that were needed because createOrder could not be called without having previously selected a drink and having enough money.

A possible option that could have been considered was to continue insisting on the idea of a builder and return different types depending on the moment in which createOrder was being called. Those types would have represented either a valid order, or an invalid order due to different reasons (not selected drink or not enough money). There are different ways to implement this option, but all of them except using some kind of polymorphism on the returning type would complicate the client of OrderProcessing, CoffeeMachine, with checks on the returned type that would result in a Special Case code smell and thus a violation of the Liskov Substitution principle. A solution using polymorphism on the returning type would avoid the Special Case code smell, but will continue to suffer from the Solution Sprawl code smell because the processing of an order would be sprawled among several classes.

In order to get to a better solution, we needed to first fix the Feature Envy code smell in the makeDrink method of the CoffeeMachine class. Once responsibilities were assigned to the right objects, the other code smells would become easier to fix.

If you think about the style of the code in makeDrink is an “ask” style in which we’re pulling all the information to one place in order to decide what to do. A better way of structuring this code would be to follow a “Tell don’t ask” style ^[4]. So we moved the makeDrink method to the OrderProcessing class. Notice how to do that we had to pass the DrinkMakerDriver collaborator as a parameter to the new method. We also renamed the makeDrink method to placeOrder.

This is the code of theCoffeeMachine class after this refactoring:

and this is the code of the OrderProcessing class:

We think that the resulting code after this refactoring has several benefits:

It concentrates all the responsibility of processing an order in the OrderProcessing class which removes the Solution Sprawl code smell.
We removed all the predicate methods that were asking about the state of OrderProcessing objects from its interface. Those methods are now private in the OrderProcessing instead of public. No more Feature Envy code smell.
The creation of an Order is now a private detail of OrderProcessing instead of part of its public interface. We think this makes sense because creating an Order object is just a part of processing an order.
Now OrderProcessing has an interface that makes sense for all the stages of the order processing. Notice how we made the placeOrder method return an OrderProcessing object. This allows placeOrder to reset the order processing.

Introducing missing abstractions to get to the State design pattern.

This new design following the “Tell don’t ask” style enabled us to refactor to the State design pattern. To do it we introduced two classes that represented the two states of processing an order, and had the same interface that OrderProcessing: InitialOrderProcessing and ReadyToPlaceOrderProcessing. See the state diagram below:

State machine for the processing of an order.

This is the code of the two new classes:

Notice how:

The temporary field code smell was removed because the selectedDrink field does not exist in InitialOrderProcessing. Now the field only appears in the other variant of ‘OrderProcessing, ReadyToPlaceOrderProcessing, and it’s assigned a value in the constructor of the class.
Each state of the order processing has its own behaviour and only the required private methods are included in each class. This resulted in more cohesive classes.
The isOrderReady method disappeared because the need for this check was not necessary any more. Passing to polymorphism eliminated it.
The transition from the InitialOrderProcessing state to the ReadyToPlaceOrderProcessing state is provoked by calling the selectDrink method on InitialOrderProcessing, and the transition from the ReadyToPlaceOrderProcessing to the InitialOrderProcessing state is provoked by calling the placeOrder method on ReadyToPlaceOrderProcessing, as indicated in the state machine diagram.

Finally, this is the code of the OrderProcessing class which became an abstract class that contained only the code for the setters shared by the two variants of OrderProcessing. Notice how we made abstract the non shared setters and the placeOrder method. We also used protected accessors to encapsulate OrderProcessing state and avoid the Inappropriate Intimacy code smell ^[5]:

All three classes are contained in the same module and only OrderProcessing is exported, so that its different states are hidden from its OrderProcessing clients.

Conclusions.

We showed how detecting some code smells and trying to remove them led us to a more cohesive and less coupled design.

The initial code presented several code smells. We started by trying to remove the temporary field code smell but we didn’t find an easy way to remove it. The real obstacle to removing it was caused by other code smells: Feature envy and Solution Sprawl.

Once we removed those smells moving to a more “Tell, don’t ask” style we had the whole responsibility of processing the order in one place and an interface that might be valid for all the different phases of the processing. Then it was easy to move to the state design pattern.

The final code is more cohesive than the original one and explicitly represents the different phases of the order processing.

Acknowledgements

I’d like to thank to my Codesai colleagues, Fran Reyes and Alfredo Casado for giving me feedback about several drafts of this post.

Also thanks to Audiense’s developers for all their work they put in the deliberate practice sessions. I learn a lot with you.

Finally I’d also like to thank Masud Allahverdizade for his photo.

Notes

[1] We are giving this service to several companies.

[2] During our deliberate practice program we use a modified version of the kata in which we introduce other iterations which introduce interesting changes that force some preparatory refactorings or help to apply other concepts.

[3] Solution Sprawl is a code smell described by Joshua Kerievsky in his Refactoring To Patterns book: “when code and/or data used to perform a responsibility becomes sprawled across numerous classes”. Solution Sprawl and Shotgun Surgery address the same problem, a Single Responsibility Principle violation or lack of cohesion, but they are detected differently. Solution Sprawl is detected by observing it in the code, while Shotgun Surgery is detected when trying to change the code.

[4] I like how Christian Clausen calls code using this “Tell don’t ask” style, ”push-based code”, as opposed to a “pull-based code” or code using “ask” style that pulls all the data to a place, does all the calculations, and then delivers the results to somewhere else. Martin Fowler’s Getter Eradicator post goes deeper into the “Tell don’t ask” style and the Feature Envy code smell, getting to the interesting rule of thumb that “things that change together should be together”.

[5] The Inappropriate Intimacy code smell is more general than accessing private members. It is about one class depending on the implementation details of another. Some examples of Inappropriate Intimacy are, for example, knowing that two public methods need to be called in a certain order because of some private implementation detail, or accessing a property to make sure that an object that loads lazily is initialised. See Jason Gorman’s video about this code smell.

Photo by Masud Allahverdizade.

"Split or condition in if" refactoring in TypeScript

2022-12-30T05:00:00+00:00

In a previous post we documented the Split or condition in if refactoring. This refactoring works fine for most languages. Unfortunately, it may occasionally present some problems in TypeScript because of how its compiler works.

After applying the Split or condition in if refactoring, the resulting code will contain duplication, and there may be obsolete if statements containing either unreachable code or code that is always executed, that we will clean.

If the resulting code contains any if statement whose boolean condition always evaluates to false, the TypeScript compiler will emit a TS2367 error, even though the code is functionally correct. We show an example of this problem in the following figure.

Compiler error when a boolean expression always evaluates to false.

In these cases, the code would not compile again, and as a consequence, the test won’t pass until we remove all the boolean conditions that always evaluate to false or indicate the compiler to ignore them using @ts-ignore or @ts-expect-error. This might be ok if there are only a few TS2367 errors. If not, cleaning those expressions will take too much time editing without having any feedback from the tests.

Revised mechanics for TypeScript.

From TypeScript 3.7 onward, we can add the @ts-nocheck rule to the top of TypeScript files to disable semantic checks (before that version, @ts-nocheck only worked for JavaScript files).

Using TypeScript’s @ts-nocheck rule will help us getting a shorter feedback cycle again, when cleaning redundant code resulting from applying the Split or condition in if refactoring that contains TS2367 errors.

We only need to slightly modify the original Split or condition in if refactoring mechanics:

Add the @ts-nocheck rule to the top of TypeScript files to disable semantic checks.
Apply the original Split or condition in if refactoring .
Remove obsolete if statements in small steps while being able to get feedback from the tests at any time.
Remove the @ts-nocheck rule to enable semantic checks again.

In the following video, we show an example of how using @ts-nocheck allows us to be able to keep refactoring the code in small steps after applying the Split or condition in if refactoring.

Conclusion.

We described a problem that TypeScript developers will find when the code resulting after applying the Split or condition in if refactoring contains any boolean condition that always evaluates to false which will produce TS2367 errors, and we provided a way to fix it. Following revised Split or condition in if refactoring mechanics that we proposed, you will be able to keep refactoring in small steps to remove unreachable code left after applying the Split or condition in if refactoring even when there are TS2367 errors.

We hope this revision of the Split or condition in if refactoring would be useful for TypeScript developers.

Acknowledgements.

I’d like to thank Fran Reyes for recording the Split or condition in if refactoring video in this post, and for giving me feedback on the contents of this post.

I’d also like to thank Yuliya Kota for her photo.

References

Articles

Photo by Yuliya Kota.

Caring Work and where to find it: concerns mechanism

2022-11-30T05:00:00+00:00

Caring work.

In our previous post about caring work we described how the concept of caring work^[1] had been very useful for us in the coaching work we did with several teams during all of 2019 and a big part of 2020.

We used the concept of caring work to redefine the very concept of value in our client, so that producing features as quickly as possible (productive work) was not the only type of work considered valuable, and they started to also see value in work concerned with keeping the health of the ecosystem composed of the code, the team and the client (caring work), so that it can continue evolving, being habitable for the team and producing more value for its users. They understood that aside from productive work, we also needed to devote energy and time to caring work.

How did we apply the concept of caring work?

The way to apply caring work in a team highly depends on the team’s context. Do not take this as “a recipe for applying caring work” or “the way to apply caring work”.

In this post we mostly talk about our experience working with Lifull Connect’s Barcelona B2B team which was the first team we worked with inside Lifull Connect. We later introduced small local variations to adapt these ideas and mechanisms to the context of other Lifull Connect’s teams, and to their coaches.

We took two main decisions^[2]:

To protect a given percentage of time/effort in every iteration for caring work. The specific distribution of time/effort between the two types of work depended on the context of each of the teams we worked with^[3].
Only developers could decide which caring work was needed.

How did we identify caring work?

"A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it." — Frank Herbert

A complex system is in constant flux, and any action may change the system in unpredictable ways. So after any change^[4] we need to observe the new dynamics that start to form and apply suitable corrections. But, how could we sense the dynamics of the system in order to adapt to it?

We decided to use a concerns mechanism to detect system health problems and try to solve them as we went.

The concerns mechanism.

A concern might be anything someone working on the system doesn’t understand, doesn’t agree with, thinks that might be problematic, or thinks that might be changed to improve the system’s sustainability. The concept of a concern^[5] was described by Xavi Gost in his talk Consensus-driven development (CDD)^[6].

Consensus-driven development is based on the premise that developing software is a team endeavour, and on seeing the current system as an implicit representation of the real team’s consensus about what they are currently developing. This consensus will evolve to adapt to contextual changes. Not acknowledging this tacit consensus may cause problems in the team’s dynamics.

The concerns mechanism we used follows the process indicated in the next figure:

Concerns mechanism.

This mechanism gives the team a way to raise concerns about the current team’s consensus so they can be discussed. It also helps to make the actual team’s consensus about the system explicit.

We find the concerns mechanism very interesting because it:

Fosters technical conversations.
Serves as a space to manage conflicts and reach new agreements that make the current team’s consensus explicit.
Helps to transmit knowledge.
Detects waste in the part of the software value stream comprising development to delivery.

We had found a way to sense the dynamics of the system.

The concerns mechanism is a kaizen process enriched with information from the people actually involved in the actual work. It helps to apply several Lean Software Development principles, such as, Eliminate waste, Amplify Learning and Empower the team.

Our goal was not only to improve the developers’ experience by creating an environment, practices, architecture and infrastructure in which the team members could learn and work better and with less stress^[7], we also wanted to develop the team’s technical skills.

The concerns mechanism can be a great coaching tool. Since the technical coaches were outnumbered by the team members^[8], the concerns mechanism provided us a space to solve team members’ doubts and raise our own concerns about design decisions. This made it an additional after-the-fact coaching tool, which complemented other live coaching activities, such as, the ensemble and pair programming sessions we had with the team.

In this coaching context, the discussion of concerns made more emphasis on learning than on reaching consensus, especially at the beginning of our work with the team. Later, as the team was more mature, the emphasis changed. The idea was that once we leave, the team could keep on using the concerns mechanism on their own to reach consensus and detect caring work.

Concerns tool summary.

Concerns collection and prioritisation.

During an iteration, the team raised concerns by describing each of them in cards that were added to a separate board dedicated to this purpose. Below you can see the concerns board of one the teams:

Concerns board.

At the end of the iteration, we had a fifteen-to-thirty-minutes meeting in which we prioritised the new concerns on the Pending to prioritize column. We used three possible levels of priority: high, medium or low^[9].

To prioritise a concern, after a brief explanation of the concern followed by some questions to clarify possible doubts, the team members responded in parallel to the question of “how important do you think discussing this particular concern is?”.

A variant of the planning poker dynamics with only three cards with values 1, 2 or 3, which corresponded to low, medium and high priority, respectively^[10] helped us reach consensus about the priority. We used PlanITPoker but any similar tool will do.

Concerns discussion and outcomes.

Once a week we held a one-hour meeting to discuss the concerns with higher priority. For each concern card, the team members that had raised it, explained further the concern’s description, and answered any doubts that the rest of the team might have about the concern. Sometimes, other team members provided information about similar problems they had observed in other parts of the system.

After understanding the concern better, we discussed it for a while to try to determine its possible causes and effects, then, we proposed and discussed possible ways of solving or, at least, mitigating the concern. In these discussions, we tried to reach consensus and good enough/pragmatic ways to address each concern. In order to foster the team’s sense of agency and autonomy, we focused on what it could control and change at any given moment. However, sometimes, this was not enough and we had to escalate the concerns to higher levels, with the intention of somehow modifying organisational constraints or policies that were affecting the team.

Depending on the specific concern, the team obtained different outcomes from its discussion (often several of them at the same time):

a. Learning about new concepts (code smells, antipatterns, design principles, patterns, techniques, tools, etc). Sometimes, the coaches helped the team, and other times the team members taught each other.

b. Reflecting on the current consensus of the team, thus, making it more explicit and transmitting it to everyone.

c. Evolving the current consensus of the team by getting to new agreements or revising old ones.

d. Detecting caring work to be done. The detected caring work was recorded and described in caring tasks cards that we collected in a different board. The caring tasks might be very varied depending on the nature of concerns that originated them. Some consisted of research in the form of experiments^[11], others resulted in internal trainings, and others were efficiency improvements of any kind (paying technical debt in code, infrastructure or architecture, writing documentation, improving the ubiquitous language, etc). Anything that we needed to keep our system healthy.

Concerns discussion outcomes.

In the following figure we show an example of the modification of a previously existing agreement after discussing a concern.

Example of reaching a new consensus after discussing a concern.

Notice how we recorded the new agreement as a comment in the Trello card. We think that it might be more useful to document these agreements that make the consensus explicit in Consensus Records, (CRs) that might follow a format similar to the Architectural Decision Records, (ADRs).

The following figure shows a caring task produced after discussing a concern about an action that had accumulated too many collaborators, and recorded how the team had decided that they could reduce the number of collaborations and remove some duplication:

Example of a caring task originated by the discussion of a concern.

Why did we decide to discuss concerns in a dedicated meeting instead of using the retrospective?

Retrospectives are also a meeting that provides a space to reflect and learn, in order to improve the efficiency of a team. They ideally include all the people that might help finding better ways of delivering value (product, tech, ux…). Why not use them, then?

We’d like to start by stating that by no means the concerns meeting should substitute retrospectives. These meetings have different, though sometimes a bit overlapping, scopes. We think that they are both useful and should be complementary.

Still, there are reasons why we think that concerns should be discussed in a different meeting than the retrospective.

On one hand, there’s the matter of who can best contribute to the discussion and of not wasting people’s time in unnecessary meetings. As we described earlier, concerns are a way to detect waste in the part of the software value stream comprising development to delivery. This means that most concerns are technical in nature, so for most of the discussions there would be no point in having non technical people in the meeting as this would waste their time. We think that this is true, regardless of having or not a healthy dynamic between product and engineering.

On the other hand, we wanted to protect the team’s autonomy to decide which caring work to do because they are the ones that work with the system and know where the friction and inefficiencies are happening, and have better information to fix them. We think that this makes sense from the point of view of the lean principle of Empowering the team. Besides, the DevOps movement also defends that engineering should spend the time devoted to caring work as they see fit^[12] (which for them amounts to at least 20% of the team’s time).

Besides, the cultural dynamic around the B2B team when we started working with them, was characterised by a strong power imbalance between the product and engineering teams which left the latter little autonomy and agency. In order to create a space safe from this vicious dynamic, we decided to discuss the concerns in a separate meeting in which only the members of the engineering team could participate. This strong boundary fostered the autonomy of the engineering team and made caring work possible^[13].

Having said that, some concerns needed a different approach.

Concerns that went beyond what the engineering team could control and change, or that required knowledge that the members of the team didn’t have yet. In those cases, we either invited whoever could provide the needed information to the concerns meeting, or took the specific concern to the retrospective.
Concerns caused by blocks due to how the company organised the teams. These kinds of problems related to Conway’s Law are very hard to fix, and their symptoms can at best be mitigated within the team. We took those concerns to the retrospective as a first step to gather more information before escalating them.

Summary·

In this post we have explained how we applied the concept of caring work in several teams of Lifull Connect for more than a year. Remember that the application of this concept depends on the team’s context. Do not take this as “a recipe for applying caring work” or “the way to apply caring work”.

We, first, showed how we created a safe space for caring work by devoting a given percentage of time/effort to it in every iteration, and by giving autonomy and agency to developers to decide which caring work was needed.

Then we showed how we applied the concerns mechanism to identify caring work and improve consensus about the system and communication in the team. The concerns mechanism also proved to be a great after-the-fact coaching tool that complemented other live coaching tools we were using.

We also described how we collected, prioritised and discussed concerns each iteration, and talked about the different outcomes we got from discussing concerns.

Finally, we gave our reasons for using a separate meeting to discuss concerns instead of using the retrospective.

Acknowledgements

Thanks to Lifull Connect’s Barcelona B2B team, for all the effort and great work they did to make the concerns mechanism work for them. That great work made it much easier for other teams in Lifull Connect to start applying the idea of caring work with the help of other Codesai coaches.

Also thanks to my Codesai colleagues, Antonio de la Torre, Rubén Díaz, Dani Ojeda and Fran Reyes, for giving me feedback about several drafts of this post.

Finally I’d also like to thank Karolina Grabowska for her photo.

Notes

[1] Idea from economic studies from a gender perspective where caring work is defined as “those occupations that provide services that help people develop their capabilities, or the ability to pursue the aspects of their lives that they value” and “necessary occupations and care to sustain life and human survival”.

[2] We didn’t know it when we took these decisions but they were aligned with the recommendations of the DevOps movement, as you can see in the following quotes:

“We will actively manage this technical debt by ensuring that we invest at least 20% of all Development and Operations cycles on refactoring, investing in automation work and architecture and non-functional requirements (NFRs, sometimes referred to as the “ilities”), such as maintainability, manageability, scalability, reliability, testability, deployability, and security.” — The DevOps Handbook

"Invest 20% of cycles on those that create positive user-invisible value” from The DevOps Handbook.

[3] The first team we worked with devoted 20% of their time to caring work and 80% to productive work. Other teams that later worked with us distributed the work in different proportions (never less than 20% to caring work).

Note that 20% is the minimum recommended in The DevOps Handbook to keep a healthy system:

The DevOps Handbook authors quote Marty Cagan’s book Inspired: How To Create Products Customers Love.

According to Cagan, “Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit.”

“Cagan notes that when organizations do not pay their “20% tax,” technical debt will increase to the point where an organization inevitably spends all of its cycles paying down technical debt.” — The DevOps Handbook

“By dedicating 20% of our cycles so that Dev and Ops can create lasting countermeasures to the problems we encounter in our daily work, we ensure that technical debt doesn’t impede our ability to quickly and safely develop and operate our services in production.” — The DevOps Handbook

According to Cagan again, “if you’re in really bad shape today, you might need to make this 30% or even more of the resources. However, I get nervous when I find teams that think they can get away with much less than 20%”. This aligns with what we had to propose in some other teams we coached in Lifull Connect.

[4] With the intention of unlocking the system from its initial dynamics, we started by applying several changes to how the team worked. These initial changes were related to the change levers we had identified in the team’s dynamics. Read about them in our previous post about caring work: The value of caring, Manuel Rivero.

[5] At first, we thought we had widened Xavi’s definition of concern. In his talk, he focused mostly on concerns in code as a way to avoid blocking code reviews. Instead, we decided to raise concerns about any inefficiency or waste that we observed in the part of the software value stream comprising development to delivery. Later in a personal conversation with Ricardo Borillo, who was researching how concerns are used in the wild, we discovered that they (Xavi and Ricardo) are using concerns in the same way we are, but Xavi did not manage to transmit this in his talk because of excessively focusing on code reviews.

[6] The talk about Consensus Driven Development is in Spanish.

[7] These ideas are related to Richard Gabriel’s idea of software habitability, and Alexandru Bolboaca’s ideas in his book Usable software Design. We think, both, are in turn, based on Deming’s idea that a system has a huge influence on a person’s performance:

"A Bad System Will Beat a Good Person Every Time." — W. Edwards Deming

[8] At the beginning only Fran Reyes and I worked with Lifull Connect’s Barcelona B2B team. Even though we later got more critical mass when Antonio de la Torre, Manuel Tordesillas and Álvaro García joined the team, by that time the B2B team had already doubled in size, so we still were outnumbered.

[9] We decided to use only three levels of priority following the early three categories of triage in medicine. Some teams decided to use prioritisation models with more categories, but it resulted in a lot of confusion at the time of prioritising. We think it’s better to keep it simple and use only the three categories mentioned: high, medium and low.

[10] We like the poker planning dynamics because it is a quick and simple diverge-and-converge collaboration method that helps reduce information cascades in the team due to power differential and anchoring.

[11] Experiments consisted of researching alternative solutions or tools that we might use to address a concern. We called them experiments to explicitly distinguish them from spikes, so that we avoided the usage of caring work time for spikes which, we think, should be used to reduce uncertainty in features.

[12] They don’t use the term caring work, but they mean the same, “not working on features”.

The DevOps Handbook quotes Marty Cagan arguing about the kind of work that the team might do in that 20%:, “Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit. They might use it to rewrite, re-architect, or refactor problematic parts of the code base… whatever they believe is necessary to avoid ever having to come to the team and say, ‘we need to stop and rewrite [all our code].”

[13] Later this strong boundary was exported to other teams due to similar power dynamics, but this doesn’t mean that this might be necessary in every context. Depending on the culture and people involved the retrospective might be enough.

References

Books

Articles

The value of caring, Manuel Rivero

Talks

Podcasts & Interviews

Photo by Karolina Grabowska in Pexels.

On code smells catalogues and taxonomies

2022-11-05T05:00:00+00:00

This post is an English translation of the original post: De taxonomías y catálogos de code smells.

Index.

Introduction: code smells and refactoring.
Martin Fowler: code smells and catalogues.
Taxonomies.

Wake’s taxonomy 2003.
Mäntylä et al taxonomy 2003.
Mäntylä et al taxonomy 2006.
Jerzyk et al taxonomy 2022.

Jerzyk’s extended code smells catalogue.
Online catalogue.

Conclusions.
Acknowledgements.
References.

Introduction: code smells and refactoring.

Refactoring is a practice that allows us to sustainably evolve code. To refactor problematic code, we first need to be able to recognize it.

Code smells are descriptions of signals or symptoms that warn us of possible design problems. It’s crucial to detect these problems and remove them as soon as possible.

Refactoring is cheaper and produces better results when done regularly. The longer a problematic piece of code lives, the more it takes to refactor it, and the biggest friction it will add to evolve new features directly contributing to accruing technical debt. Sustaining this situation over a long period of time may have a very negative economic impact. In the worst case scenario, the code might get too complicated to keep on maintaining it.

Cost of introducing a feature over time (image from The Three Values of Software from J. B. Rainsberger).

Another, sometimes not so visible, consequence of bad software quality is its effects on developers. Less refactoring, can lead to a less maintainable code that can lead to longer times to develop new features, which, in turn, means more time pressure to deliver, which can lead us to test less, which will allow us to refactor less… This vicious circle might have a very demoralising effect.

Less refactoring vicious circle.

Understanding and being able to identify code smells gives us the opportunity of detecting design problems when they are still small and located in specific areas of our code, and, as such, are still easy to fix. This might have a very positive economic and emotional effect.

The problem is that code smells are not usually very well understood. This problem is understandable because code smells descriptions are sometimes abstract, diffuse and open to interpretation. Some code smells seem obvious, others not so much, and some might mask other smells.

Besides, we should remember that smells are only symptoms of possible design problems, not guarantees of the existence of problems. To further complicate matters, in addition to possible false positives, there are degrees to the problem that each smell represents, trade-offs between different smells and contraindications in their refactorings (sometimes “the cure is worse than the disease”).

Therefore, recognizing design problems through code smells is a subtle skill that requires experience and judgement. Acquiring this skill, which sometimes may feel like a kind of spider-sense, can take some time.

In our experience teaching and coaching teams, not being able to identify code smells is one of the greatest barriers to refactoring. Many developers do not detect design problems while they are still small and localised. What we often observe is that they don’t sense the design problems until the problems are quite large and/or have compounded with other problems, spreading through their codebase.

Code smells catalogues.

In 1999 Fowler and Beck published a code smells catalogue in a chapter of the book, Refactoring: Improving the Design of Existing Code. This catalogue contains the descriptions of 22 code smells.

In 2018 Fowler published a second edition of his book. In this new edition there are a number of changes with respect to the first, mainly in the code smells catalogue of smells and the refactorings catalogue (detailed in Changes for the 2nd Edition of Refactoring).

If we focus on the smells, which is the goal of this post, the changes are as follows:

Four new code smells are introduced: Mysterious Name, Global Data, Mutable Data and Loops.
Two code smells are removed: Parallel Inheritance Hierarchies and Incomplete Library Class.
And four code smells are renamed: Lazy Class becomes Lazy Element, Long Method becomes Long Function, Inappropriate Intimacy becomes Insider Trading, and Switch Statement becomes Repeated Switches.

There are 24 code smells in total. Even though they usually have catchy and memorable names, it’s difficult to remember such a long list.

How could we better understand code smells? How could we remember them more easily?

In this post, and some later ones, we will talk about strategies to better understand and remember code smells.

Organisational strategies.

Organising and manipulating information, seeing it from different points of view, can help us understand and remember it better. Taxonomies are a type of organisational strategy that allows us to group study material according to its meaning. This helps to create significant groupings of information or “chunks” that will facilitate learning.

As we mentioned, the 2018 Fowler catalogue is a flat list that does not provide any type of classification. Although, reading the descriptions of the code smells, and the motivation sections of the different refactorings, we can glimpse that some smells are more related to each other than to other smells, these relationships are not expressed explicitly and remain blurred and dispersed in different parts of the book.

The use of taxonomies to classify similar code smells can be beneficial to better understand and remember code smells, and recognize the relationships that exist between them.

Taxonomies.

There have been different attempts to classify code smells according to different criteria. The most popular classification is that of Mäntylä et al 2006 but it is not the first one. Below we will show some taxonomies that we consider quite interesting.

Wake 2003.

Wake in his book, Refactoring Workbook, describes 9 new code smells that did not appear in Fowler’s original catalogue: Dead Code, Null Check, Special Case, Magic Number, Combinatorial Explosion, Complicated Boolean Expression, and three related to bad names: Type Embedded in Name, Uncommunicative Names and Inconsistent Names.

Wake explicitly classifies code smells by first dividing them into two broad categories, Smells within Classes and Smells Between Classes, depending, respectively, on whether the code smell can be observed from within a class or whether a broader context needs to be considered (various classes). Each of these categories is divided into subcategories that group code smells based on where they can be detected. This classification criterion, later called “occurrence” by Jerzyk, answers the question: “where does this code smell appear?”.

Following this “occurrence” criterion Wake finds 10 subcategories.

Within the category of Smells within Classes we find the following subcategories:

Measured Smells: code smells that can be easily identified with simple length metrics.
Names: code smells that create semantic confusion and affect our ability to create mental models that help us understand, remember, and reason about code.
Unnecessary Complexity: code smells related to unnecessary code that adds mental load and complexity. Dead code, YAGNI violations, and accidental complexity.
Duplication: developer’s nemesis. These code smells generate more code to maintain (cognitive and physical load), increase error proneness, and make it difficult to understand the code.
Conditional Logic Smells: code smells that complicate conditional logic making it difficult to reason about and change, and increasing error proneness. Some of them are weak substitutes for object-oriented mechanisms.

The subcategories within the Smells between Classes category are:

Data: code smells in which we find either pseudo objects (data structures without behaviour), or we find that some missing abstraction is missing.
Inheritance: code smells related to misuse of inheritance.
Responsibility: code smells related to a bad assignment of responsibilities.
Accommodating Change: code smells that manifest when we encounter a lot of friction when introducing changes. They are usually caused by combinations of other code smells.
Library Classes: code smells related to the use of third-party libraries.

Wake’s taxonomy (new code smells appear in green).

Wake presents each smell in a standard format with the following sections: Smell (the name and aliases), Symptoms (clues that may help detect it), Causes (notes on how it may have generated), What To Do (possible refactorings), Benefits (how the code will improve by removing it) and Contraindications (false positives and trade-offs). In some cases, he adds notes relating the code smell to design principles that might have helped to avoid it.

The book also contains many practical exercises and very useful tables (symptoms vs. code smells, smells vs. refactorings, reverse refactorings, etc.) and exercises that relate code smells to other concepts such as design principles or design patterns.

We highly recommend reading this book to delve into the discipline of refactoring and better understand when and why to apply the refactorings that appear in Fowler’s catalogue.

Although we also refer to to the rest of the taxonomies that we talk about in this post, the content about code smells in our course Code Smells & Refactoring is mainly based on Wake’s taxonomy seasoned with a bit of our own experience.

Mäntylä et al 2003.

In this taxonomy, code smells are grouped according to the effect they have on code (the type of problem, what they make difficult or the practices or principles that they break). This classification criteria is called “obstruction” by Jerzyk 2022.

The original classification from 2003 (A Taxonomy and an Initial Empirical Study of Bad Smells in Code) is comprised of 7 code smells categories: Bloaters, Object -Orientation Abusers, Change Preventers, Dispensables, Encapsulators, Couplers and Others.

Mäntylä et al taxonomy 2003.

This is how they define each of the categories:

Bloaters: this category of smells represents something in the code that has grown so large that it can no longer be handled effectively.
Object-Orientation Abusers: this category of smells relates to cases where the solution does not fully exploit the potential of object-oriented design.
Change Preventers: this category refers to code structures that make it very difficult to change the code.
Dispensable: these smells represent something unnecessary that should be removed from the code.
Encapsulators: this category has to do with communication mechanisms or data encapsulation.
Couplers: these smells represent cases of tight coupling, which goes against object-oriented design principles
Others: this category contains the remaining code smells (Comments and Incomplete Library Class) that did not fit into any of the previous categories.

In their paper, Mäntylä et al discuss the reasons why each code smell is in a given category and not another, although they admit that some of them could be classified in more than one category.

Mäntylä et al 2006.

In 2006 Mäntylä et al published another paper (Subjective evaluation of software evolvability using code smells: An empirical study) in which they revised their original classification from 2003.

In this new version, they eliminated the Encapsulators (moving the Message Chains and Middle Man smells to the Couplers category) and Others (Comments and Incomplete Library Class disappear from the taxonomy) categories, and moved the Parallel Inheritance Hierarchies code smell from the Object-Orientation Abusers category to the Change Preventers category.

This version of their taxonomy is the one that has become most popular on the internet (it can be found on many websites, courses and posts), probably due to the greater accessibility (readability) of the summary of the paper that appears on the web: A Taxonomy for “Bad Code Smells”.

Mäntylä et al taxonomy 2006.

What is interesting is not so much the discussion of which category each smell should fall into, but rather to start thinking that a given smell can have different types of effects on the code and the relationships between these effects. In fact, subsequent classifications from the point of view of the effect of a smell on the code (“obstruction”) consider it more useful not to lose the information that a code smell can produce several effects. This leads to no longer considering categories as exclusive, which makes it possible that the same smell can fall into several categories.

Jerzyk et al 2022.

In 2022 Marcel Jerzyk published his master’s thesis, Code Smells: A Comprehensive Online Catalog and Taxonomy and a paper with the same title. His research on code smells had three goals:

Providing a public catalogue that could be useful as a unified knowledge base for both researchers and developers.
Identifying all the possible concepts that are being characterised as code smells and determining possible controversies about them.
Assigning appropriate properties to code smells in order to characterise them.

To achieve these objectives, they carried out a review of the existing literature on code smells up to that moment, with special emphasis on code smell taxonomies.

In the thesis 56 code smells are identified and described, of which 16 are new original proposals (remember that Wake described 31 code smells and Fowler 24 in his last review).

Descriptions and discussions of each of these 56 code smells can be found in Jerzyk’s master’s thesis.

Analysing the classification criteria of the taxonomies proposed up to that moment, Jerzyk finds three significant criteria to categorise code smells:

Obstruction: this is the criterion used by Mäntylä et al to classify smells in their taxonomy, it’s also the most popular criterion. It informs us about the type of problem that a code smell causes in the code (what they make difficult or the practices or principles that they break). In the thesis they update the Mäntylä taxonomy, adding three new groups: Data Dealers, Functional Abusers and Lexical Abusers. Below we present a mental map that shows the classification of the 56 code smells according to only this criterion.

Jerzyk taxonomy according to only the obstruction criterion.

Expanse: inspired by Wake’s taxonomy, this criterion talks about whether the code smell can be observed in a reduced context (within a class) or if a broader context (between several classes) needs to be considered. Possible categories are Within Class and Between Classes.
Occurrence: Also inspired by Wake’s taxonomy, this criterion is related to the location where (or the method by which) a code smell can be detected. Possible categories are Names, Conditional Logic, Message Calls, Unnecessary Complexity, Responsibility, Interfaces, Data, Duplication and Measured Smells.

The following table shows the 56 code smells in Jerzyk’s thesis classified according to the three criteria discussed above:

Code Smell	Obstruction	Expanse	Occurrence
Long Method	Bloaters	Within	Measured Smells
Large Class	Bloaters	Within	Measured Smells
Long Parameter List	Bloaters	Within	Measured Smells
Primitive Obsession	Bloaters	Between	Data
Data Clumps	Bloaters	Between	Data
Null Check	Bloaters	Between	Conditional Logic
Oddball Solution	Bloaters	Between	Duplication
Required Setup/Teardown	Bloaters	Between	Responsibility
Combinatorial Explosion	Bloaters	Within	Responsibility
Parallel Inheritance Hierarchies	Change Preventers	Between	Responsibility
Divergent Change	Change Preventers	Between	Responsibility
Shotgun Surgery	Change Preventers	Between	Responsibility
Flag Argument	Change Preventers	Within	Conditional Logic
Callback Hell	Change Preventers	Within	Conditional Logic
Dubious Abstraction	Change Preventers	Within	Responsibility
Special Case	Change Preventers	Within	Conditional Logic
Feature Envy	Couplers	Between	Responsibility
Type Embedded In Name	Couplers	Within	Names
Indecent Exposure	Couplers	Within	Data
Fate over Action	Couplers	Between	Responsibility
Afraid to Fail	Couplers	Within	Responsibility
Binary Operator in Name	Couplers	Within	Names
Tramp Data	Data Dealers	Between	Data
Hidden Dependencies	Data Dealers	Between	Data
Global Data	Data Dealers	Between	Data
Message Chain	Data Dealers	Between	Message Calls
Middle Man	Data Dealers	Between	Message Calls
Insider Trading	Data Dealers	Between	Responsibility
Lazy Element	Dispensables	Between	Unnecessary Complexity
Speculative Generality	Dispensables	Within	Unnecessary Complexity
Dead Code	Dispensables	Within	Unnecessary Complexity
Duplicate Code	Dispensables	Within	Duplication
“What” Comments	Dispensables	Within	Unnecessary Complexity
Mutable Data	Functional Abusers	Between	Data
Imperative Loops	Functional Abusers	Within	Unnecessary Complexity
Side Effects	Functional Abusers	Within	Responsibility
Uncommunicative Name	Lexical Abusers	Within	Names
Magic Number	Lexical Abusers	Within	Names
Inconsistent Names	Lexical Abusers	Within	Names
Boolean Blindness	Lexical Abusers	Within	Names
Fallacious Comment	Lexical Abusers	Within	Names
Fallacious Method Name	Lexical Abusers	Within	Names
Complicated Boolean Expressions	Obfuscators	Within	Conditional Logic
Obscured Intent	Obfuscators	Between	Unnecessary Complexity
Vertical Separation	Obfuscators	Within	Measured Smells
Complicated Regex Expression	Obfuscators	Within	Names
Inconsistent Style	Obfuscators	Between	Unnecessary Complexity
Status Variable	Obfuscators	Within	Unnecessary Complexity
Clever Code	Obfuscators	Within	Unnecessary Complexity
Temporary Fields	O-O Abusers	Within	Data
Conditional Complexity	O-O Abusers	Within	Conditional Logic
Refused Bequest	O-O Abusers	Between	Interfaces
Alternative Classes with Different Interfaces	O-O Abusers	Between	Duplication
Inappropriate Static	O-O Abusers	Between	Interfaces
Base Class Depends on Subclass	O-O Abusers	Between	Interfaces
Incomplete Library Class	Other	Between	Interfaces

Some of the names in the table are different from those that usually appear in the literature. The changes in naming were due to the introduction of more updated names, as is the case for, for instance, Lazy Element or Insider Trading which were previously called Lazy Class and Inappropriate Intimacy, respectively.

Several smells are new:

Some, like Afraid to Fail, Binary Operator in Name, Clever Code, Inconsistent Style, and Status Variable, are completely new ideas.
Others are concepts that already existed in the literature but had not been considered in the context of code smells before: Boolean Blindness or Callback Hell.
Three of them propose alternatives for code smells that are being questioned in the literature: “What” Comment as an alternative to Comments, Fate over Action as an alternative to Data Class, and Imperative Loops as an alternative to Loops (see Jerzyk’s thesis for more on why these original code smells are debatable).
Others generalise problematic concepts that have arisen in the literature: Complicated Regex Expression, Dubious Abstraction, Fallacious Comment, Fallacious Method Name.
Finally, a known problem (especially in the field of functional programming), which had not been considered as a code smell until now: Side Effects.

One super useful and practical thing for developers in Jerzyk’s work is an online code smells catalogue that, when published, included the 56 code smells in the thesis. This catalogue is an accessible and searchable website. On the date of publication of this post, the catalogue contains 56 code smells.

In the catalogue code smells can be filtered by different classification criteria.

Example of filtering code smells in Jerzyk’s online catalogue.

For example, the screenshot above shows the result of filtering code smells that are OO Abusers and affect Interfaces which includes the Refused Bequest, Base Class depends on Subclass, and Inappropriate Static code smells.

Code smell in Jerzyk’s online catalogue.

For each code smell, the catalogue presents the following sections: Smell (discussion of the smell), Causation (possible causes of the code smell), Problems (problems that the smell can cause or design principles violates), Example (examples of minimal code that illustrate the possible symptoms of a code smell and show a possible solution), Refactoring (possible refactorings) and Sources (articles or books that have described this code smell). It also includes a box containing information about possible aliases of the code smell, the category to which it belongs according to the criteria of obstruction, occurrence and expanse, the related smells and its relationship to them, and the historical origin of the code smell.

Conclusions.

Since the code smell concept was coined in 1999, many new smells have appeared. Catalogues as flat lists of code smells catalogue are hard to remember, and don’t help to highlight the relationships that exist between different code smells.

We have presented several code smells taxonomies that can help us see code smells from different points of view and relate them to each other according to different criteria: the problems they cause in the code, where they can be detected or the context that needs to be taken into account to detect them.

These meaningful groupings of code smells will help us understand and remember them better than flat catalogue lists.

Finally we’d like to highlight the recent work by Marcel Jerzyk which has not only proposed new smells and created a new multi-criteria taxonomy, but also has made available to us an online code smells catalogue in the form of an open-source repository and accessible and searchable website, which we believe can be very useful. useful and practical for both researchers and developers. I encourage you to take a look.

Acknowledgements.

I would like to thank my colleagues Fran Reyes, Antonio de La Torre, Miguel Viera and Alfredo Casado for reading the final drafts of this post and giving me feedback.

I’d also like to thank nikita for her photo.

References.

Books.

Refactoring: Improving the Design of Existing Code 1st edition 1999, Martin Fowler et al.
Refactoring: Improving the Design of Existing Code 2nd edition 2018, Martin Fowler et al.
Refactoring Workbook, William C. Wake
Refactoring to Patterns, Joshua Kerievsky
Five Lines of Code: How and when to refactor, Christian Clausen
The Programmer’s Brain, Felienne Hermans

Papers.

A Taxonomy and an Initial Empirical Study of Bad Smells in Code, Mantyla et al, 2003.
Subjective evaluation of software evolvability using code smells: An empirical study, Mantyla et al, 2006.
A Taxonomy for “Bad Code Smells” , Mantyla et al, 2006.
Code Smells: A Comprehensive Online Catalog and Taxonomy, Marcel Jerzyk, 2022.
Code Smells: A Comprehensive Online Catalog and Taxonomy Msc. Thesis, Marcel Jerzyk, 2022.
Extending a Taxonomy of Bad Code Smells with Metrics, R. Marticorena et al, 2006

Photo by nikita in Pexels.

Eliminando código comentado

2022-10-18T09:00:00+00:00

Dead Code es un smell clasificado dentro de la taxonomía de Wake^[1] en la categoría de Complejidad Innecesaria. Normalmente, suele aparecer en forma de variables, parámetros, campos, fragmentos de código, funciones o clases que no se ejecutan más.

El problema es que la mayoría de las veces no estamos seguros de si un determinado elemento del código ya no se usa o no. No saber si un código se ejecuta o no, hace que aumente la carga cognitiva (tenemos que tenerlo en cuenta y comprenderlo) a la hora de hacer cambios de funcionalidad o corregir bugs, lo cual aumenta la complejidad del cambio de forma totalmente innecesaria. Para hacer desaparecer esta complejidad bastaría con eliminar el código muerto, pero para ello primero debemos ser capaces de detectarlo.

Hay diversas maneras de detectar el código muerto. Las más efectivas se apoyan en el uso de herramientas, por ejemplo, la mayoría de IDEs advierten sobre elementos que ya no se usan. Estas herramientas reducen el coste que supondría tener que detectar el código muerto mediante sólo la lectura del código.

Las herramientas disponibles dependen tanto del lenguaje que se usa como de las características del lenguaje que se usen en el código. En general podemos decir que la detección de código muerto será más difícil entre más dinámicas sean las características que estemos utilizando.

En este post nos centraremos en un tipo de código muerto que es quizás el más fácil de detectar: el código comentado.

Problemas del código comentado.

Con frecuencia, solemos encontrar el código comentado intercalado con el resto del código. Esto provoca una ruptura del flujo de lectura que nos obliga a hacer un esfuerzo para ignorar el código comentado. Si los bloques de código comentados son grandes, en ocasiones nos vemos obligados a usar el scroll para continuar la lectura.

Bloque largo de código comentado.

Además del aumento de la carga cognitiva que genera todo código muerto, el código comentado puede generar confusión cuando uno lo tiene en cuenta, ya sea con la intención de usarlo en el futuro, o como ayuda para entender el código actual, debido a que suele quedar rápidamente desfasado.

Eliminar el código comentado suele ser sencillo, simplemente borramos el comentario que contiene el código y si al eliminarlo, el fichero que lo contenía queda vacío, lo eliminamos también.

Resistencias frecuentes a eliminar el código comentado.

Uno de los argumentos que nos solemos encontrar para no querer eliminar código comentado es que se piensa que se necesitará en algún momento del futuro. Por ejemplo, a veces se quiere guardar el código de una implementación anterior, que es compleja de recordar.

Una manera más práctica de hacer posible la recuperación de una versión anterior del código sin necesidad de mantener código comentado, es confiar en el sistema de control de versiones con el que trabajamos.

Un argumento frecuente en contra de esta última solución es que es mucho más fácil recuperar código comentado que encontrar una versión anterior en el control de versiones.

Aunque es verdad que es más difícil encontrar la versión anterior en el control de versiones, esta fricción se reduce si mejora nuestra habilidad para navegar en el histórico del control de versiones (ya sea a través del IDE o mediante la línea de comandos). Además, debemos tener en cuenta dos factores en contra de mantener el código comentado:

Con el tiempo la necesidad de recuperar el código de una versión anterior se vuelve cada vez menos probable porque el código va a divergir cada vez más de esa versión pasada.
El problema de complejidad innecesaria que hará más caro evolucionar el código hasta que eliminemos el código comentado.

Eliminando código comentado de forma automática.

Si comentar código ha sido una práctica muy utilizada por un equipo durante un tiempo largo, se puede llegar a una situación en la que el coste de eliminarlo sea elevado, y no nos quedará otro remedio que convivir con él durante mucho tiempo, mientras vamos alternando la entrega de funcionalidad con borrar código comentado de forma oportunista

En una situación así puede ser interesante explorar herramientas que borren código comentado de manera automática. Existen múltiples herramientas que podrían hacer este trabajo en la mayoría de los lenguajes. Una manera de acotar la exploración de herramientas es empezar por conocer nuestro IDE y sacarle provecho.

Por ejemplo, recientemente hemos aplicado esta estrategia de eliminación automática de código comentado en un cliente que trabajaba con Java e Intellij.

Intellij dispone de una herramienta de análisis de código que cuenta con diferentes tipos de inspecciones. Aparte del análisis en sí, lo más potente de esta herramienta es que permite ejecutar acciones (“fixes”) sobre los problemas detectados.

Ejecución de las inspecciones por nombre en IntelliJ.

La inspección concreta para detectar código comentado es commented out code. Se puede seleccionar el scope del análisis, diversos filtros y el número de líneas mínimas de los comentarios a considerar (lo que puede ser útil si, por ejemplo, queremos empezar por grandes bloques de código comentado).

Opciones para ejecutar la inspección 'commented out code'.

A continuación, podemos seleccionar los elementos detectados que queramos y proceder a realizar algunos de los fixes que el IDE nos proponga, en este caso aplicaremos Delete comment.

Fixes propuestos para resolver los caso de 'commented out code'.

Tras realizar estos cambios, ejecuta tus test para ver que no se ha modificado el comportamiento esperado. Dependiendo de tu situación (cobertura de tests, confianza del equipo, etc.) podría ser interesante verificar también que el borrado se ha hecho correctamente leyendo el código resultante. Sin embargo, si hay muchos cambios que verificar esto puede ser muy laborioso. Lo que podrías hacer en ese caso es planificar el borrado en varias fases, dividiéndolo por tipos de fichero, por paquetes, o por otro criterio de división que se adecue a tu situación.

Conclusión.

Hemos visto que el código comentado es una de las formas en la que se presenta el Dead Code smell, y como este smell aumenta de forma innecesaria la complejidad de nuestro código. Hemos presentado los argumentos más comunes (en nuestra experiencia) para resistirse a eliminar el código comentado, y hemos dado argumentos para rebatirlos. Finalmente, cuando trabajas con una base de código plagado de código comentado, hemos recomendado una alternativa a su eliminación mediante refactorings oportunistas, que consiste en explorar las herramientas que tienes a mano (tu IDE) para ver si disponen de funcionalidades para eliminar código muerto de manera automática. Esto te permitirá eliminar una mayor cantidad de código comentado con un coste asumible.

Notas

[1] Puedes leer sobre esta taxonomía y otras más en nuestro post De taxonomías y catálogos de code smells.

"Split or condition in if" refactoring

2022-10-08T05:00:00+00:00

We’d like to document a refactoring that we usually teach to teams we work with: the Split or condition in if refactoring.

Split or condition in if.

Motivation.

Sometimes we have nested conditionals that are branching depending on the same information. When an outer if condition contains an or which combines boolean expressions that check that information, splitting the or in the outer if may lead to opportunities to remove the rechecks in inner branching. This happens because having that or in the outer if forces us to check again the same information in an inner if condition.

Let’s see an example:

Have a look at the execute method code of the Rover class (we’ve omitted some code for brevity). Notice how this code is branching twice depending on the value of the command variable. Using an or in the condition of the outer if, makes it necessary to recheck the command variable again in inner if conditions. This adds unnecessary nesting and duplication that can be easily removed if we first split the or in the outer if.

Mechanics.

Some IDEs have automated this refactoring, for instance, the JetBrains family of IDEs. If you’re using one of JetBrains IDEs, you only need to place your cursor on the or condition and press ALT+ENTER to ask the IDE for possible context sensitive actions and select the Split ‘||’ condition in ‘if’ from the pop up menu.

Automated refactoring in WebStorm.

If your IDE does not have this refactoring automated, you can use the following mechanics to safely split the or condition in the if:

Duplicate the if.
This step might be different depending on if there was initially an else or not.
- If there was an else, you’d need to add the duplicated code in an else if block.
- If there was no else, you can just duplicate the whole if besides the original one.
Note that this step may change the behaviour. The tests may not pass until you do the next step.
Remove one clause of the or condition from one of the copies and the other clause of the or condition from the other copy.
At this point, run the tests to be sure that you haven’t accidentally modified the behaviour and the refactoring went ok.

Refactoring mechanics when there’s no else.

Refactoring mechanics when there’s an else.

Related code smells.

Mainly Duplicated Code and Complicated Boolean Expression.

Splitting or condition in if results in a code where is easier to remove both Duplicated Code and Complicated Boolean Expression smells, which in turn may unmask other smells.

In the following video, we show how after applying this refactoring we can easily remove duplicated if conditions because they become obsolete (even though the refactoring is automated in WebStorm, we used the mechanics described above for demonstration purposes).

Related refactorings.

The inverse of this refactoring pattern is the Combine ifs refactoring pattern described by Christian Clausen in his book Five Lines of Code, How and when to refactor

Conclusion.

We have described the Split or condition in if refactoring, and provided safe mechanics to perform it when it’s not automated by your IDE. We hope this refactoring technique might be useful to you.

Acknowledgements.

I’d like to thank Fran Reyes and Rubén Díaz for giving me feedback on the final draft of this post.

Update 2025/05/20:

I’ve just discovered that William Wake had already documented this refactor in 2020 with the name Duplicate and Customize.

Have a look at his great post: Refactor: Duplicate and Customize.

I was applying this refactor before 2017 (it was recorded in the YouTube video Expressing symmetry in Mars Rover movement refactoring from 2017), but didn’t document it until five years later.

The first time I applied it was while solving the Gilded Rose kata (which is coincidentally the same example that Wake shows to demonstrate the refactor in his post). I was just trying to simplify the same conditional in small steps and this was the way I found best. I’m a big fan of Wake’s work, so it’s great for me that we independently got to the same refactor.

Simplifying jest stubs using jest-when

2022-09-29T05:00:00+00:00

In a recent deliberate practice session with some developers from Audiense (with whom we’re doing the Codesai’s Practice Program twice a month), we were solving the Unusual Spending Kata in JavaScript.

While test-driving the UnusualSpendingDetector class we found that writing stubs using plain jest can be a bit hard. The reason is that jest does not match mocked function arguments, so to create stubbed responses for particular values of the arguments we are forced to introduce logic in the tests.

Have a look at a fragment of the tests we wrote for UnusualSpendingDetector class:

Notice the paymentsRepositoryWillReturn helper function, we extracted it to remove duplication in the tests. In this function we had to add explicit checks to see whether the arguments of a call match some given values. It reads more or less ok, but we were not happy with the result because we were adding logic in test code (see all the test cases).

Creating these stubs can be greatly simplified using a library called jest-when which helps to write stubs for specifically matched mocked function arguments. Have a look at the same fragment of the tests we wrote for UnusualSpendingDetector class now using jest-when:

Notice how the paymentsRepositoryWillReturn helper function is not needed anymore, and how the fluent interface of jest-when feels nearly like canonical jest syntax.

We think that using jest-when is less error prone than having to add logic to write your own stubs with plain jest, and it’s as readable as or more than using only jest (see all the refactored test cases).

To improve readability we played a bit with a functional builder. This is the same fragment of the tests we wrote for UnusualSpendingDetector class now using a functional builder over jest-when:

where the PaymentsRepositoryHelper is as follows:

In this last version we were just playing a bit with the code in order to find a way to configure the stubs both in terms of the domain and without free variables (have a look at all the test cases using this builder). In any case, we think that the previous version using jest-when was already good enough.

Probably you already knew jest-when, if not, give it a try. We think it can help you to write simpler stubs if you’re using jest.

De taxonomías y catálogos de code smells

2022-09-15T05:00:00+00:00

Índice.

Introducción: refactoring y code smells.
Martin Fowler, Code Smells y Catálogos.
Taxonomías

Taxonomías de Wake 2003
Taxonomía de Mäntylä et al 2003
Taxonomía de Mäntylä et al 2006
Taxonomía de Jerzyk et al 2022

Catálogo de Code Smells
Catálogo online.

Conclusiones.
Agradecimientos.
Referencias.

Introducción: refactoring y code smells.

Refactorizar es una práctica que nos permite evolucionar un código de forma sostenible. Para poder hacerlo necesitamos, en primer lugar, ser capaces de reconocer el código problemático que necesita ser refactorizado.

Los code smells son descripciones de señales o síntomas que nos avisan de posibles problemas de diseño en nuestro código. Detectar estos problemas y eliminarlos tan pronto como uno se da cuenta de que hay algo mal es crucial.

El refactoring produce mejores resultados y es más barato si se hace con regularidad. Entre más tiempo permanezca sin refactorizar un código problemático, más se agravará su efecto y constreñirá el futuro desarrollo del código, contribuyendo directamente a la deuda técnica. Esta situación hará el código cada vez más difícil de mantener, lo que tendrá un impacto económico muy negativo, pudiendo incluso llegar, en el peor de los casos, a ser tan complicada que ya no se pueda seguir manteniendo el código.

Coste de introducir una feature en función del tiempo (imagen de The Three Values of Software de J. B. Rainsberger).

Otra consecuencia, a veces, no tan visible de la mala calidad del código es su efecto en los desarrolladores. Menos refactor, lleva a código menos mantenible, que nos lleva a tardar más tiempo en implementar nuevas funcionalidades, lo cuál nos mete más presión de tiempo, lo que nos lleva a testear menos, lo que nos lleva a refactorizar menos… Es un círculo vicioso que puede tener un efecto muy desmoralizador.

Círculo vicioso sin refactor.

Por tanto, entender y saber identificar los code smells nos da mucho poder porque seremos capaces de detectar problemas de diseño cuando aún son pequeños y están muy localizados en zonas concretas de nuestro código, y eso tendrá un efecto económico y anímico muy positivo.

El problema es que los code smells no se suelen entender demasiado bien. Esto es entendible porque sus definiciones son a veces abstractas, difusas y abiertas a interpretación. Algunos code smells parecen obvios, otros no tanto, y algunos pueden enmascarar a otros code smells.

Además, recordemos que los code smells son sólo síntomas de posibles problemas, y no garantías de problemas. Para complicarlo aún más, además de los posibles falsos positivos, existen grados en el problema que cada smell representa, trade-offs entre smells y contraindicaciones en sus refactorings (en ocasiones “el remedio puede ser peor que la enfermedad”).

Por tanto, reconocer los code smells que señalan problemas de diseño, es decir, que no son falsos positivos, es una habilidad sutil, que requiere de experiencia y juicio. Adquirir esta habilidad, que a veces parece una especie de sentido arácnido, puede llevar tiempo.

En nuestra experiencia enseñando y acompañando a muchos equipos identificar code smells es una de las mayores barreras iniciales al refactoring. Muchos desarrolladores no se dan cuenta de los problemas del código que están generando cuando aún son pequeños. Lo que solemos ver es que no se dan cuenta hasta que los problemas son bastante grandes y/o se han combinado con otros problemas, propagándose por su base de código.

Catálogos de code smells.

En 1999 Fowler y Beck publicaron un catálogo de code smells en un capítulo del libro, Refactoring: Improving the Design of Existing Code. Este catálogo contiene las descripciones de 22 code smells.

En 2018 Fowler publicó una segunda edición de su libro. En esta nueva edición hay una serie de cambios con respecto a la primera, principalmente en el catálogo de smells y el catálogo de refactorings (que detalla en Changes for the 2nd Edition of Refactoring).

Si nos centramos en los smells, lo que nos interesa en este post, los cambios son los siguientes:

Introduce cuatro code smells nuevos: Mysterious Name, Global Data, Mutable Data y Loops.
Elimina dos smells: Parallel Inheritance Hierarchies y Incomplete Library Class.
Renombra cuatro smells: Lazy Class pasa a ser Lazy Element, Long Method pasa a ser Long Function, Inappropriate Intimacy pasa a ser Insider Trading y Switch Statement pasa a ser Repeated Switches.

Quedan un total de 24 code smells, que aunque suelen tener nombres llamativos y memorables, son difíciles de recordar.

¿De qué manera podríamos entender mejor los code smells? ¿Cómo podríamos recordarlos más fácilmente?

En este post, y algunos posteriores, hablaremos de estrategias para profundizar, recordar y entender mejor los code smells.

Estrategias organizativas.

Organizar y manipular la información, verla desde diferentes puntos de vista, nos puede ayudar a entender y recordar mejor. Las taxonomías son un tipo de estrategia organizativa, que nos permite agrupar un material de estudio según su significado, creando agrupamientos significativos de información (“chunks”), que facilitarán el aprendizaje.

Como comentamos el catálogo de Fowler de 2018 es una lista plana que no proporciona ningún tipo de clasificación. Si bien, leyendo las descripciones de los de code smells, y las secciones de motivación de los diferentes refactorings podemos vislumbrar que algunos smells están más relacionados entre ellos que con otros smells, estas relaciones no se expresan de forma explícita y quedan difuminadas y dispersas en diferentes partes del libro.

El uso de taxonomías que clasifican code smells similares puede ser beneficioso para entenderlos mejor, recordarlos y reconocer las relaciones que existen entre ellos.

Taxonomías.

Ha habido diferentes intentos de clasificar los code smells agrupándolos según diferentes criterios. La clasificación más popular es la de Mäntylä et al 2006 pero no es la primera. A continuación mostraremos algunas que consideramos bastante interesantes.

Wake 2003.

Wake en su libro Refactoring Workbook de 2003 describe 9 nuevos code smells que no aparecían en el catálogo original de Fowler: Dead Code, Null Check, Special Case, Magic Number, Combinatorial Explosion, Complicated Boolean Expression, y tres relacionados con malos nombres: Type Embedded in Name, Uncommunicative Names e Inconsistent Names.

Wake clasifica explícitamente los code smells dividiéndolos primero en dos categorías amplias, Smells within Classes y Smells Between Classes, dependiendo, respectivamente, de si el code smell puede ser observado desde una clase o si se necesita considerar un contexto más amplio (varias clases). Cada una de estas categorías se divide en subcategorías que agrupan los code smells según en dónde se pueden detectar. Este criterio de clasificación, denominado más tarde “occurrence” por Jerzyk, responde a la pregunta: “¿dónde aparece este code smell?”.

Siguiendo este criterio Wake encuentra las siguientes 10 subcategorías.

Dentro de la categoría de Smells within Classes estarían las siguientes subcategorías:

Measured Smells: code smells que pueden ser identificados fácilmente con simples métricas de longitud.
Names: code smells que crean confusión semántica y afectan a nuestra capacidad de crear modelos mentales que nos ayuden a comprender, recordar y razonar sobre el código.
Unnecessary Complexity: code smells relacionados con código innecesario que añade carga mental y complejidad. Código muerto, violaciones de YAGNI y complejidad accidental.
Duplication: la némesis de los desarrolladores. Estos code smells provocan que haya mucho más código que mantener (carga cognitiva y física), aumentan la propensión a errores y dificultan la comprensión del código.
Conditional Logic Smells: code smells que complican la lógica condicional haciendo difícil razonar sobre ella, dificultando el cambio y aumentando la propensión a cometer errores. Algunos de ellos son sucedáneos de mecanismos de la orientación a objetos.

Las subcategorías dentro de la categoría de Smells between Classes son:

Data: code smells en los que encontramos, o bien pseudo objetos (estructuras de datos sin comportamiento), o bien encontramos que falta alguna abstracción.
Inheritance: code smells relacionados con un mal uso de la herencia.
Responsibility: code smells relacionados con una mala asignación de responsabilidades.
Accommodating Change: code smells que se manifiestan cuando nos encontramos con mucha fricción al introducir cambios. Suelen estar provocados por combinaciones de otros code smells.
Library Classes: code smells relacionados con el uso de librerías de terceros.

Taxonomía de Wake (los nuevos smells aparecen en verde).

Wake presenta cada smell siguiendo un formato estándar con las siguientes secciones: Smell (el nombre y aliases), Síntomas (pistas que pueden ayudar a detectarlo), Causas (notas sobre cómo puede haberse generado), Qué Hacer (posibles refactorings), Beneficios (cómo mejorará el código al eliminarlo) y Contraindicaciones (falsos positivos y trade-offs). En algunos casos añade notas relacionando el code smell con principios de diseño que podrían ayudar a evitarlo.

El libro además contiene muchos ejercicios prácticos y tablas muy útiles (síntomas vs code smells, smells vs refactorings, refactorings inversos, etc) y ejercicios que relacionan los code smells con otros conceptos como principios de diseño o patrones de diseño.

Es un libro muy recomendable para profundizar en la disciplina de refactoring y entender mejor cuándo y por qué aplicar los refactorings que aparecen en el catálogo de Fowler.

Lo que enseñamos sobre code smells en nuestro curso sobre Code Smells & Refactoring se basa principalmente en esta clasificación de Wake aderezada con un poco de nuestra experiencia, aunque también hacemos referencia al resto de taxonomías de las que hablamos en este post.

Mäntylä et al 2003.

En ella los code smells se agrupan según el efecto que tienen en el código (el tipo de problema, lo que hacen difícil o las prácticas o principios que rompen). Jerzyk 2022 denomina “obstrucción” a este criterio de clasificación.

En la clasificación original de 2003 (A Taxonomy and an Initial Empirical Study of Bad Smells in Code) había 7 categorías de code smells: Bloaters, Object-Orientation Abusers, Change Preventers, Dispensables, Encapsulators, Couplers y Others.

Taxonomía de Mäntylä et al 2003.

Así es como definen cada una de las categorías (disculpen al traductor…):

Bloaters: “representan algo en el código que ha crecido tanto que ya no se puede manejar de forma efectiva.“
Object-Orientation Abusers: “esta categoría de smells se relaciona con casos en los que la solución no explota completamente las posibilidades del diseño orientado a objetos.”
Change Preventers: “esta categoría hace referencia a estructuras de código que dificultan considerablemente cambiar el software.”
Dispensables: “estos smells representan algo innecesario que debería ser eliminado del código.”
Encapsulators: “tiene que ver con mecanismos de comunicación o encapsulación de datos.”
Couplers: “estos smells representan casos de acoplamiento alto, lo cual va en contra de los principios de diseño orientado a objetos”
Others: “esta categoría contiene los code smells restantes (Comments e Incomplete Library Class) que no encajaban en ninguna de las categorías anteriores.”

En el artículo, Mäntylä et al discuten los motivos por los que incluyeron cada smell en una determinada categoría y no otra, aunque admiten que algunos de ellos podrían ser clasificados en más de una categoría.

Mäntylä et al 2006.

En 2006 Mäntylä et al sacaron otro artículo (Subjective evaluation of software evolvability using code smells: An empirical study) en el que revisaron su clasificación original de 2003.

La diferencia de esta nueva versión es que elimina las categorías Encapsulators (moviendo los smells Message Chains y Middle Man a la categoría Couplers) y Others (Comments e Incomplete Library Class desaparecen de la taxonomía), y mueve el code smell Parallel Inheritance Hierarchies de la categoría de Object-Orientation Abusers a la categoría de Change Preventers.

Esta última versión de su taxonomía es la que se ha hecho más popular en internet (se puede encontrar en muchas webs, cursos y posts), probablemente debido a la mayor accesibilidad (facilidad de lectura) del resumen del artículo que aparece en la web que resume el artículo: A Taxonomy for “Bad Code Smells”.

Taxonomía de Mäntylä et al 2006.

Lo interesante no es tanto la discusión de en qué categoría debe caer cada smell, sino el empezar a pensar qué un determinado smell puede tener diferentes tipos de efectos en el código y las relaciones entre estos efectos. De hecho, en posteriores clasificaciones desde el punto de vista del efecto de un smell en el código, no consideran ya las categorías como excluyentes, sino que, un mismo smell puede caer en varias categorías, ya que consideran que es más útil no perder la información de que un smell puede producir varios efectos.

Jerzyk et al 2022.

En 2022 Marcel Jerzyk publicó su tesis de master, Code Smells: A Comprehensive Online Catalog and Taxonomy y un artículo con el mismo título. Su investigación sobre code smells tenía tres objetivos:

Proporcionar un catálogo público que pudiera ser útil como una base de conocimiento unificada tanto para investigadores como para desarrolladores.
Identificar todos los conceptos posibles que están siendo caracterizados como code smells y determinar posibles controversias sobre ellos.
Asignar propiedades apropiadas a los code smells con el fin de caracterizarlos.

Para conseguir estos objetivos realizaron una revisión de la literatura existente hasta ese momento sobre code smells, haciendo especial énfasis en las taxonomías de code smells.

En su tesis identifican y describen 56 code smells, de los cuales 16 son propuestas originales suyas, (recordemos que Wake describió 31 code smells y Fowler 24 en su última revisión). En la tesis de master de Jerzyk se pueden encontrar descripciones y discusiones sobre cada uno de estos 56 code smells.

Analizando los criterios de clasificación de las taxonomías propuestas anteriormente, Jerzyk encuentra tres criterios significativos para categorizar code smells:

Obstruction: Este es el criterio usado por Mäntylä et al para clasificar los smells en su taxonomía y el más popular. Este criterio nos informa sobre el tipo de problema que un code smell causa en el código (lo que hacen difícil o las prácticas o principios que rompen). En la tesis actualizan la taxonomía de Mäntylä, añadiendo tres nuevos grupos: Data Dealers, Functional Abusers y Lexical Abusers. A continuación presentamos un mapa mental que muestra la clasificación de los 56 code smells siguiendo únicamente este criterio.

Taxonomía de Jerzyk usando sólo el criterio de obstruction.

Expanse: Inspirado por la taxonomía de Wake, este criterio habla de si el code smell puede ser observado en un contexto reducido (dentro de una clase) o si se necesita considerar un contexto más amplio (entre varias clases). Las posibles categorías son Within Class y Between Classes.
Occurrence: También inspirado por la taxonomía de Wake, este criterio está relacionado con la localización donde (o el método por el cuál) se puede detectar un code smell. Las posibles categorías son Names, Conditional Logic, Message Calls, Unnecessary Complexity, Responsibility, Interfaces, Data, Duplication y Measured Smells.

A continuación presentamos una tabla con los 56 code smells clasificados por Jerzyk en su tesis usando los tres criterios comentados anteriormente:

Code Smell	Obstruction	Expanse	Occurrence
Long Method	Bloaters	Within	Measured Smells
Large Class	Bloaters	Within	Measured Smells
Long Parameter List	Bloaters	Within	Measured Smells
Primitive Obsession	Bloaters	Between	Data
Data Clumps	Bloaters	Between	Data
Null Check	Bloaters	Between	Conditional Logic
Oddball Solution	Bloaters	Between	Duplication
Required Setup/Teardown	Bloaters	Between	Responsibility
Combinatorial Explosion	Bloaters	Within	Responsibility
Parallel Inheritance Hierarchies	Change Preventers	Between	Responsibility
Divergent Change	Change Preventers	Between	Responsibility
Shotgun Surgery	Change Preventers	Between	Responsibility
Flag Argument	Change Preventers	Within	Conditional Logic
Callback Hell	Change Preventers	Within	Conditional Logic
Dubious Abstraction	Change Preventers	Within	Responsibility
Special Case	Change Preventers	Within	Conditional Logic
Feature Envy	Couplers	Between	Responsibility
Type Embedded In Name	Couplers	Within	Names
Indecent Exposure	Couplers	Within	Data
Fate over Action	Couplers	Between	Responsibility
Afraid to Fail	Couplers	Within	Responsibility
Binary Operator in Name	Couplers	Within	Names
Tramp Data	Data Dealers	Between	Data
Hidden Dependencies	Data Dealers	Between	Data
Global Data	Data Dealers	Between	Data
Message Chain	Data Dealers	Between	Message Calls
Middle Man	Data Dealers	Between	Message Calls
Insider Trading	Data Dealers	Between	Responsibility
Lazy Element	Dispensables	Between	Unnecessary Complexity
Speculative Generality	Dispensables	Within	Unnecessary Complexity
Dead Code	Dispensables	Within	Unnecessary Complexity
Duplicate Code	Dispensables	Within	Duplication
“What” Comments	Dispensables	Within	Unnecessary Complexity
Mutable Data	Functional Abusers	Between	Data
Imperative Loops	Functional Abusers	Within	Unnecessary Complexity
Side Effects	Functional Abusers	Within	Responsibility
Uncommunicative Name	Lexical Abusers	Within	Names
Magic Number	Lexical Abusers	Within	Names
Inconsistent Names	Lexical Abusers	Within	Names
Boolean Blindness	Lexical Abusers	Within	Names
Fallacious Comment	Lexical Abusers	Within	Names
Fallacious Method Name	Lexical Abusers	Within	Names
Complicated Boolean Expressions	Obfuscators	Within	Conditional Logic
Obscured Intent	Obfuscators	Between	Unnecessary Complexity
Vertical Separation	Obfuscators	Within	Measured Smells
Complicated Regex Expression	Obfuscators	Within	Names
Inconsistent Style	Obfuscators	Between	Unnecessary Complexity
Status Variable	Obfuscators	Within	Unnecessary Complexity
Clever Code	Obfuscators	Within	Unnecessary Complexity
Temporary Fields	O-O Abusers	Within	Data
Conditional Complexity	O-O Abusers	Within	Conditional Logic
Refused Bequest	O-O Abusers	Between	Interfaces
Alternative Classes with Different Interfaces	O-O Abusers	Between	Duplication
Inappropriate Static	O-O Abusers	Between	Interfaces
Base Class Depends on Subclass	O-O Abusers	Between	Interfaces
Incomplete Library Class	Other	Between	Interfaces

Algunos de los nombres en la tabla son diferentes de los que suelen aparecer en la literatura. Los cambios de nombre fueron debidos a la introducción de nombre más actualizados, como es el caso, por ejemplo, de Lazy Element o Insider Trading que antes se llamaban Lazy Class e Inappropriate Intimacy, respectivamente.

Hay varios smells que son nuevos. Algunos como Afraid to Fail, Binary Operator in Name, Clever Code, Inconsistent Style, y Status Variable, son ideas completamente nuevas. Otros son conceptos ya existentes en la literatura pero que no se habían considerado en el contexto de los code smells: Boolean Blindness o Callback Hell. Tres de ellos proponen alternativas para code smells que están siendo cuestionados en la literatura: “What” Comment como alternativa para Comments, Fate over Action como alternativa para Data Class, e Imperative Loops como alternativa para Loops (ver la tesis de Jerzyk para profundizar en por qué estos code smells originales son discutibles). Otros generalizan otros conceptos problemáticos que han surgido en la literatura: Complicated Regex Expression, Dubious Abstraction, Fallacious Comment, Fallacious Method Name. Por último, un problema conocido (especialmente en el campo de la programación funcional), pero que no se ha considerado hasta ahora como code smell: Side Effects.

Una cosa super útil y práctica para desarrolladores que aporta el trabajo de Jerzyk es la creación de un catálogo online de code smells que incluía cuando se publicó los 56 code smells que aparecen en la tabla. Este catálogo es un sitio web accesible y buscable. En la fecha de publicación de este post, el catálogo contiene 56 code smells.

En el catálogo se pueden buscar los smells por diferentes criterios de clasificación.

Ejemplo de búsqueda en el catálogo online de code smells de Jerzyk.

Por ejemplo, esta captura de pantalla muestra el resultado de buscar code smells que sean OO Abusers y que afecten a Interfaces: Refused Bequest, Base Class depends on Subclass e Inappropriate Static.

Code smell en el catálogo online de Jerzyk.

Para cada smell el catálogo presentan las siguientes secciones: Smell (discusión del smell), Causation (posibles causas del code smell), Problems (problemas que el smell puede causar o principios de diseño que viola), Example (ejemplos de código mínimo que ilustran los posibles síntomas de un code smell y muestran una posible solución), Refactoring (posibles refactorings) y Sources (artículos o libros en los que se ha hablado de este code smell). También incluye un recuadro en el que aparece información sobre posibles aliases del code smell, la categoría a la que pertenece según los criterios de obstruction, occurrence y expanse, los smells relacionados y su relación con ellos, y el origen histórico del code smell.

Conclusiones.

Desde que se acuñó el concepto de code smell en 1999 han aparecido muchos nuevos smells. Las presentaciones planas en forma de catálogo son difíciles de recordar, y no ayudan a resaltar las relaciones que existen entre diferentes code smells.

Hemos presentado varias taxonomías de code smells que nos pueden ayudar a ver los code smells desde diferentes puntos de vista y relacionarlos unos con otros según diferentes criterios: los problemas que producen en el código, dónde se detectan o el contexto que es necesario tener en cuenta para detectarlos.

Estos agrupamientos significativos de code smells nos ayudarán a entenderlos y a recordarlos mejor que las listas planas de los catálogos.

Por último queremos destacar el reciente trabajo de Marcel Jerzyk que no sólo ha propuesto nuevos smells y ha creado una nueva taxonomía multicriterio, sino que además ha puesto a nuestra disposición un catálogo online de code smells en forma de repositorio open-source y sitio web accesible y buscable, que creemos que puede resultar muy útil y práctico tanto para investigadores como para desarrolladores. Los animo a echarle un vistazo.

Agradecimientos.

Me gustaría darle las gracias a mis colegas Fran Reyes, Antonio de La Torre, Miguel Viera y Alfredo Casado por leer los borradores finales de este post y darme feedback. También quería agradecer a nikita por su foto.

Referencias.

Libros.

Refactoring: Improving the Design of Existing Code 1st edition 1999, Martin Fowler et al.
Refactoring: Improving the Design of Existing Code 2nd edition 2018, Martin Fowler et al.
Refactoring Workbook, William C. Wake
Refactoring to Patterns, Joshua Kerievsky
Five Lines of Code: How and when to refactor, Christian Clausen
The Programmer’s Brain, Felienne Hermans

Artículos.

A Taxonomy and an Initial Empirical Study of Bad Smells in Code, Mantyla et al, 2003.
Subjective evaluation of software evolvability using code smells: An empirical study, Mantyla et al, 2006.
A Taxonomy for “Bad Code Smells” , Mantyla et al, 2006.
Code Smells: A Comprehensive Online Catalog and Taxonomy, Marcel Jerzyk, 2022.
Code Smells: A Comprehensive Online Catalog and Taxonomy Msc. Thesis, Marcel Jerzyk, 2022.
Extending a Taxonomy of Bad Code Smells with Metrics, R. Marticorena et al, 2006

Foto de nikita in Pexels

Un caso de Shotgun Surgery

2022-09-12T14:30:00+00:00

Colaboramos con un cliente en cuyo producto, el SEO es un aspecto muy importante del negocio. En general, el SEO suele ser un aspecto a cuidar, pero en el caso de este cliente el SEO supone una fuente de ingresos considerable.

Cuando los buscadores analizan las páginas de un producto hay 2 partes importantes para nuestro sistema que se deben indicar al buscador, la indexación de esa página y su canonical.

Ante páginas similares, el canonical le indica al buscador cuál página queremos posicionar (mediante su url). De esta manera evitamos que los motores de búsqueda nos penalicen al considerar dichas páginas similares como contenido duplicado.

En el contexto del producto, el SEO además de ser una fuente de ingresos importante, es bastante complejo. Es decir, partimos de una complejidad esencial contenida en reglas de negocio, con una gran variedad de reglas de comportamiento dependiendo de aspectos como la ubicación, el número de resultados, el tipo de búsqueda, etc.

Situación del código

A la complejidad esencial de calcular el canonical de una página y decidir si se indexa o no, se añadía la complejidad accidental provocada por un código en el que las reglas del SEO se encontraban dispersas en 2 zonas de la aplicación, IndexationCalculator y CanonicalCalculator. Por suerte, ambas tenían tests.

Un caso claro de shotgun surgery...

Los clientes veían estas 2 funcionalidades a través de las interfaces que se muestran a continuación:

El problema

Viendo los nombres de las interfaces, IndexationCalculator y CanonicalCalculator, parece que la responsabilidad de saber si una página se indexa y calcular el canonical están bien segregadas. Sin embargo, cuando se nos pide, por ejemplo, cambiar un aspecto del cálculo del canonical nos vemos obligados a considerar y probablemente cambiar tanto la implementación de IndexationCalculator como CanonicalCalculator.

Es decir, el problema es que si nos piden hacer cambios concretos nos vemos obligados a tocar múltiples zonas. El código presenta un caso claro de un code smell conocido como Shotgun Surgery.

El Shotgun Surgery es una violación del principio de única responsabilidad. En este caso concreto existe una falta de cohesión a nivel de implementación. Es decir, si bien los ejes de cambio se identificaron correctamente a nivel de interface, las responsabilidades se distribuyeron mal, quedando repartidas entre ambas implementaciones^[1].

La solución para resolver el Shotgun Surgery es segregar las responsabilidades de manera que no violemos el principio de única responsabilidad. Para ellos necesitamos mover código hacia el lugar donde debería habitar, pero esto no es tan fácil como usar el refactoring Move Function.

El problema es que en este caso las reglas se estaban ejecutando en un orden determinado y eso no estaba ni en IndexationCalculator ni en CanonicalCalculator sino en el código cliente. Además, ese orden, determinado por el cliente, no estaba testeado.

Segregando las Reglas

En un caso en el que el cálculo del canonical y el de la indexación no tuvieran que ser ejecutadas en un orden determinado, mover las reglas sólo supondría mover casos de tests entre los tests de las implementaciones y el mover el código correspondiente, usando Move Function.

Mover reglas es fácil cuando no importa el orden de ejecución.

Pero, como explicamos anteriormente, la dependencia entre ambos cálculos introducida por el orden preestablecido y la complejidad de las reglas, hacía que no fuera fácil razonar si era seguro mover la lógica sin cambiar comportamiento. Además, teniendo en cuenta, como ya se explicó, que el SEO supone una fuente de ingresos considerable para este producto, no podíamos aceptar el nivel de riesgo que suponía refactorizar de la manera que hemos explicado.

Para reducir el riesgo de modificar el comportamiento, lo que hicimos fue extraer una clase, llamada PageIndexer, cuya responsabilidad era coordinar los cálculos de la indexación y el canonical.

A continuación creamos una nueva batería de tests contra PageIndexer que contenía los casos de tests tanto del CanonicalCalculator como de IndexationCalculator, y añadimos los tests que faltaban para la interacción entre ambas clases. De esta manera estábamos probando no solo cada unidad por separado sino además la interacción (o integración) de ambas.

Nuevos tests contra la nueva abstracción que encapsula el orden de ejecución de las reglas.

Teniendo estos tests contra PageIndexer pudimos empezar a mover a IndexationCalculator la lógica de indexation que se había filtrado en CanonicalCalculator y viceversa. Para ello movimos las reglas moviendo primero los casos de tests y luego el código correspondiente, usando Move Function. Al terminar de segregar las responsabilidades, eliminamos los tests que probaban las responsabilidades por separado.

Ahora podemos mover reglas con confianza y, al final, eliminar los antiguos tests.

Conclusión

Hemos presentado un caso de Shotgun Surgery a partir de un caso real y hemos contado como se hizo refactoring para segregar las responsabilidades.

En un contexto sin las particularidades comentadas, los pasos para resolver el problema habrían dado menos trabajo. Pero el orden de ejecución, la complejidad y el alto valor de negocio en este contexto, hicieron que tuviéramos que trabajar más y no seguir la manera canónica descrita en la mayoría de literatura.

Si te encuentras en una situación parecida, quizás puedes aplicar algunos de los aspectos de esta solución y reducir el riesgo del cambio.

Notas

[1] Los motivos por los que se produjo una mezcla de las responsabilidades pueden estar en el diseño de las interfaces, pero este problema quizás lo tratemos en un futuro post.

Example of role tests in JavaScript with Jest

2022-08-04T05:30:00+00:00

In this post we’ll show our last example applying the concept of role tests, this time in JavaScript using Jest. Have a look at our previous posts on this topic.

This example comes from a deliberate practice session we did recently with some developers from Audiense with whom we’re doing Codesai’s Practice Program in JavaScript twice a month.

Similar to what we did in our previous example of role tests in Java, we wrote the following tests to develop two different implementations of the TransactionsRepository port while solving the Bank Kata: the InMemoryTransactionsRepository and the NodePersistTransactionRepository.

These are their tests, respectively:

As what happened in our previous post, both tests contain the same test cases since both tests document and protect the contract of the same role, TransactionsRepository, which InMemoryTransactionsRepository and NodePersistTransactionRepository implement.

Again we’ll use the concept of role tests to remove that duplication, and make the contract of the role we are implementing more explicit.

Although Jest does not have something equivalent or similar to the RSpec’s shared examples functionality we used in our previous example in Ruby, we can get a very similar result by composing functions.

First, we wrote the behavesLikeATransactionRepository function. This function contains all the test cases that document the role and protect its contract, and receives as a parameter a testContext object containing methods for all the operations that will vary in the different implementations of this integration test.

Notice that in the case of Jest we are using composition, whereas we used inheritance in the case of Junit.

Then, we called the behavesLikeATransactionRepository function from the previous tests and implemented a particular version of the methods of the testContext object for each test.

This is the new code of InMemoryTransactionsRepositoryTest:

And this is the new code of NodePersistTransactionRepository after the refactoring:

This new version of the tests not only reduces duplication, but also makes explicit and protects the behaviour of the TransactionsRepository role. It also makes less error prone the process of adding a new implementation of TransactionsRepository because just by using the behavesLikeATransactionRepository function, you’d get a checklist of the behaviour you need to implement in order to ensure substitutability, i.e., to ensure the Liskov Substitution Principle is not violated.

These role tests using composition are also more readable than the Junit ones, in my opinion at least :)

Acknowledgements.

I’d like to thank Audiense’s deliberate practice group for working with us on this kata, and my colleague Rubén Díaz for co-facilitating the practice sessions with me.

Thanks to my Codesai colleagues for reading the initial drafts and giving me feedback, and to Elina Sazonova for the picture.

References.

Photo from Elina Sazonova in Pexels

Example of role tests in Java with Junit

2022-08-02T05:30:00+00:00

I’d like to continue with the topic of role tests that we wrote about in a previous post, by showing an example of how it can be applied in Java to reduce duplication in your tests.

This example comes from a deliberate practice session I did recently with some people from Women Tech Makers Barcelona with whom I’m doing Codesai’s Practice Program in Java twice a month.

Making additional changes to the code that resulted from solving the Bank Kata we wrote the following tests to develop two different implementations of the TransactionsRepository port: the InMemoryTransactionsRepository and the FileTransactionsRepository.

These are their tests, respectively:

As you can see both tests contain the same test cases: a_transaction_can_be_saved and transactions_can_be_retrieved but their implementations are different for each class. This makes sense because both implementations implement the same role, (see our previous post to learn how this relates to Liskov Substitution Principle).

We can make this fact more explicit by using role tests. In this case, Junit does not have something equivalent or similar to the RSpec’s shared examples functionality we used in our previous example in Ruby. Nonetheless, we can apply the Template Method pattern to write the role test, so that we remove the duplication, and more importantly make the contract we are implementing more explicit.

To do that we created an abstract class, TransactionsRepositoryRoleTest. This class contains the tests cases that document the role and protect its contract (a_transaction_can_be_saved and transactions_can_be_retrieved) and defines hooks for the operations that will vary in the different implementations of this integration test (prepareData, readAllTransactions and createRepository):

Then we made the previous tests extend TransactionsRepositoryRoleTest and implemented the hooks.

This is the new code of InMemoryTransactionsRepositoryTest:

And this is the new code of FileTransactionsRepositoryTest after the refactoring:

This new version of the tests not only reduces duplication, but also makes explicit and protects the behaviour of the TransactionsRepository role. It also makes less error prone the process of adding a new implementation of TransactionsRepository because just by extending the TransactionsRepositoryRoleTest, you’d get a checklist of the behaviour you need to implement to ensure substitutability, i.e., to ensure the Liskov Substitution Principle is not violated.

Have a look at this Jason Gorman’s repository to see another example that applies the same technique.

In a future post we’ll show how we can do the same in JavaScript using Jest.

Acknowledgements.

I’d like to thank the WTM study group, and especially Inma Navas and Laura del Toro for practising with this kata together.

Thanks to my Codesai colleagues, Inma Navas and Laura del Toro for reading the initial drafts and giving me feedback, and to Esranur Kalay for the picture.

References.

Photo from Esranur Kalay in Pexels

Simple example of property-based testing

2022-06-20T11:30:00+00:00

Introduction.

We were recently writing tests to characterise a legacy code at a client that was being used to encrypt and decrypt UUIDs using a cipher algorithm. We have simplified the client’s code to remove some distracting details and try to highlight the key ideas we’d like to transmit.

In this post we’ll show how we used parameterized tests to test the encryption and decryption functions, and how we applied property-based testing to explore possible edge cases using a very useful pattern to discover properties.

Finally, we’ll discuss the resulting tests.

Testing the encryption and decryption functions.

We started by writing examples to fixate the behaviour of the encryption function. Notice how we used parameterized tests^[1] to avoid the duplication that having a different test for each example would have caused:

Then we wrote more parameterized tests for the decryption function. Since the encryption and decryption functions are inverses of each other, we could use the same examples that we had used for the encryption function. Notice how the roles of being input and expected output change for the parameters of the new test.

Exploring edge cases.

You might wonder why we wanted to explore edge cases. Weren’t the parameterized tests enough to characterise this legacy code?

Even though, the parameterized tests that we wrote for both functions were producing a high test coverage, coverage only “covers” code that is already there. We were not sure if there could be any edge cases, that is, inputs for which the encryption and decryption functions might not behave correctly. We’ve found edge cases in the past even in code with 100% unit test coverage.

Finding edge cases is hard work which sometimes might require exploratory testing by specialists. It would be great to automatically explore some behaviour to find possible edge cases so we don’t have to find them ourselves or some QA specialists. In some cases, we can leverage property-based testing to do that exploration for us^[2].

One of the most difficult parts of using property-based testing is finding out what properties we should use. Fortunately, there are several approaches or patterns for discovering adequate properties to apply property-based testing to a given problem. Scott Wlaschin wrote a great article in which he explains several of those patterns^[3].

It turned out that the problem we were facing matched directly to one of the patterns described by Wlaschin, the one he calls “There and back again”(also known as “Round-tripping” or “Symmetry” pattern).

According to Wlaschin “There and back again” properties “are based on combining an operation with its inverse, ending up with the same value you started with”. As we said before, in our case the decryption and encryption functions were inverses of each other so the “There and back again” pattern was likely to lead us to a useful property.

Once we knew which property to use it was very straightforward to add a property-based test for it. We used the jqwik library. We like it because it has very good documentation and it is integrated with Junit.

Using jqwik functions we wrote a generator of UUIDs (have a look at the documentation on how to generate customised parameters), we then wrote the decrypt_is_the_inverse_of_encrypt property:

By default jqwik checks the property with 1000 new randomly generated UUIDs every time this test runs. This allows us to gradually explore the set of possible examples in order to find edge cases that we have not considered.

Discussion.

If we examine the resulting tests we may think that the property-based tests have made the example-based tests redundant. Should we delete the example-based tests and keep only the property-based ones?

Before answering this question, let’s think about each type of test from different points of view.

Understandability.

Despite being parameterized, it’s relatively easy to see which inputs and expected outputs are used by the example-based tests because they are literal values provided by the generateCipheringUuidExamples method. Besides, this kind of testing was more familiar to the team members.

In contrast, the UUID used by the property-based tests to check the property is randomly generated and the team was not familiar with property-based testing.

Granularity.

Since we are using a property that uses the “There and back again” pattern, if there were an error, we wouldn’t know whether the problem was in the encryption or the decryption function, not even after the shrinking process^[4]. We’d only know the initial UUID that made the property fail.

This might not be so when using other property patterns. For instance, when using a property based on the “The test oracle” pattern, we’d know the input and the actual and expected outputs in case of an error.

In contrast, using example-based testing it would be very easy to identify the location of the problem.

Confidence, thoroughness and exploration.

The example-based tests specify behaviour using concrete examples in which we set up concrete scenarios, and then check whether the effects produced by the behaviour match what we expect. In the case of the cipher, we pass an input to the functions and assert that their output is what we expect. The testing is reduced just to the arbitrary examples we were able to come up with, but there’s a “gap between what we claim to be testing and what we’re actually testing”^[5]: why those arbitrary examples? Does the cipher behave correctly for any possible example?

Property-based testing “approach the question of correctness from a different angle: under what preconditions and constraints (for example, the range of input parameters) should the functionality under test lead to particular postconditions (results of a computation), and which invariants should never be violated in the course?”^[6]. With property-based testing we are not limited to the arbitrary examples we were able to come up with as in example-based testing. Instead, property-based testing gives us thoroughness and the ability to explore because it’ll try to find examples that falsify a property every time the test runs. I think this ability to explore makes them more dynamic.

Implementation independence.

The example-based tests depend on the implementation of the cypher algorithm, whereas the property-based tests can be used for any implementation of the cypher algorithm because the decrypt_is_the_inverse_of_encrypt property is an invariant of any cipher algorithm implementation. This makes the property-based tests ideal to write a role test^[7] that any valid cipher implementation should pass.

Explicitness of invariants.

In the case of the cipher there’s a relationship between the encryption and decryption functions: they are inverses of each other.

This relationship might go completely untested using example-based testing if we use unrelated examples to test each of the functions. This means there could be changes to any of the functions that may violate the property while passing the independent separated tests of each function.

In the parameterized example-based tests we wrote, we implicitly tested this property by using the same set of examples for both functions just changing the roles of input and expected output for each test, but this is limited to the set of examples.

With property-based testing we are explicitly testing the relation between the two functions and exploring the space of inputs to try to find one that falsifies the property of being inverses of each other.

Protection against regressions.

Notice that, in this case, If we deleted the example-based tests and just kept the property-based test using the decrypt_is_the_inverse_of_encrypt property, we could introduce a simple regression by implementing both functions, encrypt and decrypt, as the identity function. That obviously wrong implementation would still fulfil the decrypt_is_the_inverse_of_encrypt property, which means that the property-based test using decrypt_is_the_inverse_of_encrypt property is not enough on its own to characterise the desired behaviour and protect it against regressions. We also need to at least add example-based testing for one of the cipher functions, either encrypt or decrypt. Notice that this might happen for any property based on “There and back again” pattern. This might not hold true for different contexts and property patterns.

What we did.

Given the previous discussion, we decided to keep both example-based and property-based tests in order to gain exploratory power while keeping familiarity, granularity and protection against regressions.

Summary.

We’ve shown a simple example of how we applied JUnit 5 parameterized tests to test the encryption and decryption functions of a cipher algorithm for UUIDs.

Then we showed a simple example of how we can use property-based testing to explore our solution and find edge cases. We also talked about how discovering properties can be the most difficult part of property-based testing, and how there are patterns that can be used to help us to discover them.

Finally, we discussed the resulting example-based and property-based tests from different points of view.

We hope this post will motivate you to start exploring property-based testing as well. If you want to learn more, follow the references we provide and start playing. Also have a look at the other posts exploring property-based testing in our blog we have written in the past.

Acknowledgements.

I’d like to thank my Codesai colleagues for reading the initial drafts and giving me feedback.

Notes.

[1] The experience of writing parameterized tests using JUnit 5 is so much better than it used to be with JUnit 4!

[2] Have a look at this other post in which I describe how property-based tests were able to find edge cases that I had not contemplated in a code with 100% test coverage that had been written using TDD.

[3] Scott Wlaschin’s article, Choosing properties for property-based testing, is a great post in which he manages to explain the patterns that have helped him the most, to discover the properties that are applicable to a given problem. Besides the “There and back again” pattern, I’ve applied the [“The test oracle”][https://fsharpforfunandprofit.com/posts/property-based-testing-2/#the-test-oracle] on several occasions. Some time ago, I wrote a post explaining how I used it to apply property-based testing to an implementation of a binary search tree. Another interesting article about the same topic is Property-based Testing Patterns, Sanjiv Sahayam.

[4] “Shrinking is the mechanism by which a property-based testing framework can be told how to simplify failure cases enough to let it figure out exactly what the minimal reproducible case is.” from chapter 8 of Fred Hebert’s PropEr Testing online book

[5] From David MacIver’s In praise of property-based testing post. According to David MacIver “the problem with example-based tests is that they end up making far stronger claims than they are actually able to demonstrate”.

[6] From Johannes Link’s Know for Sure with Property-Based Testing post.

[7] Have a look at our recent post about role tests.

References.

Photo from Pixabay in Pexels.

Listening to test smells: detecting lack of cohesion and violations of encapsulation

2022-05-04T17:30:00+00:00

Introduction.

We’d like to show another example of how difficulties found while testing can signal design problems in our code^[1].

We believe that a good design is one that supports the evolution of a code base at a sustainable pace and that testability is a requirement for evolvability. This is not something new, we can find this idea in many places.

Michael Feathers says “every time you encounter a testability problem, there is an underlying design problem”^[2].

Nat Pryce and Steve Freeman also think that this relationship between testability and good design exists^[3]:

“[…] We’ve found that the qualities that make an object easy to test also make our code responsive to change”

and also use it to detect design problems and know what to refactor:

“[…] where we find that our tests are awkward to write, it’s usually because the design of our target code can be improved”

and to improve their TDD practice:

“[…] sensitise yourself to find the rough edges in your tests and use them for rapid feedback about what to do with the code. […] don’t stop at the immediate problem (an ugly test) but look deeper for why I’m in this situation (weakness in the design) and address that.”^[4]

This is why they devoted talks, several posts and a chapter of their GOOS book (chapter 20) to listening to the tests^[5] and even added it to the TDD cycle steps:

Next we’ll show you an example of how we’ve recently applied this in a client.

The problem.

Recently I was asked to help a pair that was developing a new feature in a legacy code base of one of our clients. They were having problems with the following test^[6]:

that was testing the RealTimeGalleryAdsRepository class:

They had managed to test drive the functionality but they were unhappy with the results. The thing that was bothering them was the resetCache method in the RealTimeGalleryAdsRepository class. As its name implies, its intent was to reset the cache. This would have been fine, if this had been a requirement, but that was not the case. The method had been added only for testing purposes.

Looking at the code of RealTimeGalleryAdsRepository you can learn why. The cachedSearchResult field is static and that was breaking the isolation between tests. Even though they were using different instances of RealTimeGalleryAdsRepository in each test, they were sharing the same value of the cachedSearchResult field because static state is associated with the class. So a new public method, resetCache, was added to the class only to ensure isolation between different tests.

Adding code to your production code base just to enable unit testing is a unit testing anti-pattern^[7], but they didn’t know how to get rid of the resetCache method, and that’s why I was called in to help.

Let’s examine the tests in RealTimeGalleryAdsRepositoryTests to see if they can point to more fundamental design problems.

Another thing we can notice is that the tests can be divided in to sets that are testing two very different behaviours:

One set of tests, comprised of maps_all_ads_with_photo_to_gallery_ads, ignore_ads_with_no_photos_in_gallery_ads and when_no_ads_are_found_there_are_no_gallery_ads, is testing the code that obtains the list of gallery ads;
whereas, the other set, comprised of when_cache_has_not_expired_the_cached_values_are_used and when_cache_expires_new_values_are_retrieved is testing the life and expiration of some cached values.

This lack of focus was a hint that the production class might lack cohesion, i.e., it might have several responsibilities.

It turns out that there was another code smell that confirmed our suspicion. Notice the boolean parameter useCache in RealTimeGalleryAdsRepository constructor. That was a clear example of a flag argument^[8]. useCache was making the class behave differently depending on its value:

It cached the list of gallery ads when useCache was true.
It did not cache them when useCache was false.

After seeing all this, I told the pair that the real problem was the lack of cohesion and that we’d have to go more object-oriented in order to avoid it. After that refactoring the need for the resetCache would disappear.

Going more OO to fix the lack of cohesion.

To strengthen cohesion we need to separate concerns. Let’s see the problem from the point of view of the client of the RealTimeGalleryAdsRepository class, (this point of view is generally very useful because the test is also a client of the tested class) and think about what it would want from the RealTimeGalleryAdsRepository. It would be something like “obtain the gallery ads for me”, that would be the responsibility of the RealTimeGalleryAdsRepository, and that’s what the GalleryAdsRepository represents.

Notice that to satisfy that responsibility we do not need to use a cache, only get some ads from the AdsRepository and map them (the original functionality also included some enrichments using data from other sources but we remove them from the example for the sake of simplicity). Caching is an optimization that we might do or not, it’s a refinement of how we satisfy the responsibility but it’s not necessary to satisfy it, so, we might say that caching changes the “how” but not the “what”.

This matches very well with the Proxy design pattern ^[9] because it allows us to attach additional behaviour (caching) to the basic behaviour that satisfied the role that the client needs (“obtain the gallery ads for me”). This way instead of having a flag parameter (like useCache in the original code) to control whether we cache or not, we might add caching by composing two objects that implement the GalleryAdsRepository interface. One of them is the object with the basic behaviour, RealTimeGalleryAdsRepository, that would be in charge of getting ads from the AdsRepository and mapping them to gallery ads, and the other one, CachedGalleryAdsRepository, would cache the gallery ads. The object with the basic behaviour might not be called if the proxy decides it does not need to do so.

So we moved the responsibility of caching the ads to the CachedGalleryAdsRepository class which wraps the RealTimeGalleryAdsRepository class.

This is the code of the CachedGalleryAdsRepository class:

and these are its tests:

Notice how we found here again the two tests that were previously testing the life and expiration of the cached values in the test of the original RealTimeGalleryAdsRepository: when_cache_has_not_expired_the_cached_values_are_used and when_cache_expires_new_values_are_retrieved.

Furthermore, looking at them more closely, we can see how, in this new design, those tests are also simpler because they don’t know anything about the inner details of RealTimeGalleryAdsRepository. They only know about the logic related to the life and expiration of the cached values and that when the cache is refreshed they call a collaborator that implements the GalleryAdsRepository interface, this means that now we’re caching gallery ads instead of an instance of the SearchResult and we don’t know anything about the AdsRepository.

On a side note, we also improved the code by using the Duration value object from java.time to remove the primitive obsession smell caused by using a long to represent milliseconds.

Another very important improvement is that we don’t need the static field anymore.

And what about RealTimeGalleryAdsRepository?

If we have a look at its new code, we can notice that its only concern is how to obtain the list of gallery ads and mapping them from the result of its collaborator AdsRepository, and it does not know anything about caching values. So the new design is more cohesive than the original one. Notice how we removed both the resetCache method that was before polluting its interface only for testing purposes, and the flag argument, useCache, in the constructor.

We also reduced its number of collaborators because there’s no need for a Clock anymore. The Clock collaborator was needed for a different concern that is now taken care of by the proxy: CachedGalleryAdsRepository.

These design improvements are reflected in its new tests. They are now more focused, and can only fail if the obtention of the gallery ads breaks. Having only one reason to fail comes from testing a more cohesive unit with only one reason to change. Notice how these tests coincide with the subset of tests concerned with testing the same behaviour in the original tests of RealTimeGalleryAdsRepository:

Persisting the cached values between calls.

You might be asking yourselves, how are we going to ensure that the cached values persist between calls now that we don’t have a static field anymore.

Well, the answer is that we don’t need to keep a static field in our classes for that. The only thing we need is that the composition of CachedGalleryAdsRepository and RealTimeGalleryAdsRepository is created only once, and that we use that single instance for the lifetime of the application. That is a concern that we can address using a different mechanism.

We usually find in legacy code bases that this need to create something only once, and use that single instance for the lifetime of the application is met using the Singleton design pattern described in the design patterns book. The Singleton design pattern intent is to “ensure that only one instance of the singleton class ever exists; and provide global access to that instance”. The second part of that intent, “providing global access”, is problematic because it introduces global state into the application. Using global state creates high coupling (in the form of hidden dependencies and possible actions at a distance) that drastically reduces testability.

Instead we used the singleton pattern^[10]. Notice the lowercase letter. The lowercase ’s’ singleton avoids those testability problems because its intent is only to “ensure that only one instance of some class ever exists because its new operator is called only once”. The problematic global access part gets removed from the intent. This is done by avoiding mixing object instantiation with business logic by using separated factories that know how to create and wire up all the dependencies using dependency injection.

We might create this singleton, for instance, by using a dependency injection framework like Guice and its @Singleton annotation.

In this case we coded it ourselves:

Notice the factory method that returns a unique instance of the GalleryAdsRepository interface that caches values. This factory method is never used by business logic, it’s only used by instantiation logic in factories that know how to create and wire up all the dependencies using dependency injection. This doesn’t introduce testability problems because the unique instance will be injected through constructors by factories wherever is needed.

Conclusions.

We show a recent example we found working for a client that illustrates how testability problems may usually point, if we listen to them, to the detection of underlying design problems. In this case the problems in the test were pointing to a lack of cohesion in the production code that was being tested. The original class had too many responsibilities.

We refactored the production code to separate concerns by going more OO applying the proxy design pattern. The result was more cohesive production classes that led to more focused tests, and removed the design problems we had detected in the original design.

Acknowledgements.

I’d like to thank my Codesai colleagues for reading the initial drafts and giving me feedback.

Notes.

[1] We showed another example of this relationship between poor testability and design problems in a previous post: An example of listening to the tests to improve a design.

[2] Listen to his great talk about this relationship: The Deep Synergy Between Testability and Good Design

[3] This is the complete paragraph from chapter 20, Listening to the tests, of the GOOS book: “Sometimes we find it difficult to write a test for some functionality we want to add to our code. In our experience, this usually means that our design can be improved — perhaps the class is too tightly coupled to its environment or does not have clear responsibilities. When this happens, we first check whether it’s an opportunity to improve our code, before working around the design by making the test more complicated or using more sophisticated tools. We’ve found that the qualities that make an object easy to test also make our code responsive to change.”

[4] This quote is from their post Synaesthesia: Listening to Test Smells.

[5] Have a look at this interesting series of posts about listening to the tests by Steve Freeman. It’s a raw version of the content that you’ll find in chapter 20, Listening to the tests, of their book.

[6] We have simplified the client’s code to remove some distracting details and try to highlight its key problems.

[7] Vladimir Khorikov calls this unit testing anti-pattern Code pollution.

[8] A flag Argument is a kind of argument that is telling a function or a class to behave in a different way depending on its value. This might be a signal of poor cohesion in the function or class.

[9] A proxy is a wrapper of an object that implements the same interface and controls access to it. A proxy may restrict what a client does by controlling access to some functionality, or it may restrict what a client knows by performing actions that are invisible and unknown to the client. Some examples of using proxies are caching when operations on the real object are resource intensive, or checking preconditions before operations on the real object are invoked. See Design Patterns: Elements of Reusable Object-Oriented Software.

[10] Miško Hevery talks about the singleton pattern with lowercase ‘s’ in its talk Global State and Singletons at 10:20: “Singleton with capital ’S’. Refers to the design pattern where the Singleton has a private constructor and has a global instance variable. Lowercase ’s’ singleton means I only have a single instance of something because I only called the new operator once.”

References.

Photo from cottonbro in Pexels.

Role tests for implementation of interfaces discovered through TDD

2022-04-03T17:30:00+00:00

Introduction.

Working through the first three iterations of a workshop’s exercise, we produced several application services that at some point collaborated with a users repository that we hadn’t yet created so we used a test double in its place in their tests.

These are the tests:

In these tests, every time we allow or expect a method call on our repository double, we are defining not only the messages that the users repository can respond to (its public interface)^[1] but also what its clients can expect from each of those messages, i.e. its contract.

In other words, at the same time we were testing the application services, we defined from the point of view of its clients the responsibilities that the users repository should be accountable for.

The users repository is at the boundary of our domain. It’s a port that allows us to not have to know anything about how users are stored, found, etc. This way we are able to just focus on what its clients want it to do for them, i.e., its responsibilities.

Focusing on the responsibilities results in more stable interfaces. As I heard Sandi Metz say once:

“You can trade the unpredictability of what others do for the constancy of what you want.”^[2]

which is a very nice way to explain the “Program to an interface, not an implementation”^[3] design principle.

How those responsibilities are carried out is something that each different implementation (or adapter) of the users repository port is responsible for. However, the terms of the contract that its clients rely on, must be respected by all of the adapters. They must play their roles. In this sense, any adapter must be substitutable by any other without the clients being affected, (yes, you’re right, it’s the Liskov substitution principle).

Role or contract tests.

The only way to ensure this substitutability is by testing each adapter to check if it also respects the terms of the contract, i. e. it fulfils its role. Those tests would ensure that the Liskov substitution principle is respected^[4].

I will use the term role test used by Sandi Metz because contract test has become overloaded^[5].

Ok, but how can we test that all the possible implementations of the user repository respect the contract without repeating a bunch of test code?

Using shared examples in RSpec to write role tests.

There’s one very readable way to do it in Ruby using RSpec.

We created a RSpec shared example in a file named users_repository_role.rb where we wrote the tests that describes the behaviour that users repository clients were relying on:

Then for each implementation of the users repository you just need to include the role tests using RSpec it_behaves_like method, as shown in the following two implementations:

You could still add any other test that only has to do with a given implementation in its specific test.

This solution is very readable and reduces a lot of duplication in the tests. However, the idea of role tests is not only important from the point of view of avoiding duplication in test code. In dynamic languages, such as Ruby, they also serve as a mean to highlight and document the role of duck types that might otherwise go unnoticed because there is no interface construct.

Acknowledgements.

I’d like to thank my Codesai colleagues for reading the initial drafts and giving me feedback.

Notes.

[1] Read more about objects communicating by sending and receiving messages in Alan Kay’s Definition Of Object Oriented

[2] You can find a slightly different wording of it in her great talk Less - The Path to Better Design at 29’48’’.

[3] Presented in chapter one of Design Patterns: Elements of Reusable Object-Oriented Software book.

[4] This is similar to J. B. Rainsberger’s idea of contract tests mentioned in his Integrated Tests Are A Scam talk and also to Jason Gorman’s idea of polymorphic testing.

[5] For example Martin Fowler uses contract test to define a different concept in Contract Test.

References.

Photo from Anna Rye in Pexels

Restringiendo interfaces II: Modelando apariencias

2022-02-19T00:00:00+00:00

Volvemos con la segunda parte de Restringiendo Interfaces. En esta ocasión hablaremos de cómo heredar modelos existentes puede adulterar su diseño, provocando la ilusión de que es la forma más fiel de modelar el dominio del problema. En este post veremos que, para implementar diseños más fieles al problema, debemos cuidar el proceso de creación de interfaces, y evitar dejarnos embaucar por modelos heredados que podrían limitar nuestra visión..

Para plantear esta idea, usaremos un problema sencillo, estudiando, en primer lugar, un posible modelado que presenta los problemas de diseño que queremos evitar. A continuación, comentaremos un modelado alternativo que mejora el enfoque inicial resolviendo sus problemas. Modelaremos el recuento de puntos de un partido de tenis, pero centrándonos sólo en el subproblema de conseguir un punto de set. Partiremos de la siguiente definición:

Un marcador de tenis se compone de sets, puntos de set, y puntos de juegos. Para ganar un punto de set, hay que jugar varios puntos de juego. Los jugadores parten de 0-0, cuando un jugador gana un punto se suma 15 al marcador, por ejemplo, 0-15. Una vez llegas a 30, suman 10, es decir, 0-40, y si ese jugador gana el siguiente punto, ganaría el punto de set. En el caso de empatar en 40-40 (denominado Deuce), se procede a conceder ventajas de juego, por ejemplo Ad.-40. Si el jugador que va por detrás marca otro punto de juego, el marcador regresa a Deuce, y se volvería a repetir que si algún jugador gana el siguiente punto de juego, se concede una ventaja. Para ganar el punto de set, se necesita ganar un punto cuando tienes una ventaja, o lo que es lo mismo, se gana con una diferencia de dos puntos por encima del otro jugador.

Una progresión del marcador de un set válida sería la siguiente:

0-0 -> 0-15 -> 15-15 -> 15-30 -> 30-30 -> 40-30 -> 40-40 -> Ad.-40

Con esta descripción podríamos empezar a modelar. Como dijimos partiremos de una implementación factible y la iremos transformando poco a poco para exponer las ideas que pretendo explorar en este post. La implementación inicial pertenece a enunciado de la Kata de refactoring Tennis.

Lo que hace este código es llamar al método wonPoint(playerName) con el nombre del jugador (o equipo) que marca el punto y sumarle un punto en el marcador. Luego, el cliente que consume este código, llama al método getScore() que devuelve la puntuación con un tipo String que representa los puntos de juego en la jerga del tenis.

A partir de este código podemos analizar qué heurísticas podrían haber llevado a esta implementación. Lo primero que observamos es que para determinar los puntos de un jugador, se emplean operaciones aritméticas, es decir, cada vez que un jugador gana un punto,se almacena el estado en los campos mScore1 o mScore2. Además, los valores numéricos empleados para operar con los puntos no son los mismos que se emplean para representar los puntos de juego de un set, en su lugar, se usa una serie matemática infinita de números enteros para calcular la puntuación del jugador.

Estamos ante un problema típico de implementación, como el que vimos en el post anterior: existe un Connascence of Meaning, es decir, hay valores en el código que tienen un significado implícito no reflejado en el diseño. Este problema de diseño también lo podríamos haber identificaco mediante otra heurística: los Code Smells. En este caso estaríamos ante un Data Clump. Los Data Clumps hacen referencia a aquellos datos datos que sólo tienen sentido cuando están juntos, y que de forma implícita se relacionan. Si uno de esos datos cambia, el otro se ve forzado a cambiar conjuntamente. Este ejemplo lo podemos encontrar en la representación de la serie aritmética en los campos mScore1 y mScore2y el método getScore(), ambos datos se interrelacionan, pues score necesita conocer la lógica de la progresión de la serie para poder operar con ella y saber cuál es el valor de marcador que tiene que devolver y la serie conoce como getScore() emplea sus datos para poder identificar el marcador y por tanto, no puede cambiar libremente. Podríamos suavizar este problema de diseño de forma implícita si los números que empleamos en estas operaciones aritméticas fuesen los mismos que usa el problema en su definición (0, 15, 30, 40). Pero nuestro diseño seguiría sin utilizar tipos complejos para representar y forzar que sólo podamos elegir valores correctos, ya que la interfaz actual no restringe qué valores se pueden usar. La definición implícita que generaríamos sólo sería válida si el desarrollador conoce bien las reglas del tenis, en caso contrario, estaríamos en la casilla de salida, es decir, la solución de limitar los números utilizados en las operaciones aritméticas, no ayudaría a hacer más explícitas las reglas de negocio ni adocumentar el comportamiento del código para facilitar su comprensión.

El problema que presenta el al método getScore() se debe a que la elección de representar los puntos como un entero que sigue una serie en incrementos de uno, fuerza a mantenerlos puntos como estado local para poder determinar el momento del juego en el que se está (es decir, los marcadores entre el 0-0 y Deuce, Advantage y Victoria) y saber si hay algún jugador que va por delante, hay empate o se ha ganado el punto de set. El hecho de que cuando un jugador gana un punto de juego se incremente la serie, obliga a que el método getScore() tenga que absorber el comportamiento del cálculo de puntos y que no tenga exclusivamente su representación.

Este diseño tiene por tanto dos problemas pronunciados:

Representar los posibles estados del problema con números ajenos a su definición. Esto ha complicado el algoritmo que permite obtener los puntos actuales de ambos jugadores agravando el Connascence of Meaning. Los posibles valores de la serie implican que el mismo valor puede significar diferentes cosas según el estado que se encuentre el marcador y a medida que se altere. Lo que nos lleva al segundo problema.
La identidad del mismo valor cambia y puede tener un significado distinto, y su ”Meaning”, se superpone a la serie matemática. Este tipo de acoplamiento se denomina Connascence of Algorithm, que implica que varias partes de nuestro diseño conocen la lógica interna del algoritmo e implícitamente aceptan un contrato sobre la transformación de los datos. Este problema lo encontramos a medida que avance la serie a medida que transcurre el partido. Por ejemplo, pongamos que los jugadores van 40-40 (Deuce), el estado de nuestra clase la primera vez que llegan a esta puntuación es de 3-3. Pero hay diferentes estados de nuestra serie que significan también empate, como por ejemplo: 4-4, 5-5, 99-99… Pero en un marcador de 4-2, el cuatro significa victoria, mientras que en un 4-3, significa ventaja. Por tanto, el mismo valor puede significar hasta cuatro cosas distintas.

Implementando el rediseño

El primer paso y el más barato, en términos de economía de software, es eliminar el tipo String del playerName y lo sustituimos por un tipo enumerado que represente a los dos posibles jugadores (o equipos) que pueden jugar un partido de tenis, eliminando así el Connascence of Meaning del player y a su vez protegiéndonos con el compilador de posibles entradas no válidas. Luego para resolver el problema de la serie emplearemos sólo el rango de valores posibles para los puntos de juego de un partido de tenis.

Este sería el resultado de nuestra primera transformación:

El siguiente paso es reducir la complejidad ciclomática en el método getScore() que calculaba la representación de los puntos de los jugadores. Para conseguirlo, primero, duplicamos el código del for que contiene. Y a continuación, hacemos que sólo emplee los valores de los puntos posibles en un juego de tenis mediante un switch. Con esto llevamos la lógica del cálculo aritmético al método wonPoint(Player), que ahora es capaz de reflejar, usando estos valores, cómo funciona un marcador, consiguiendo así centralizar en un único lugar esa responsabilidad En el proceso hemos inventado dos nuevos valores que no pueden soportar una de las lógicas del problema, la ventaja de un jugador y la victoria. Esto se debe a que tanto la ventaja de un jugador como la victoria en el punto de set no tienen valores numéricos asociados. Los valores elegidos para representar estos últimos son el 41, para la ventaja de algunos de los jugadores y el 50, para la victoria. El porqué de esta última decisión la podemos entender como un paso intermedio en el refactor. Ahora mismo en el proceso de descubrir nuestro diseño optamos por elegir valores ajenos a la definición del problema para que generen ruido y la necesidad de eliminarlos al final.

Con este refactor hemos obtenido nuevos aprendizajes sobre el problema:

Los valores de victoria y ventaja no son numéricos, son estados que se representan de forma distinta al resto del conjunto de valores numéricos posibles. La nueva implementación que elimina la serie matemática que almacenaba el estado y que se usaba para calcular quién iba ganando, nos desvela otra perspectiva sobre el diseño. Gracias al marcador de ventaja y la victoria, podemos exponer esta nueva interpretación, en un Deuce el jugador que gane el siguiente punto y adquiera ventaja (40-Ad.), sólo tiene dos posibles estados siguientes, volver al Deuce o ganar el punto. Además otro detalle que podemos observar es que existen diferentes combinaciones de puntos desde las que podemos alcanzar la victoria de algún jugador.
Podemos deducir que estamos ante a una máquina de estados finita, lo cual nos permitiría replantear el algoritmo desde otra perspectiva. Si representamos los puntos como transiciones de estado sobre un diagrama de estados tendríamos algo tal que así:

Marcador como máquina de estados

Tenemos 20 posibles estados dentro de nuestro problema, algo bastante sencillo de modelar y que nos permitiría eliminar las operaciones aritméticas de nuestro código. Representar los puntos mediante valores numéricos nos impedía ver otras opciones de diseño más sencillas con las que plantear el problema y limitar el dominio de posibles valores.

Marcador como máquina de estados simplificada

Podemos también emplear una simplificación de la máquina de estados a través de un transductor de estados como la máquina de Mealy y a partir de las entradas identificar estados que son comunes y que representan a un único estado duplicado múltiples veces. En este caso podemos reducir los 20 estados a un total de 4, Initial, para los valores comprendidos entre el 0-0 y el 40-40, Deuce, para 40-40, Advantage para los marcadores 40-Ad. y Ad.-40 y Win, para cuando un jugador gana la partida, quedando de esta manera:

Un detalle importante es entender que hay múltiples procesos para alcanzar esta solución. En el caso que nos atañe, lo hemos conseguido a través del análisis del estado a partir de los posibles valores del tenis. Pero si hubiéramos partido del análisis del comportamiento en vez de enfocarnos en los valores, hubiéramos llegado al mismo sitio. El State Pattern que vamos a emplear para diseñar la nueva solución permite desde el análisis del problema, encontrar el patrón en el problema por las fuerzas y motivaciones detrás del mismo. No es necesaria usar la fuerza bruta para conseguir llegar a la solución que ahora veremos, en este caso he querido que sea así por analizar este caso que me parece curioso, pero es importante no confundir State Pattern = Máquina de estados finita.

Luego de este análisis, podemos empezar a transformar el código utilizando el State Pattern. Este patrón nos ayudará a representar los diferentes estados de las máquinas que hemos diseñado a partir del código anterior. También tiene un valor añadido porque solventará el Data Clump del getScore() y y mScore1 y mScore2 en los nuevos objetos que representan el estado. Pero lo más importante es que cada lógica de transición de un estado a otro estará albergada dentro de la lógica de las diferentes clases que surjan en la implementación.

Este código es el que representa la primera máquina de estados. Esta sería la propuesta inicial de la implementación. Hemos eliminado las operaciones aritméticas y hemos creado el conjunto de transiciones de estados posibles a través de una nueva clase Scoreboard que aglomera la puntuación actual de ambos jugadores y cuando alguno de los dos marca un nuevo punto de juego, se transiciona a otro estado que refleje la victoria de ese jugador. Esta nueva clase absorbe ambos switch de TennisGame y se reemplazan a través del refactor Replace conditional with Polymorphism que lo elimina de los método wonPoint(Player) y getScore().

Si ahora eliminamos la duplicación de estados que hemos dicho anteriormente y representamos la máquina de estados simplificada el resultado será el siguiente:

Como se puede observar, la clase ScoreBoard se convierte en interfaz y deja de ser un enumerado, y tenemos diferentes implementaciones de la interfaz en las clases Initial, Deuce, Advantage y Win. Initial absorbe la lógica de transición entre los estados duplicados y es la que avanza de estado una vez se llega a 40-40, que transiciona al estado Deuce. Deuce concederá ventajas avanzando al estado Advantage y este último avanza a Win si un jugador ganó o volverá a Deuce si vuelven a empatar.

Ambos diseños son inmutables, las transiciones entre estados no producen cambio interno de estado. En la primera implementación al ser un enumerado es bastante fácil de ver pues es un enumerado sin estado interno. Pero en el caso de la implementación de la máquina de estados simplificada hay que observar que aunque Initial, alberga estado, no lo modifica internamente, lo que hace es crear un estado nuevo a partir de su propio estado modificado, que puede ser mantenerse en el estado actual o transicionar a otro estado con estos nuevos valores.

Conclusiones

Como comenté en el post anterior, la clave de diseñar interfaces no trata sólo de definir interfaces a prueba de errores humanos, sino también hacerlas semánticas. Esto lo hemos visto con ambas implementaciones, pues ambas son restrictivas y semánticas.

En el caso de la Initial, Deuce, Advantage y Win, hemos creado un nuevo término no existente en la jerga para expresar un abstracción subyacente en el modelo, mientras que la otra si que es fiel a la jerga existente. Ambas opciones son perfectamente válidas y a la hora de elegir el diseño final es tener claros los ejes de cambio [1] [2] de nuestro sistema. En el caso del tenis es sencillo, al ser un problema acotado y definido, podríamos quedarnos con la solución con 20 estados aunque su dominio sea espacialmente mayor por la duplicidad del mismo estado varias veces. La solución de cuatro estados coloca en un sitio más cohesivo la lógica de a qué estado tiene que avanzar. Ante un problema que no fuera de dominio finito preferiría la solución con menos estados ya que su diseño es más fácil evolucionar para satisfacer nuevas necesidades de negocio. Así que, aquí te dejo elegir la solución que más consideres oportuna para la Kata Tennis, elige tus tradeoffs y como dice Richard Hickey “Pick your poison”.

Es muy valioso que al diseñar intentamos siempre evaluar desde múltiples heurísticas los problemas que podemos encontrar en nuestros diseños. En esta kata concretamente, esta práctica nos ha aportado mucho porque identificar los diferentes tipos de Connascence (Meaning y Algorithm), el code smell Data Clump y ver que las fuerzas del problema se corresponden con las del patrón estado ha empujado a nuestro diseño al mismo destino gracias a triangular los mismos síntomas desde diferentes perspectivas o heurísticas. Lo interesante es que en este caso el resultado de aplicar las diferentes heurísticas se reforzaban unas a otras ya que se apuntaban a la misma dirección de diseño.

Cuando empezamos a definir el ejemplo del juego de tenis encontramos varios elementos que definen el lenguaje del espacio del problema, y surgen valores o elementos que representan el dominio del mismo. Cuando se nos da un código como el inicial, que toma ciertas decisiones de diseño que resuelven el problema obviando este lenguaje/elementos/dominio,** nos alejamos de encontrar una solución que sea más semántica con el problema y dejamos permear en el diseño detalles de bajo nivel que distraen a quien lo lee.** Emplear únicamente la serie aritmética infinita dejaba exponer un diseño más acorde al tipo de problema que presenta la kata tenis y la primera transformación que hicimos fue seguir asumiendo que el problema era exclusivamente matemático, pues la solución ya lo contemplaba, y los valores posibles dentro del enunciado, a excepción de la ventaja y victoria, eran numéricos. Cuando modelamos un problema es necesario mirarlo o tratar de representarlo desde varios prismas, para evitar caer en la trampa de la solución aparente. No hay que caer en la trampa de elegir la opción más sencilla de percibir, pero que representa el problema con un diseño más complejo, que escoger la opción menos aparente, pero que más se adapta al problema. Pensar en los límites de tus valores de entrada puede ser una heurística que te ayude a acotar el problema y guiarte a modelar tus interfaces correctamente y seguir destilando el problema hasta dar con el diseño que buscas. Además es útil conocer y aplicar otras heurísticas, como el connascence, los code smells o los patrones, para contrastar el diseño que vas encontrando.

Espero que te haya gustado el post y que me des feedback de qué te ha parecido.

Referencias:

Refactoring, Martin Fowler. Mencionados en el post: Refactoring to Polymorphism y Data Clump.
Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Ralph Johnson, John Vlissides, Richard Helm. El mencionado en el post State Pattern.
About Connascence, Manuel Rivero.
Examples lists in TDD, Manuel Rivero.
Single Responsibility ¿Principle?, The Big Branch Theory podcasts.
Code Smells, Martin Fowler.
Data clumps, primitive obsession and hidden tuples, Manuel Rivero.
Refactoring Kata Tennis to State Pattern, Manuel Rivero.

Notes on LSP from Agile Principles, Practices and Patterns book

2022-02-14T06:00:00+00:00

I continue sharing my notes on SOLID to prepare the ground for the upcoming The Big Branch Theory Podcast episode about Liskov Substitution Principle.

Ok, so these are the raw notes I took while reading the chapter devoted to Liskov Substitution Principle (LSP) in Robert C. Martin’s Agile Principles, Practices and Patterns in C# book (I added some personal annotations between brackets):

“The primary mechanisms behind the OCP are abstraction and polymorphism” <- [but in some languages inheritance is needed to have polymorphism]
”.. questions addressed by the LSP”
- “What are the desgin rules that govern this particular use of inheritance hierarchies?”
- “What are the characteristics of the best inheritance hierarchies?”
- “What are the traps that will cause us to create hierarchies that do not conform to OCP?”
LSP -> “Subtypes must be substitutable for their base types”
“Violating LSP often results in the use of runtime type checking in a manner that grossly violates OCP”
“a violation of LSP is a latent violation of OCP”
“… more subtle way of violating LSP” -> “.. use of IS-A relationship is sometimes thought to be one of the fundamental techniques of OOA, a term frequently used but seldom defined […]. However this kind of thinking can lead to some subtle yet significant problems. Generally, these problems are not foreseen until we see them in code”
Invariants -> “those properties that must always be true regardless of state”
“… when the creation of a derived class causes us to make changes to the base class, it often implies that the design is faulty”
“Validity is not intrinsic”
- “LSP leads us to a very important conclusion: A model, viewed in isolation, cannot be meaningfully validated. The validity of a model can be expressed only in terms of its clients.”
- “When considering whether a particular design is appropriate, one cannot simply view the solution in isolation. One must view it in terms of the reasonable assumptions made by the users of that design”
- “Therefore, as with all other principles, it is often best to defer all but the most obvious LSP violations until the related fragility has been smelled”
“IS-A is about behavior” -> “… it is behavior that software is really all about. LSP makes it clear than in OOD, the IS-A relationship pertains to behavior that can be reasonably assumed and that clients depend on” <- [related to behavioural approach to modelling shown in David West’s Object Thinking, or Rebecca Wirfs-Brock’s Designing Object-Oriented Software]
“How do you know what your clients will really expect? There is a technique for making those reasonable assumptions explicit and thereby enforcing LSP…” -> Design By Contract (DBC)
“Using DBC, the author of a class explicitly states the contract of that class. The contract informs the author of any client code if the behaviors that can be relied on. The contract is specified by declaring preconditions and postconditions for each method. The preconditions must be true for the method to execute. On completion, the method guarantees that the postconditions are true.”
“…the rule for preconditions and postconditions of derivatives, as stated by Meyer, is: ‘A routine redeclaration [in a derivative] may only replace the original precondition by one equal or weaker, and the original postcondition by one equal or stronger’” <- “X is weaker than Y if X does not enforce all the constraints of Y. It does not matter how many new constraints X enforces”
“In other words, when using an object through its base class interface, the user knows only the preconditions and postconditions of the base class. Thus, derived objects must not expect such users to obey preconditions that are stronger than those required by the base class. Also, derived classes must conform to all the postconditions of the base. That is, their behaviors and outputs must not violate any of the constraints established for the base class.” “Users of the base class must not be confused by the output of the derived class.” <- [a form of the Least Astonishment Principle]
“Contracts can […] be specified by writing unit tests. By thoroughly testing the behavior of a class, the unit tests make the behavior of the class clear. Authors of the client code will want to review the unit tests in order to know what to reasonably assume about the classes they are using”
“It’s a big advantage not to have to know or care what kind of [sth] you are using. It means that the programmer can decide which kind of [sth] is needed in each particular instance, and none of the client functions will be affected by that decision”
“…the problem with conventions: they have to be continually resold to each developer”
“There are occasions when it is more expedient to accept a subtle flaw in polymorphic behavior than to attempt to manipulate the design into complete LSP compliance. Accepting compromise instead of pursuing perfection is an engineering trade-off. A good engineer learns when compromise is more profitable that perfection. However, conformance to LSP should not be surrendered lightly. The guarantee that a subclass will always work where its base classes are used is a powerful way to manage complexity. Once it is forsaken we must consider each subclass individually.”
“Factoring is a powerfull tool. If qualities can be factored out of two subclassses, there is the distinct possibility that other classes will show up later that need those qualities too”
“Rebecca Wirfs-Brock, on factoring:”
- “We can state that if a set of classes all support a common responsibility, they should inherit that responsibility from a common superclass”
- “If a common superclass does not already exist, create one, and move the common responsibility to it. After all such a class is demonstrably useful […]. Isn’t it conceivable that a later extension of your system might add a new subclass that will support those same responsibilitties in a new way? This new superclass will probably be an abstract class”
“Some simple heuristics can give you some clues about LSP violations. These heuristics all have to do with derivative classes that somehow remove functionality from their base class. A derivative that does less that its base is usually not substitutable for that base and therefore violates LSP” <- “The presence of degenerate functions in derivatives is not always indicative of an LSP violation, but it’s worth looking at them when they occur” [see Refused Bequest code smell]
“The OCP is at the heart of many of the claims made for OOD. […] The LSP is one of the prime enablers of OCP”
“The substitutability of subtypes allows a module, expressed in terms of a base type, to be extensible without modification. That substitutability must be sth that developers can depend on implicitly. Thus, the contract of the base type has to be well and prominently understood, if not explicitly enforced, by the code”
“The […] IS-A is too broad to act as a definition of a subtype. The true definition of a subtype is substitutable, where substitutability is defined by either an explicit or implicit contract”

Foto de Miguel Á. Padriñán en Pexels

Mutando para simplificar

2022-02-11T00:00:00+00:00

Una de las herramientas que mencionamos en nuestro curso de TDD es mutation testing ^[1]. Para quien no esté familiarizado, es una herramienta que, en líneas generales, lanza nuestra batería de tests haciendo modificaciones (mutaciones) del código de producción que introducen defectos. Si un test falla, significa que nuestros tests protegen contra el defecto introducido (o en términos de mutation testing, nuestros tests matan al mutante). En cambio, si todos los tests pasan, significa que los tests no protegían contra el defecto introducido.

Personalmente, el mutation testing no es algo que use a diario, pero sí que es valioso conocer su existencia si te encuentras en el caso de que necesitas cambiar una zona de código sensible en la que un bug supondría perder mucho dinero.

Un ejemplo muy sencillo que puede servir para mostrar su potencia es cuando estamos haciendo comprobaciones de rangos de números. Por ejemplo, en la kata ohce hay una parte de la funcionalidad que saluda de diferentes maneras según la hora del día:

Entre las 20 y las 6, ohce te dirá ¡Buenas noches!
Entre las 6 y las 12, ohce dirá ¡Buenos días!
Entre las 12 y las 20, dirá ¡Buenas tardes!

Si no tenemos cuidado al testear estos rangos, podemos acabar con una batería de tests en verde que pruebe que si son las 8 te dice ¡Buenos días!, si son las 14 te responde ¡Buenas tardes! y a las 23 ¡Buenas noches!. Con estos tres casos, tendremos los tests en verde y 100% de cobertura, genial, ¿verdad?

Seguridad infundada

Si ejecutasemos una herramienta de mutation testing como Stryker, nos encontraríamos la sorpresa de que 6 mutaciones en nuestro código sobrevivirían a los casos de prueba que tenemos definidos ahora mismo.

Mutaciones supervivientes en una línea de código

En la figura de arriba podemos ver una sección del informe que genera Stryker. Nos está marcando que en ese if ha hecho 3 mutaciones que han sobrevivido, siendo una de ellas el cambiar un >= por >. ¿Por qué ha pasado esto? Porque nuestros tests solamente estaban fijando un valor en el interior del rango, el número 8, y no sus extremos.

Si cambiamos los tests de forma que fijen los extremos de los rangos y volvemos a ejecutar Stryker, comprobaremos que no sobrevivirá ninguna mutación.

Informe de Stryker por consola mostrando 0 mutaciones supervivientes^[2]

Simplificando nuestro código

Hasta ahora hemos visto cómo mutation testing nos puede ayudar a encontrar aquellos tests que hemos olvidado hacer. Ahora me gustaría hablar de un caso particular que nos encontramos recientemente en una sesión de práctica deliberada con la gente de Audiense.

Cuando una de las parejas estaba usando mutation testing para comprobar que habían hecho todos los tests necesarios para cuadrar el rango de horas, esperábamos encontrar una lista de mutantes parecida a la que aparece en la figura de más arriba. Sin embargo, nos encontramos con que había sobrevivido un único mutante:

Mutación de Stryker que sobrevive borrando una condición

Resulta que la condición de hour >= 6 era innecesaria, ya que la mutación introducida al cambiar dicho código por true sobrevivía (los tests seguían pasando). Pero revisamos los tests y estaban “bien” así que, ¿qué está pasando?

Si nos paramos a pensar un poco, debido a cómo están estructurados los ifs, entraremos en el primer caso si la hora es mayor igual que 20 o menor que 6. Si esta condición es falsa, significa que la hora es menor que 20 y mayor o igual que 6, así que la condición que tenemos de hour >= 6 siempre va a ser true.

Sabiendo esto, podemos decidir “simplficar” el código y dejar la condición en el segundo if simplemente como hour < 12. Cabría preguntarse si este cambio merece la pena o no. A mi de entrada me pareció buena idea, todo lo que sea borrar código siempre me parece bien. El código quedaría así:

Sin embargo, el código resultante no será fácil de entender para la gente que tendrá que mantenerlo. Aunque podríamos sacar funciones privadas para mejorar su comprensión de las condiciones de los ifs, hemos hecho que el orden de ejecución de los ifs sea importante. Imaginemos que alguien modifica el orden de las comprobaciones. Si el if de los “Buenos días” lo pusiéramos el primero, romperíamos los tests, porque haríamos que para las 4 de la mañana diga Buenas noches en lugar de Buenos días^[3].

Para evitar estos problemas seguramente decidiría no borrar la condición innecesaria e ignorar el mutante que ha sobrevivido. Otra opción podría ser refactorizar el código para que los ifs estén en el mismo orden que vimos en la primera solución de la kata, lo cual, no dejaría sobrevivir a ningún mutante.

Conclusión

Como hemos visto, mutation testing es una herramienta muy útil que nos puede ayudar a encontrar tests que se nos han olvidado y asegurar más nuestro código en las zonas más críticas. Configurarlo para nuestro proyecto es relativamente sencillo (al menos ese es el caso con Stryker en Javascript o PIT en Java), pero tenemos que saber interpretar los datos que nos da y decidir si debemos añadir tests, o bien modificar nuestro código para que mate todas las mutaciones sin perder legibilidad.

Agradecimientos

Me gustaría agradecer a mi compañero Manuel Rivero por invitarme a impartir varias sesiones de práctica deliberada con él donde me pude encontrar con este caso, y a la gente de Audiense por su asistencia, especialmente a Iván Portillo y Roberto Segura porque fue con ellos con quién vimos este curioso caso de mutation testing. Y por último, gracias a mis compañeros de Codesai por el feedback en este post.

Notas

[1] En este otro post hablamos también de mutation testing para el desarrollo de la librería reffects.

[2] En el informe aparece un timeout porque en el código de la kata hay un bucle que al cambiar una condición se convierte en un bucle infinito y los tests no terminan de ejecutarse.

[3] Aquí tendríamos un ejemplo de Connascence of Execution.

Restringiendo interfaces

2022-01-31T00:00:00+00:00

Una heurística que empleo para diseñar software, y considero fundamental a la hora de crear interfaces o APIs claras y orientadas al negocio, es restringir con tipos los errores que podemos introducir en nuestro diseño al consumir estas APIs dentro de nuestro propio sistema o al ofrecerlas como parte de una librería externa.

En este post hablaré sobre cómo limitar tus interfaces de esta manera facilita su consumo. Además intentaré ejemplificar explicando mis preferencias a la hora de cómo modelar un problema de negocio.

Disclaimer: El ejemplo trata de ser didáctico, pero no muy alejado de la realidad, se establece un caso de uso simple pero factible para intentar establecer mi argumento sin tener que extenderme demasiado con detalles del problema.

Imaginemos que tenemos una startup que quiere ofrecer a sus usuarios la posibilidad de crear recordatorios para el día de hoy, Estos recordatorios se componen de cuatro opciones que damos a elegir. La hora del día que quiere que se le recuerde, los minutos en intervalos de 15 min en esa hora que ha elegido (es decir, 00:00, 00:15, 00:30, 00:45), el mensaje que quiere que se le recuerde y además la prioridad que tiene ese recordatorio si el usuario tiene varios en esa misma hora y en el mismo intervalo de minutos para dar más prioridad en cómo queremos que se le notifique al usuario los recordatorios que tiene y el orden que les aparece.

Una posible implementación de este API podría ser la siguiente:

Como se ve, hemos indicado todos los parámetros necesarios para que el usuario pueda registrar las necesidades que podría tener al usar nuestra aplicación para crear recordatorios en el mismo día.

Una posible implementación de este método, podría ser la siguiente:

Ahora, para prevenir los posibles errores que podríamos introducir usando esta API, podemos controlar los parámetros que le llegan al método haciendo que, por ejemplo, no se pueda dar el caso de crear un recordatorio que sea a las 25:62. Además, también queremos que el usuario disponga de tres niveles de prioridad para sus recordatorios. Para resolver este problema podríamos hacer lo siguiente:

En esta última implementación he utilizado Defensive Programming con el objetivo de evitar la introducción de valores erróneos pero admitidos por el tipo que se usa en la interfaz (las horas de un día por ejemplo).

Con esta implementación, nos sería suficiente para establecer la idea que quiero transmitir. Normalmente cuando diseñamos software, casi de forma automática, empleamos tipos básicos del lenguaje, para modelar las reglas de negocio. Esto tiene un problema de que no estamos haciendo explícitos los posibles valores que pueden pasar los que consumen nuestras APIs. Una buena interfaz es aquella que, aparte de ser semántica, limita los errores que puedo cometer cuando trato de usarla.

El interfaz del API que hemos creado tiene un problema de diseño muy claro, nos permite llamar a nuestros métodos con valores incorrectos y además, el rango de posibles valores incorrectos es mucho más grande que el de valores correctos, es decir, si usamos el tipo Integer para representar horas y minutos tenemos casi 4,3 millones de valores posibles frente a tan sólo 24 valores correctos para las horas, 60 para los minutos y 3 para la prioridad. Estamos eligiendo un diseño de interfaz en el que es mucho más probable fallar que acertar a la hora de pasar un valor como parámetro.

Este diseño sufre del Code Smell, Primitive Obsession y que es básicamente la razón de este post. Aparte del tema de la elección de horas y minutos, este problema también lo sufre el parámetro prioridad. Con el entero que representa este valor, no podemos saber si la prioridad es ascendente o descendente (si el cero es el más prioritario o lo es el tres). Lo que nos hace darnos cuenta que el verdadero problema que subyace en este diseño es un Connascence of Meaning que implica que varios puntos de nuestro diseño tienen que conocer un acuerdo implícito sobre lo que significan esos valores. También es algo que puede suceder con las horas y minutos, porque podríamos decidir no usar el estándar 00:00-23:59, y usar el de 12:00AM-12:00PM, pero partamos desde el primer estándar como consenso para facilitar el ejemplo.

Para plasmar cómo restringir las interfaces pueden facilitar el consumo de las mismas, refactoricemos la interfaz, creando tipos que representan las posibles opciones válidas que, esto permite, eliminar las elecciones erróneas de quienes usen nuestra interfaz.

Nuestros tipos representan las 24 horas de un día, las cuatro elecciones de minutos que mencionamos antes, y las posibles prioridades que puede elegir el usuario y le damos además semántica, dejando claro cual es la prioridad más alta y la más baja.

Esto nos permite hacer los siguientes cambios en nuestro código:

Gracias a estos tipos, eliminamos la programación defensiva^[1] antes mencionada, y además dejamos claro a nuestros consumidores cuáles son las opciones disponibles que tiene para usar nuestra API para crear recordatorios y dejar de transportar números con convenciones implícitas que debemos conocer antes de usarlos por todas las capas de nuestro dominio.

Otra serie de ventajas de elegir este tipo de diseño:

El feedback es el más inmediato posible. El compilador es una herramienta que muchas veces se ve como una molestia en vez de un recurso más con el que poder diseñar interfaces más robustas y explícitas. El diseño propuesto, ofrece feedback sobre la implementación en el momento más prematuro, cuando hacemos compilar el código, este te fuerza a usar única y exclusivamente las posibilidades correctas a la hora de elegir los parámetros al consumir interfaz. Además como este feedback es previo a la ejecución de los tests, no es necesario validar esta parte de tu diseño porque el consumidor no tiene capacidad de saltarse esta barrera de tu AP. Por lo tanto los tests validan únicamente la lógica de negocio, y te ahorras el tener que testear los límites de tus interfaces, pues ya has forzado esa decisión en los tipos que recibe.
Fuerza la transformación de los tipos básicos que vienen de los mecanismos de entrega a un mayor nivel de abstracción. En un diseño de tipo arquitectura hexagonal, diseñar tipos de esta manera fuerza a concentrar la lógica de transformación a los mismos en las capas más externas de la arquitectura, como en los Controllers o Mappers que residen fuera de la capa de dominio. Evitamos así que se filtren estos tipos básicos a las capas más internas de nuestro diseño.
Los tipos/objetos funcionan como behaviour attractors. Las abstracciones que hemos creado para representar nuestro modelo de dominio actúan como elementos que atraen comportamiento asociado al propio tipo. Esto favorece la cohesión y reduce el acoplamiento de otros elementos de nuestro diseño que de otra manera tendrían que conocer el significado de esos tipos y a cómo operar con ellos. Eliminando el Connascence of Meaning (Feature Envy y/o Data Clump) suelen aparecer dos smells relacionados Feature Envy (la atracción de comportamiento a la que nos referimos) y Data Class, que eliminamos convirtiendo las estructuras de datos en objetos al darles responsabilidades. Por ejemplo, si le damos una vuelta más al refactor y creamos una clase para los recordatorios tal que así:

Se puede apreciar que hemos conseguido mover la comprobación del mensaje dentro de la clase Reminder, lo cual, si no cumple la regla de negocio que impide crear recordatorios sin mensaje, ni siquiera inicializa el objeto. Por lo que una vez más estamos forzando que nuestra API no pueda recibir tipos inválidos, en este caso, gracias a Kotlin, el compilador fuerza a que si el tipo que ha devuelto el método create (Reminder?) al poder ser nulo no se le pueda pasar directamente al setReminder que solo recibe Reminder no nulos por lo que hay que controlar esta nulabilidad para poder llamarlo, y forzamos a que el consumidor de nuestra API sea consciente de esta restricción de diseño que hemos creado a partir de la regla de negocio.

Este es un ejemplo muy claro de atracción de comportamiento, y además es una tendencia bastante fácil de seguir, puesto que si se diera el caso de que no queremos permitir que se creen recordatorios con palabras que pertenecen a un conjunto de palabras prohibidas, como por ejemplo insultos, es bastante probable que acabaran en el mismo punto y así cada vez que tengamos reglas de no permitir crear recordatorios en base a las necesidades de negocio.

Aclaro también que seguramente el nulo no sería mi diseño final, pero me parece un ejemplo good enough para ilustrar el concepto de restringir interfaces.

Gran parte de la solución de este diseño está asociada al uso de lenguajes con tipado estático en tiempo de compilación^[2], tiene una razón clara, creo que los tipos con estos lenguajes ayudan a modelar dominios ricos y la forma en la que obtenemos feedback de nuestro diseño creando restricciones con el compilador. Es probable que incluso carácteristicas como el tipo nullable de Kotlin no esté en la mayoría de lenguajes, pero me parece una forma de permitir entender una máxima que tengo a la hora de escribir código, que es expresar mi intención a la hora de diseñar interfaces y hacerlas robustas y limpias.

Aún así creo que se le puede sacar mucho partido a esta forma de diseñarinterfaces y que sirva sobre todo para tratar de evitar leaks de tipos básicos en nuestros diseños. Con ello reducimos el Connasence of Meaning, que es un verdadero dolor para mí cuando me enfrento a legacy, y más aún si ese legacy ya ni siquiera tiene a su creador en el equipo y tienes que descubrir para qué sirve y qué significa ese valor que se usó.

Ojalá que estas ideas puedan influenciar de manera positiva tus diseños en el futuro y que te permitan crear mejores interfaces. Me gustaría hacer otro post relacionado con esta misma idea, pero, no solamente desde el punto de vista de los consumidores, sino desde un punto de vista interno y de modelar el negocio con tipos. Esta es una guerra mental que también libro a la hora de desarrollar tipos explícitos y restrictivos para modelar un problema.

¡Muchas gracias y espero tu feedback!

Footnotes:

[1] La programación defensiva no deja de existir en nuestro código aunque restrinjamos nuestras interfaces. Lo que provocamos es empujarlas a capas superiores de nuestro diseño, logrando que estas comprobaciones y se hagan antes de que nuestro diseño se deje permear por tipos más básicos. En situaciones en las que nuestro diseño envuelva un tipo primitivo para operar internarmente, lo que puede suceder es que empujemos a los constructores de la clase estas comprobaciones. Eliminando duplicidad de nuestro diseño y impidiendo que se puedan crear objetos que no cumplan las reglas de negocio que ese tipo trata de representar.

[2] Aclaro que no es una ventaja únicamente de los lenguajes de tipado estático, en lenguajes dinámicos es también una restricción muy interesante que con el uso de tests de contrato de interfaces pueden facilitar mucho su uso y que sean una referencia documental a la hora de poder consumirlos.

Huyendo de las ramas

2022-01-25T00:00:00+00:00

El pasado mes de diciembre, mi compañero Alfredo y yo tuvimos el placer de compartir un par de horas con el equipo de Declarando para hablar sobre feature branching, continuous integration, continuous delivery y algunas técnicas como feature flags y cambio en paralelo.

Hace unos años dimos una charla parecida en la Conferencia Agile Spain, y me gustaría compartir por aquí algunas ideas sobre cómo hacemos integración continua y por qué nos gusta trabajar así.

Gitflow

Cuando empecé mi carrera en el mundo del desarrollo, en todos los proyectos que trabajé me tocó trabajar haciendo Gitflow o variantes similares. Siendo algo tan común en muchas empresas, pensaría que es algo sencillo pero, viendo el flujo de trabajo, la verdad que no lo parece.

From https://nvie.com/posts/a-successful-git-branching-model/

No voy a explicar en profundidad el flujo de trabajo con Gitflow, pero sí que hay un detalle que salió cuando tuvimos la charla con el equipo de Declarando y que me resultó muy llamativo.

La rama master (o main como solemos llamarla hoy en día) es la que se despliega a producción, y vemos que hay 2 formas de llegar a master: mediante una rama de hotfix o mediante una rama de release. Viendo sólo la figura de arriba, se ve que introducir código a master desde un hotfix es más “rápido” (hay menos ceremonias de commits y ramas) que entrar a través de release. La gente de Declarando nos decía “es que a veces la gente de producto viene con una historia de usuario y nos la quiere colar como un hotfix”. Eso también me ha pasado a mi en algún trabajo pero veámoslo desde la perspectiva de alguien de producto que no tiene porqué entender Gitflow. Yo quiero una feature, hay una forma “lenta” de tenerla en producción y una forma “rápida”. ¿Cuál quiero yo? Pues la rápida, obviamente.

Aparte de la anécdota, ¿tiene sentido tener dos formas de llegar a producción?^[1] ¿Por qué aceptamos tener una forma lenta de desplegar si podemos hacerlo de forma más rápida? ¿O es que elegimos hacer un despliegue de forma menos segura para arreglar un problema en producción?

Incertidumbre e inventario

Has estado una semana trabajando tranquilamente en tu rama y anuncias en la daily que la feature está terminada, pero es mentira porque has dejado para el final la integración de tu rama con la rama principal del proyecto. En ocasiones tendrás suerte y será fácil, y otras veces te tocará resolver un conflicto que te llevará media mañana. Además, como resolver el conflicto te ha parecido molesto la próxima vez intentarás tocar el mínimo código posible para evitar conflictos. A partir de ese momento habrás perdido el refactor oportunista^[2], aquel que hacemos a modo de scout dejando el código por el que pasamos mejor de lo que estaba, ya que ahora no quieres modificar el código por miedo a tener que resolver conflictos.

En términos de Lean, podemos entender el trabajar en una rama como una optimización local (trabajar en una rama sin que nos molesten es más cómodo que traer cambios de todo el equipo a menudo), pero desde el punto de vista global no es la forma más óptima porque retrasamos el aprendizaje de integrar. Además, el código que está en una rama es inventario, stock que hemos producido y dejado sin entregar, retrasando el valor.

Feedback y pull requests

¿Y cómo se suelen llevar los cambios de una rama a main? Normalmente a través de pull requests que bloquean el merge de la rama hasta que X personas lo aprueban. Los pull requests pueden ser una herramienta muy chula para compartir conocimiento y debatir cómo se desarrolla una solución en equipos que cumplen alguna de estas condiciones:

Están distribuidos en distintas zonas horarias o geográficas. El aumento del trabajo en remoto debido a la pandemia nos ha permitido mejorar en cómo hacemos pairing sin estar en una misma oficina, pero compartir conocimiento de forma síncrona con gente que está a muchas horas de diferencia puede ser un problema.
Tiene integrantes con dedicación asimétrica. Cuando hablamos de equipos asimétricos nos referimos a aquellos en los que existen distintos roles con grandes diferencias de dedicación al proyecto. Por ejemplo, en proyectos open source tenemos gente que actúa como maintainers (gente que tiene una visión global del proyecto) y contributos (personas que hacen alguna contribución ocasional para arreglar bugs o añadir pequeñas features).

En una empresa en la que el equipo no está distribuido (o está distribuido pero en zonas horarias cercanas) los pull requests son una manera de revisar código mucho más compleja que hacer pairing o mostrar los cambios al resto del equipo en una mini reunión. ¿Por qué? Imaginemos un equipo de 4 personas, donde cada persona empieza una tarea en una rama. Cuando la primera persona acaba su tarea, hace una pull request y pide al resto de compañeras que revise para poder hacer merge. El resto del equipo está ocupado, así que empezamos una tarea nueva mientras esperamos su feedback. Una de las personas se libera y empieza a revisar el código, pero resulta que el pull request tiene 100 cambios, así que lo mira en diagonal y le da el ok. Al día siguiente, otro miembro del equipo revisa la pull request con más detenimiento y anota 10 comentarios. El desarrollador que hizo la tarea inicialmente recibe una notificación con los comentarios, deja de trabajar en la tarea con la que estaba y lee los comentarios intentando recordar por qué hizo las cosas de esa manera. Así hasta que todo el equipo lo ve ok y se hace merge del pull request. Y mientras tanto la gente de producto esperando que nos pongamos de acuerdo en cómo llamar a una variable en una tarea supuestamente “terminada”.

¿Qué problemas vemos aquí?

Cambios de contexto continuos. Cada vez que hay que revisar una pull request, alguien tiene que parar lo que está haciendo (o hacerlo en un rato muerto, como después de comer) y revisarlo. Cuando llega el feedback, quien hizo el pull request tiene que parar lo que está haciendo y hacer memoria para poder discutir el tema.
Bloqueo en la entrega de valor. No estoy cuestionando que nos preocupemos por los nombres de las cosas y por el diseño de nuestro software, lo que propongo es que si ya hemos solucionado un problema y está funcionando, entreguemos el valor. Luego habrá tiempo de discutir sobre él, refactorizar o incluso borrar el código si hemos visto que no aporta el valor que esperábamos.

Mejora contínua, conoce tu contexto

Con este post no quiero que te vayas con la idea de “tengo que hacer trunk based development”. Es importante siempre conocer la teoría, practicar las técnicas en cosas que tengan poco riesgo (de esto hablaremos en otros posts) y, si encaja en tu contexto, dar el salto. Al final lo importante es cuestionar siempre lo que hacemos. No decir “es que en la empresa siempre hemos hecho gitflow”, sino pararte a pensar, detectar posibles problemas y encontrar cosas que podrías ir probando para mejorar.

Por último, te dejo algunas acciones que puedes intentar aplicar para ir reduciendo algunos de los problemas de Gitflow.

Elimina develop. ¿Para qué necesitas dos ramas de larga duración? Ten sólo main e intenta que cada vez que se haga merge de una rama haya un despliegue.
Acelera el feedback al desarrollar código. Hacer pair programming o una reunión corta es más rápido para obtener feedback que esperar a terminar la tarea para hacer una pull request.
Intenta que las revisiones de código no bloqueen la entrega de valor. Existen formas de hacer reviews de código no bloqueantes como los concerns. Echa un vistazo a la charla de Xavi Gost sobre concerns [3].
Reduce el tamaño de tus pull requests. No tienes porqué hacer una PR con toda la tarea terminada. Si has hecho un refactor previo a la tarea que mejora lo que había antes, haz un PR y mergealo ya. ¿Has avanzado una parte de la tarea que no modifica comportamiento observable para el usuario? ¡Mergéalo! Acabarás teniendo pull requests tan pequeños que dar el salto a commitear en main te parecerá natural.

Notas

[1] Al respecto de tener dos formas de desplegar en producción, Charity Majors publica un tweet diciendo que solo debería haber una forma de desplegar, y no tener una forma corta “insegura” para usar justo en los momentos de estrés.

[2] En la charla Workflows of refactoring Martin Fowler explica el concepto de refactoring oportunista.

[3] Otro post relacionado con el concepto de Consensus-Driven Development de Nicholas C. Zakas

Entrevistas para la Agile Alliance

2021-02-10T00:00:00+00:00

Hace unos meses, nuestros compañeros de Codesai, Toño de la Torre y Miguel Viera participaron en una serie de entrevistas para la Agile Alliance de mano de Juan Banda, quién en una iniciativa por llevar más representación de la opinión técnica al mundo Agile, contactó con ellos para hablar de algún tema que les pareciera interesante compartir. En este caso, sobre Caring y DDD.

Queríamos compartir estas charlas con la comunidad y añadirlas en una entrada en nuestro blog. Esperamos las disfrutes y cualquier feedback sobre las mismas será bien recibido.

Primero os dejamos la charla de Toño, que viene a traer un poco más de contexto al gran post que nuestro compañero Manuel Rivero ya publicó sobre “The Value of Caring” en nuestro blog hace varios meses. En ella Toño cuenta su experencia personal aplicando esta filosofía en equipos con los que ha trabajado. ¡Muchas gracias Toño!

Por otro lado, Miguel tuvo también su entrevista sobre DDD, hablando un poco sobre en qué se fundamenta esta metodología de desarrollo, hablando de prácticas y principios en los que se basa, comentando cómo la industria ha entendido DDD y que puede hacer, según su opinión para continuar llevando estos conocimientos al mundo del software. Además ofrece su visión de por qué DDD no ha triunfado tanto como otras tantas alternativas que existen en el mundo del software. ¡Muchas gracias Miguel!

Y nada más, agradecer a Juan Banda por contar con nosotros para esta serie de entrevistas y a la Agile Alliance por permitir este tipo de iniciativas por seguir compartiendo conocimiento y apostando por visibilizar la importancia del trabajo técnico y no solo en el proceso a la hora de desarrollar software.

Recapitulando nuestra experiencia con Connectsai

2021-02-04T00:00:00+00:00

Este post viene a solucionar una de las espinas clavadas que quedaban en nuestro backlog de publicaciones pendientes. Y esto es contaros nuestra experiencia con el Open Space remoto Connectsai.

Hace unos meses (el sábado 17 de octubre) montamos conjuntamente con Lifull Connect el que sería nuestro primer evento de autor: Connectsai. La experiencia de montar el evento, como en todas las organizaciones, tiene sus claroscuros: incertidumbre sobre el nivel de asistencia, la retención de la gente a medida que pasa el día, el rendimiento de las herramientas para remote, cómo comunicar un evento de esta magnitud, si se puede sobrevivir sin patrocinadores y un largo etc.

Pero con dudas o no, llegó el gran día y tuvimos la fortuna de que el evento contó con bastante asistencia, menos de la que hubiéramos querido, pero bastante más que nuestra predicción a la baja. La media de personas durante el evento era de 60 con un pico de asistencia de más de 90 personas. Pero sí que hay aprendizajes que creemos que podemos aportar en este pequeño post:

No sobrecargar de comunicación a la gente. Que sea efectiva y que sea fácil buscarla para cuando haya un momento en el que la gente se pierda.
Anima a la gente a que se conecte en espacios fuera de las charlas. El valor que más hemos percibido que no hemos podido proveer a la gente es la capacidad de que conecten entre si en espacios menos oficiales a la organización del evento.
Fomentar los valores de la organización, respeto, apertura, divergencia y sobretodo crear un espacio en el que la gente se sienta segura compartiendo.
Romper el hielo. En los open space remotos hemos notado que es más difícil empezar la retahíla de propuestas. Habla con gente que tenga temas que puedan dar en el open space para que empiecen las propuestas ellas, esto anima a que el resto se sume poco a poco.
Si vas a grabar la charla, que quede claro que es opcional. La gente puede echarse atrás por el miedo a que se grabe.

Kudos a Aitor Alzola @aitortxu por su fantásticas manos para la facilitación gráfica

Con todos estos aprendizajes, esperamos que en la siguiente edición (que no sabemos si se llamará así o no) podamos mejorar nuestro desempeño como organizadores. Aún así el feedback recibido ha sido muy positivo, la gente ha disfrutado mucho del evento, de volver a encontrarse con gente, y sobretodo del nivel de las charlas preparadas que teníamos con las speakers que se mostraron dispuestas a colaborar en ese día con nosotros. Desde aquí queremos dar las gracias por brindarnos su tiempo y esfuerzo para que esto saliera bien.

Por último queríamos compartir la lista de las charlas grabadas que se encuentra en nuestro canal de Youtube en la lista de Connectsai.

También aprovechamos para compartir la charla en este post la charla de Mitos y Leyendas de DDD que dieron nuestros compañeros Miguel Viera @mangelviera y Alfredo Casado @AlfredoCasado:

Agradecimientos

No queríamos marcharnos sin agradecer a Lifull Connect por su tiempo y esfuerzo en lograr que esto haya sido posible, estamos deseando volver a colaborar para una nueva edición.

Y por último a todas las speakers y facilitadoras que han pasado por esta edición y que queremos hacerles un hueco en este post:

Muchas gracias a todas y nos vemos en el siguiente Connectsai.

Notes on OCP from Agile Principles, Practices and Patterns book

2021-01-29T06:00:00+00:00

Some time ago I wrote a post sharing my notes on SRP from Agile Principles, Practices and Patterns book because I was making an effort to get closer to the sources of some object-oriented concepts. I didn’t continue sharing my notes on SOLID because I thought they might not be interesting for our readers. However, seeing the success of the Single responsibility ¿Principle? episode of The Big Branch Theory Podcast for which I used my notes on SRP, I’ve decided to share the rest of my notes on SOLID on Codesai’s blog.

Ok, so these are the raw notes I took while reading the chapter devoted to Open-closed Principle in Robert C. Martin’s Agile Principles, Practices and Patterns in C# book (I added some personal annotations between brackets):

OCP -> “Software entities (classes, modules, functions, etc) should be open for extension but closed for modification”
“When a single change to a program results in a cascade of changes to dependent modules, the design smells of fragility” <- [No local consequences. See Beck’s Local Consequences principle from Implementation Patterns] “OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works”
“It’s possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors”
“[A module that uses such abstractions] can be closed for modification, since it depends on an abstraction that is fixed. Yet the behavior of the module can be extended by creating new derivatives of the abstraction”
“Abstract classes are more closely associated to their clients than to the classes that implement them” <- [related with Separated Interface from Fowler’s P of EAA]
”[Strategy and Template Method patterns] are the most common ways to satisfy OCP. They represent a clear separation of generic functionality from the detailed implementation of that functionality”
Anticipation
- “[When a] program conforms to OCP. It is changed by adding code rather than by changing existing code”
- “In general no matter how “closed” a module is, there will always be some kind of change against which it is not closed”
- “Since closure <- [“closure” here means protection against a given axis of variation or change, see Craig Larman’s Protected Variation: The Importance of Being Closed] can’t be complete, it must be strategic. That is the designer must choose the kinds of changes against which to close the design, must guess at the kinds of changes that are most likely, and then construct abstractions to protect against those changes.”
- “This is not easy. It amounts to making educated guesses about the likely kinds of changes that the application will suffer over time.” “Also conforming to OCP is expensive. It takes development time and money to create the appropriate abstractions. These abstractions also increase the complexity of the software design”
- “We want to limit the application of OCP to changes that are likely”
- “How do we know which changes are likely? We do the appropriate research, we ask the appropriate questions, and we use our experience and common sense.” <- [also requires knowing about the domain. A bit easier to predict in technological boundaries. Listen to the conversation in Single Responsibility ¿Principle?] podcast] “And after all that, we wait until the changes happen!” <- [see Yagni] “We don’t want to load the design with lots of unnecessary abstractions. Rather we want to wait until we need the abstraction and then put them in”
“Fool me once”
- “… we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind.” <- [One heuristic: we get to OCP through refactoring to avoid Speculative Generality. Most useful heuristic in unknown territory.]
- “If we decide to take the first bullet, it is to our advantage to get the bullets flying early and frequently. We want to know what changes are likely before we are very far down the development path. The longer we wait to find out what kind of changes are likely, the more difficult it will be to create the appropriate abstractions.”
- “Therefore, we need to stimulate changes”
  - “We write tests first” -> “testing is one kind of usage of the system. By writing tests first, we force the system to be testable. Therefore, changes in testability will not surprise us later. We will have built the abstractions that make the system testable. We are likely to find that many of these abstractions will protect us from other kinds of changes later.” <- [incrementally (tests “right after”) might also work]
  - “We use short development cycles”
  - “We develop features before infrastructure and frequently show those feature to stake-holders”
  - “We develop the most important features first”
  - “We release the software early and often”
“Closure is based on abstraction”
“Using a data-driven approach to achieve closure” <- [OCP is not only an OO principle, see Craig Larman’s Protected Variation: The Importance of Being Closed for more]
- “If we must close the derivatives […] from knowledge of one another, we can use a table-driven approach”
- “The only item that is not closed against [the rule that involves] the various derivatives is the table itself. An that table can be placed in its own module, separated from all the other modules, so that changes to it do not affect any of the other modules”
“In many ways the OCP is at the heart of OOD.”
“Yet conformance to [OCP] is not achieved by using an OOP language. Nor is it a good idea to apply rampant abstraction to every part of the application. Rather it requires a dedication on the part of the developers to apply abstraction only to those parts of the program that exhibit frequent change. <- [applying Beck’s Rate of Change principle from Implementation Patterns]”
“Resisting premature abstraction is as important as abstraction itself <- [related to Sandi Metz’s “duplication is far cheaper than the wrong abstraction”]”

For me getting closer to the sources of SOLID principles was a great experience that helped me to remove illusions of knowledge I had developed due to the telephone game effect caused by initially learning about SOLID through blog posts and talks. I hope these notes on OCP might be useful to you as well, and motivate you to read a bit closer to some of the sources.

Solving the Beverages Prices Refactoring kata (2): limiting the options on the menu

2021-01-20T05:00:00+00:00

Introduction.

This is the second and last post in a series of posts showing a possible solution to the Beverages Prices Refactoring kata that I recently developed with some people from Women Tech Makers Barcelona with whom I’m working through Codesai’s Practice Program twice a month.

In the previous post we introduced a design based on composition that fixed the Combinatorial Explosion code smell and produced a flexible solution applying the decorator design pattern. There was a potential problem in that solution because the client code, the code that needed to find out the price of the beverages, knew^[1] too much about how to create and compose beverages and supplements.

Have a look, for instance, at the following line new WithCream(new WithMilk(new Coffee())). It knows about three classes and how they are being composed. In the case of this kata, that might not be a big problem, since the client code is only comprised of a few tests, but, in a larger code base, this problem might spread across numerous classes generating a code smell known as Creation Sprawl^[2] In this post, we’ll try to reduce client knowledge of concrete component and decorator classes and their composition by encapsulating all the creational knowledge behind a nice, readable interface that we’ll keep all the complexity of combining the supplements (decorators) and beverages (components) hidden from the client code.

Another more subtle problem with this design based on composition has to do with something that we have lost: the fact that not all combinations of beverages and supplements were allowed on the menu. That knowledge was implicitly encoded in the initial inheritance hierarchy, and disappeared with it. In the current design we can dynamically create any combination of beverages and supplements, including those that were not included in the original menu, like, for instance a tea with cinnamon, milk and cream (doing new WithCinnamon(new WithCream(new WithMilk(new Tea())))) which you might find delicious :).We’ll also explore possible ways to recover that limitation of options.

We’ll start by examining some creational patterns that are usually applied along with the decorator design pattern.

Would the Factory pattern help?

In order to encapsulate the creational code and hide its details from client code, we might use the factory pattern described by Joshua Kerievsky in his Refactoring to Patterns. A factory is a class that implements one or more Creation Methods. A Creation Method is a static or non-static method the creates and returns an object instance^[3].

We might apply the Encapsulate Classes with Factory refactoring^[4] to introduce a factory class with an interface which provided a creation method for each entry on the menu, that is, it would have a method for making coffee, another one for making tea, another one for making coffee with milk, and so on, and so forth.

Before starting to refactor, let’s think a bit about the consequences of introducing this pattern to assess if it will leave us in a better design spot or not. At first sight, introducing the factory pattern seems to simplify client code and reduce the overall coupling because it encapsulates all the creational logic hiding the complexity related to composing decorators and components behind its interface which solves the first problem we discussed in the introduction. The second one, limiting the combinations of beverages and supplements to only the ones available on the menu, is solved just by limiting the methods in the interface of the factory.

However, it would also create a maintenance problem somehow similar to the initial combinatorial explosion code smell we were trying to avoid when we decided to introduce the decorator design pattern. As we said, the interface of the factory would have a method for each combination of beverages and supplements available on the menu. This means that to add a new supplement we’d have to multiply the number of Creation methods in the interface of the factory by two. So, we might say that, introducing the factory pattern, we’d get an interface suffering from a combinatorial explosion of methods^[5].

Knowing that, we might conclude that a solution using the factory pattern would be interesting only when having a small number of options or if we didn’t expect the number of supplements to grow. As we said in the previous post, we think it likely that we’ll be required to add new supplements so we prefer a design that is easy to evolve along the axis of change of adding new supplements^[6]. This means the factory pattern is not the way to go for us this time because it’s not flexible enough for our current needs. We’ll have to explore more flexible alternatives^[7].

Let’s try using the Builder design pattern.

The builder design pattern is often used for constructing complex and/or composite objects^[8]. Using it we might create a nice readable interface to compose the beverages and supplements bit by bit. Like the factory pattern, a builder would encapsulate the complexity of combining decorators from the client code. Unlike the factory pattern, a builder allows to construct the composite following a varying process. It’s this last characteristic that will avoid the combinatorial explosion of methods that made us discard the factory pattern.

In this case you can introduce the builder by applying the Encapsulate Composite with Builder. Let’s have a look at how we implemented it:

Notice how we keep the state of the partially composed object and apply the decorations incrementally until it’s returned by the make method. Notice also how the beverage is the initial state in the process of creating the composite object.

These are the tests after introducing the builder design pattern:

Notice the fluent interface that we decided for the builder. Although a fluent interface is not a requirement to write a builder, we think it reads nice.

As we said before, using a builder does not suffer from the combinatorial explosion of methods that the factory pattern did. The builder design pattern is more flexible than the factory pattern which makes it more suitable for composing components and decorators.

Still, our success is only partial because the builder can create any combination of beverages and supplements. A drawback of using a builder instead of a factory is usually that clients require to have more domain knowledge. In this case, the current solution forces the client code to hold a bit of domain knowledge: it knows which combinations of beverages and supplements are available on the menu.

We’ll fix this last problem in the next section.

A hybrid solution combining factory and builder patterns.

Let’s try to limit the possible combinations of beverages and supplements to the options on the menu by combining the creation methods of the factory pattern and the builder design pattern.

To do so, we added to BeverageMachine the creation methods, coffee, tea and hotChocolate, that create different builders for each type of beverage: CoffeeBuilder, TeaBuilderand HotChocolateBuilder, respectively. Each of the builders has only the public methods to select the supplements which are possible on the menu for a given type of beverage.

Notice that we chose to write the builders as inner classes of the BeverageMachine class. They could have been independent classes, but we prefer inner classes because the builders are only used by BeverageMachine and this way they don’t appear anywhere else.

This is the first design that solves the problem of limiting the possible combinations of beverages and supplements to only the options on the menu. It still encapsulates the creational logic and still reads well. In fact the tests haven’t changed at all because BeverageMachine’s public interface is exactly the same.

However, the new builders present duplication: the code related to supplements that can be used with different beverages and the code in the make method.

What is different for the clients that call the coffee method and the clients that call the tea or hotChocolate methods are the public methods they can use on each builder, that is, their interfaces. When we had only one builder, we had an interface with methods that were not interesting for some of its clients.

By having three builders we segregated the interfaces so that no client was forced to depend on methods it does not use^[9]. However we didn’t need to introduce classes to segregate the interfaces, we could have just used, well, interfaces. As we’ll see in the next section using interfaces would have avoided the duplication in the implementation of the builders.

Segregating interfaces better by using interfaces.

As we said, instead of directly using three different builder classes, it’s better to use three interfaces, one for each kind of builder. That would also comply with the Interface Segregation Principle, but, using the interfaces helps us avoid having duplicated code in the implementation of the builders, because we can write only one builder class, Beverage Machine, that implements the three interfaces.

Notice how, in the creation methods, we feed the base beverage into BeverageMachine through its constructor, and how each of those creation methods return the appropriate interface. Notice also that BeverageMachine’s public interface remains the same, so this refactor won’t change the tests at all. You can check the resulting builder interfaces in Gist: TeaBuilder, HotChocolateBuilder and CoffeeBuilder.

Conclusions.

In this last post of the series dedicated to the Beverages Prices Refactoring kata, we’ve explored different ways to avoid creation sprawl, reduce coupling with client code and reduce implicit creational domain knowledge in client code. In doing so, we have learned about and applied several creational patterns (factory pattern, and builder design pattern), and some related refactorings. We have also used some design principles (such as coupling, open-closed principle or interface segregation principle), and code smells (such as combinatorial explosion or creation sprawl) to judge different solutions and guide our refactorings.

Acknowledgements.

I’d like to thank the WTM study group, and especially Inma Navas for solving this kata with me. Thanks also to my Codesai colleagues and to Inma Navas for reading the initial drafts and giving me feedback and to Amelia Hallsworth for the picture.

Notes.

[1] Knowledge here means coupling or connascence.

[2] Creation Sprawl is a code smell that happens when the knowledge for creating an object is spread out across numerous classes, so that creational responsibilities are placed in classes that should now be playing any role in object creation. This code smell was described by Joshua Kerievsky in his Refactoring to Patterns book.

[3] Don’t confuse the Factory Pattern with design patterns with similar names like Factory method pattern or Abstract factory pattern. These two design patterns are creational patterns described in the Design Patterns: Elements of Reusable Object-Oriented Software book.

A Factory Method is “a non-static method that returns a base class or an interface type and that is implemented in a hierarchy to enable polymorphic creation” whereas an Abstract Factory is “an interface for creating fqamiñlies of related or dependent objects without specifying their concrete classes”.

In the Factory Pattern a Factory is “any class that implements one or more Creation Methods” which are “static or non-static methods that create and return an object instance”. This definition is more general. Every Abstract Factory is a Factory (but not the other way around), and every Factory Method is a Creation Method (but not necessarily the reverse). Creation Method also includes what Martin Fowler called “factory method” in Refactoring (which is not the Factory Method design pattern) and Joshua Bloch called “static factory” (probably a less confusing name than Fowler’s one) in Effective Java.

[4] Presented in the fourth chapter of Refactoring to Patterns that is dedicated to Creational Patterns. [5] If you remember the previous post, before introducing the decorator design pattern, we suffered from a combinatorial explosion of classes (adding a new supplement meant multiplying the number of classes by two). Now, the factory interface (its public methods) would suffer a combinatorial explosion of methods.

[6] In other words: that it’s [protected against that type of variation (https://www.martinfowler.com/ieeeSoftware/protectedVariation.pdf).

[7] This is common when working with creational patterns. All of them encapsulate knowledge about which concrete classes are used and hide how instances of these classes are created and put together, but some are more flexible than others. It’s usual to start using a Factory pattern and evolve toward the other creational patterns as we realize more flexibility is needed.

[8] We have devoted several posts to builders: Remove data structures noise from your tests with builders, Refactoring tests using builder functions in Clojure/ClojureScript, In a small piece of code, The curious case of the negative builder.

[9] Following the Interface Segregation Principle that states that “no client should be forced to depend on methods it does not use”.

References.

Books

Articles

Testeando una integración con SNS

2020-12-07T11:30:00+00:00

En un post anterior hablamos sobre cómo desarrollamos y testeamos una integración con S3 en uno de nuestros clientes. En esta segunda parte queríamos contar cómo ha sido nuestra experiencia con otro servicio de AWS: SNS.

¿Para qué usamos SNS?

Amazon SNS (Simple Notification Service) es un servicio de mensajería de Amazon que nos permite múltiples opciones de integración. Podemos configurar un topic de SNS para que cada vez que reciba un mensaje ejecute una lambda, envie un mail, reenvie ese mensaje a una o varias colas de SQS, etc.

Flujo de comunicación con SNS.

En nuestro caso concreto, queríamos publicar una serie de eventos en un topic de SNS, y que luego éste enviase esos mensajes a una cola de SQS que consumía otro equipo.

Testeando contra SNS

Para conseguir que los tests contra SNS fueran lo más sencillos posible, redujimos al mínimo la lógica del componente que se comunica con SNS^[1]. En nuestro caso, nos bastó con tener una interfaz con un único método encargada de enviar un mensaje en forma de diccionario.

De esta forma, la lógica de cuándo se tienen que enviar los mensajes y el formato de éstos quedaba segregada en otros componentes que podíamos testear de manera unitaria sin depender de servicios externos.

Para comprobar el envío del mensaje en sí, pensamos en escribir un test de integración que publicase un mensaje con nuestro servicio SnsNotifier y comprobase que recibimos ese mensaje en el test. Siguiendo el mismo enfoque que con S3, buscamos una imagen de Docker que nos permitiera escribir estos tests de integración. En este caso elegimos usar la imagen s12v/sns, que nos proporciona una versión falsa de SNS contra la que podemos trabajar. No es una versión oficial mantenida por Amazon, pero nos sirvió para lo que queríamos.

Aún disponiendo de esta imagen nos dimos cuenta de que este test de integración no iba a ser tan sencillo como el de S3. Como ya dijimos, SNS es un servicio de mensajería, y su API sólo deja enviar mensajes y suscribir otros componentes a un topic. No tenemos una forma de pedir directamente los mensajes relacionados con un topic. Esto complicaba un poco el testing porque requería montar una pieza extra que fuese capaz de recibir los mensajes que íbamos a publicar.

La documentación de s12v/sns proporciona un listado de integraciones soportadas con las que se podrían hacer esas comprobaciones. La opción de integrar a través de ficheros nos pareció sencilla. Supusimos que sería simplemente especificar la ruta a un fichero y luego leer el contenido del fichero para recuperar el mensaje. Sin embargo, no había documentación sobre cómo hacerlo funcionar y no lo conseguimos. Optamos por hacer el test integrando a través de SQS, que, además, era justo lo que se usaría en producción.

Amazon SQS (Simple Queue Service) es el servicio de colas de AWS. Para los tests usamos la imagen roribio16/alpine-sqs, que nos da una versión falsa de SQS sobre la que podemos enviar y recibir mensajes. Tampoco es una versión oficial mantenida por AWS, pero de momento nos ha funcionado y nos da también una interfaz gráfica para consultar los mensajes pendientes de procesar.

El procedimiento del test de integración sería el siguiente:

Setup:

Crear un topic de SNS
Crear una cola de SQS.
Suscribimos la cola al topic.

Test:

Publicamos un mensaje a través de nuestra clase SnsNotifier.
Verificamos que el mensaje ha llegado a la cola de SQS.

Siguiendo esta idea así quedó el código del test que comprobaba el envío de un evento a SNS.

Dado que la publicación de mensajes en SNS es asíncrona, en este test usamos un helper para hacer una aserción usando la técnica de polling and probing, como explicaba Manuel Rivero en este post.

¿Tests en producción?

En el post sobre la integración con S3 hablamos de la importancia de testear en producción para asegurarnos que todo funciona como es debido. En este caso tenemos alguna idea sobre lo que nos gustaría hacer, pero no hemos llegado a implementar nada aún porque, de momento, no hemos querido invertir más en esta feature.

Lo que nos interesaría probar en producción es que si la aplicación lanza un evento, éste llega a los suscriptores del topic de SNS. Para conseguirlo podríamos seguir un enfoque parecido al que utilizamos para testear la integración con S3: tener un proceso que publique periódicamente un evento y revisar que se puede consumir en el otro extremo. Hemos pensado que desplegar un cronjob que periódicamente llame a un endpoint de la API que publique un evento en SNS, y suscribir una cola nueva a este topic y leer de la cola podría servir para verificar que el mensaje llega.

Lo ideal sería que ese evento se publique en el mismo topic que se usa para los eventos reales, pero tendríamos que evitar que ese evento provoque efectos no deseados en el entorno de producción. En este punto se nos ocurren 2 maneras alternativas para conseguirlo:

Usar un evento de la aplicación que sea idempotente y sobre un dato que controlemos. Por ejemplo, teniendo un anuncio en producción que está despublicado, podemos llamar a un endpoint que haga que un anuncio deje de estar publicado, que lanzará el evento correspondiente. Validando el evento que llega, podríamos testear el servicio sin producir ningún efecto visible en producción. Sin embargo, puede que en el futuro no quisiéramos que se propaguen eventos cuando no hay cambio de estado o que haya algún cambio en cómo se gestiona el evento y rompamos nuestro test por el motivo que no esperamos.
Por otro lado, podemos acordar con el equipo que está consumiendo eventos un evento sintético que ellos puedan ignorar, pero que nosotros podamos verificar por nuestro lado. Necesitaríamos un poco más de coordinación entre equipos y algo más de código custom para las pruebas, pero nos aseguraríamos que el test en producción solo se rompería por los motivos adecuados.

Como ya hemos dicho, aún no hemos testeado esta integración en producción ni tomado una decisión firme sobre cómo hacerlo. Eso será material para otra publicación en la que detallaremos lo que hayamos hecho.

Agradecimientos

Gracias a mis compañeros de Codesai por el feedback en las versiones iniciales de este post y al equipo de B2B de LifullConnect por ser parte del trabajo que se describe aquí.

Notas

[1] Esta técnica se denomina Humble Object del libro xUnit Test Patterns de Gerard Meszaros

Referencias

Solving the Beverages Prices Refactoring kata (1): composition over inheritance

2020-11-30T05:00:00+00:00

Introduction.

We are going to show a possible solution to the Beverages Prices Refactoring kata that we developed recently with some people from Women Tech Makers Barcelona with whom I’m doing Codesai’s Practice Program twice a month.

The Beverages Prices Refactoring kata shows an example of inheritance gone astray. The initial code computes the price of the different beverages that are sold in a coffee house. There are some supplements that can be added to those beverages. Each supplement increases the price a bit. Not all combinations of drinks and supplements are possible.

As part of the kata, we are asked to add an optional cinnamon supplement that costs 0.05€ to all our existing catalog of beverages. We are also advised to refactor the initial code a bit before introducing the new feature. Let’s see why.

The initial code.

To get an idea of the kind of problem we are facing, we’ll have a look at the code. There are 8 files: a Beverage interface and 7 classes, one for each type of beverage and one for each allowed combination of beverages and supplements.

Initial code.

A closer look reveals that the initial design uses inheritance and polymorphism to enable the differences in computing the price of each allowed combination of beverage and supplements. This is the inheritance hierarchy:

Class diagram showing the inheritance hierarchy in the initial code.

If that diagram is not enough to scare you, have a quick look at the unit tests of the code:

First, we make the change easy^[1].

Given the current design, if we decided to add the new feature straight away, we would end up with 14 classes (2 times the initial number of classes). If you think about it, this would happen for each new supplement we were required to add: we would be forced to double the number of classes. Adding n supplements more would mean multiplying the initial number of classes by 2ⁿ.

This exponential growth in the number of classes is a typical symptom of a code smell called Combinatorial Explosion^[2]. In this particular case the problem is caused by using inheritance to represent the pricing of beverages plus supplements.

In order to introduce the new cinnamon supplement, we thought sensible to do a bit of preparatory refactoring first in order to remove the Combinatorial Explosion code smell. The recommended refactoring for this code smell is Replace Inheritance with Delegation which leads to a code that uses composition instead of inheritance to avoid the combinatorial explosion. If all the variants^[3] (supplements) keep the same interface, we’d be creating an example of the decorator design pattern^[4].

Class diagram for the decorator design pattern^[5].

The decorator pattern provides an alternative to subclassing for extending behavior. It involves a set of decorator classes that wrap concrete components and keep the same interface that the concrete components. A decorator changes the behavior of a wrapped component by adding new functionality before and/or after delegating to the concrete component.

Applying the decorator pattern design to compute the pricing of beverages plus supplements, the beverages would correspond to the concrete components, tea, coffee and hot chocolate; whereas the supplements, milk and cream would correspond to the decorators.

Design using the decorator design pattern to compute the pricing of beverages plus supplements.

We can obtain the behavior for a given combination of supplements and beverage by composing supplements (decorators) with a beverage (base component).

For instance, if we had the following WithMilk decorator for the milk supplement pricing,

we would compose it with a Tea instance to create the behavior that computes the price of a tea with milk:

A nice thing about decorators is that, since they have the same interface as the component they wrap, they are transparent for the client code^[6] which never has to know that it’s dealing with a decorator. This allows us to pass them around in place of the wrapped object which makes it possible to compose behaviors using as many decorators as we like. The following example shows how to compose the behavior for computing the price of a coffee with milk and cream^[7].

After applying the Replace Inheritance with Delegation refactoring we get to a design that uses composition instead of inheritance to create all the combinations of supplements and beverages. This fixes the Combinatorial Explosion code smell.

Code after refactoring introducing the decorator design pattern.

You can have a look at the rest of the test after this refactoring in this gist.

Then, we make the easy change.

Once we had the new design based in composition instead of inheritance in place, adding the requested feature is as easy as creating a new decorator that represents the cinnamon supplement pricing:

Code after adding the new feature.

Remember that using the initial design adding this feature would have involved multiplying by two the number of classes.

What have we gained and lost with this refactoring?

After the refactoring we have a new design that uses the decorator design pattern. This is a flexible alternative design to subclassing for extending behavior that allows us to add behavior dynamically to the objects wrapped by the decorators.

Thanks to this runtime flexibility we managed to fix the Combinatorial Explosion code smell and that made it easier to add the new feature. Now, instead of multiplying the number of classes by two, adding a new supplement only involves adding one new decorator class that represents the new supplement pricing. This new design makes the client code open-closed to the axis of change of adding new supplements.

On the flip side, we have introduced some complexity^[8] related to creating the different compositions of decorators and components. At the moment this complexity is being managed by the client code (notice the chains of news in the tests snippets above).

There’s also something else that we have lost in the process. In the initial design only some combinations of beverages and supplements were allowed. This fact was encoded in the initial inheritance hierarchy. Now with our decorators we can dynamically add any possible combination of beverages and supplements.

All in all, we think that the refactoring leaves us in a better spot because we’ll be likely required to add new supplements, and there are usual improvements we can make to the design to isolate the client code from the kind of complexity we have introduced.

Conclusion.

We have shown an example of preparatory refactoring to make easier the addition of a new feature, and learned about the Combinatorial Explosion code smell and how to fix it using the decorator design pattern to get a new design in which we have protected the client code^[9] against variations involving new supplements.

In a future post we will show how to encapsulate the creation of the different compositions of decorators and components using builders and/or factories to hide that complexity from client code, and show how we can limit again the allowed combinations that are part of the menu.

Acknowledgements.

I’d like to thank the WTM study group, and especially Inma Navas for solving this kata with me.

Thanks to my Codesai colleagues and Inma Navas for reading the initial drafts and giving me feedback and and to Lisa Fotios for her picture.

Notes.

[1] This and the next header come from Kent Beck’s quote:

“For each desired change, make the change easy (warning: this may be hard), then make the easy change”

[2] You can find this code smell described in Bill Wake’s wonderful Refactoring Workbook.

[3] In this context variant means a variation in behavior. For instance, each derived class in a hierarchy is a variant of the base class.

[4] Have a look at the chapter devoted to the decorator design pattern in the great Head First Design Patterns. It’s the most didactic and fun explanation of the pattern I’ve ever found. This kata is heavily inspired in the example used in that chapter to explain the pattern.

[5] We could have also solved this problem composing functions instead of objects, but we wanted to practice with objects in this solution of the kata. That might be an interesting exercise for another practice session.

[6] In this context client code means code that uses objects implementing the interface that both the components and decorators implement, which in the kata would correspond to the Beverage interface.

[7] Also known as a “cortado leche y leche” in Gran Canaria :)

[8] Complexity is most often the price we pay for flexibility. That’s why we should always assess if the gains are worth the price.

[9] Protected variations is another way to refer to the open-closed principle. I particularly prefer that way to refer to this design principle because I think it is expressed in a way that relates less to object orientation. Have a look at Craig Larman’s great article about it: Protected Variation: The Importance of Being Closed

References.

Testeando una integración con S3

2020-10-28T16:30:00+00:00

En uno de nuestros clientes actuales estamos ayudando en el desarrollo de un nuevo sistema que utiliza servicios de Amazon Web Services. Nos gustaría contarles el enfoque de testing que hemos seguido al integrarnos con S3, combinando tests locales contra imágenes Docker con tests en producción que se ejecutan periódicamente. Algunos de los tests que hemos hecho o el enfoque que hemos seguido lo hemos basado en los artículos de Cindy Sridharan sobre testing de microservicios y testing en producción.

Nuestra primera feature con S3

Una de las primeras features que hemos tenido que desarrollar ha sido la subida de imágenes, como por ejemplo para el perfil de usuario. Decidimos utilizar S3 (Simple Storage Service) para almacenar las imágenes que suben los usuarios. Por lo tanto, necesitamos integrarnos con S3 y una base de datos, para almacenar la información de usuario con la ruta a la imagen.

Hacer los tests contra la base de datos suele ser bastante sencillo. Utilizamos una imagen de Docker oficial que simula la base de datos que usamos en producción, MariaDB. En este caso, haríamos tests contra el repositorio de usuarios que se conectaría con este contenedor. Usar esta imagen, aunque no sea “real”, nos da bastante confianza (por ser una imagen oficial) de que será muy similar al sistema real. Los tests serían del estilo “guardo esto en base de datos, le pido al repositorio que lo lea y compruebo que ha leído lo que guardé”.

En el caso de S3, nos gustaría poder hacer lo mismo. Subo una imagen a S3 a través de un servicio que implementamos nosotros y compruebo que la imagen está disponible. Sin embargo, en el caso de los servicios de AWS, no contábamos (al menos hasta donde sabíamos) con imágenes oficiales soportadas por AWS. Se nos ocurrieron dos opciones para testear la integración con S3:

Hacer los tests de integración contra un bucket real de S3.

Así nos aseguramos que usamos la API correctamente. Pero trae una serie de problemas, como que es un gasto extra en la factura de AWS y hay que tener en cuenta que se pueden pisar recursos compartidos si hay tests que ejecutan varias personas a la vez.
Usar contenedores no oficiales que simulan S3.

No hay recursos compartidos entre distintos desarrolladores y es gratis, pero corres el riesgo de que la imagen se desactualice o tengas configuraciones distintas en producción.

Nuestro primer test para conectar con S3

Para empezar optamos por usar una imagen Docker que simula S3, adobe/s3mock, en nuestros tests. Para ello, teníamos que configurar nuestro cliente de S3 para que apunte al endpoint de nuestro contenedor Docker e inyectarlo a nuestro servicio:

De esta forma el test de S3 queda muy sencillo. Lo único que hace es subir un fichero y comprobar que está disponible cuando intentamos descargarlo.

Luego hicimos otro test para comprobar que el borrado de imágenes funcionaba.

Suponiendo que la imagen de Docker se comporta igual que el S3 real, estos tests validan que usamos la API de S3 correctamente.

Sin embargo, algunos miembros del equipo no estaban del todo cómodos testeando únicamente en una imagen “falsa” de S3. Para mejorar el grado de confianza en los tests decidimos duplicar el test de subida de imágenes pero apuntado a un bucket de S3 real en AWS. De esta forma nuestra suite de test contiene tests para todas las posibles casuísticas contra la imagen de Docker de S3, y un único test contra el entorno real que nos sirve para comprobar que el sistema ha sido configurado correctamente.

Local rara vez se parece a staging o producción

Creíamos que estos tests nos daban la tranquilidad de de que todo iba a funcionar perfectamente. Sin embargo, cuando el equipo de sistemas nos pidió cambiar el bucket en el que guardábamos imágenes en el entorno de staging y producción, vimos que no era así.

Para asegurarnos de que no romperíamos nada al hacer ese cambio, decidimos hacer tests de configuración en producción porque este tipo de cambios de configuración suele ser más peligrosos que los cambios de código.

Estos “tests” se ejecutan con el código ya en producción, pero con una feature flag que nos permite ocultar los cambios a los usuarios. Por eso se denominan tests en la fase de deploy: el código está desplegado, pero aún no se ha “liberado” a los usuarios.

Diferentes tipos de test de acuerdo al post de testing en producción de Cindy Sridharan.

Utilizamos dos variables de entorno distintas para apuntar al bucket viejo y el nuevo. Metimos una feature flag que decidía qué variable usar y desplegamos. Activamos la feature flag en staging y, sorpresa, empezaron a fallar las subidas de imágenes.

Habíamos asumido que los tests contra la imagen de Docker era posible que dieran un falso positivo pero, ¿y el test que teníamos contra el bucket real?

Resulta que nos estábamos conectando, mediante credenciales de un usuario de IAM, a un bucket creado en el entorno de staging. En un punto, sistemas decidió cambiar esta forma de acceso porque no era una opción segura en producción, y pasamos a asignar permisos a través de un perfil a los pods de Kubernetes.

Con este cambio nuestros tests seguían funcionando, aunque el sistema en producción estaba roto. Los tests que se ejecutaban contra la imagen de S3 pasaban porque no apuntaban al sistema real, mientras que el test que apuntaba a un bucket real de S3 pasaba porque se conectaba de una forma distinta.

En este punto nos planteamos, ¿qué valor nos estaba aportando el test “real” si no se conectaba a S3 de la misma forma que se usaba en producción?

Concluimos que ninguno, así que tomamos la decisión de borrar el test que teníamos contra el entorno real de AWS y mantener solo los tests contra la imagen de Docker. De esta forma, sólo teníamos testeado si nuestra forma de interactuar con S3 era correcta, pero volvíamos a tener el inconveniente de quedar expuestos a posibles errores al cambiar la forma de establecer esa comunicación.

Cuantas más piezas tiene nuestro sistema más fácil es que alguna de ellas falle y necesitamos mecanismos que nos ayuden a detectar esos errores lo antes posible. Tener tests que ejecutamos en local o en una pipeline, o un entorno de staging para testear nos ayudan a reducir esos riesgos. Sin embargo, aunque pueden ser una muy buena imitación de la realidad, no dejan de ser sino una especie de placebo que nos da seguridad de que no se romperá en producción.

I’m more and more convinced that staging environments are like mocks - at best a pale imitation of the genuine article and the worst form of confirmation bias.

It’s still better than having nothing - but “works in staging” is only one step better than “works on my machine”.
— Cindy Sridharan (@copyconstruct) March 16, 2018

Testeando en producción

Ahora mismo, todos los tests se ejecutan en una pipeline que verifica que nuestro código es válido y, si lo es, se despliega en un entorno de staging. Esto nos protege de errores que hayamos cometido a la hora de programar pero, ¿qué pasa si por un error de configuración dejamos de tener acceso a ciertos recursos como puede ser base de datos o S3?

Independientemente del equipo que gestione los recursos de infraestructura, lo normal es que la configuración de esos recursos esté en un repositorio con un ritmo de cambio distinto y con unos tests que no tienen porqué cubrir todos nuestros casos de uso. Alguien podría borrar los permisos de acceso a un recurso para una aplicación, desplegar y no enterarnos hasta que empezamos a recibir errores de los usuarios.

La solución por la que hemos optado es chequear contínuamente en producción (y staging) que nuestro sistema tenga acceso a los recursos que necesita. Para ello, usamos un endpoint de health check. Kubernetes llama periódicamente a este endpoint y, en lugar de simplemente devolver un OK para decir que nuestra API está funcionando, aprovechamos para realizar una serie de comprobaciones adicionales. Por volver un poco a la terminología de Cindy, estaríamos haciendo tests release o post-release, ya que el código ya está disponible para los usuarios pero seguimos monitoreando posibles errores.

En el caso de S3, lo que haremos es subir una pequeña imagen, comprobar que si le hacemos una request nos da un 200 y luego borrarla. Esto nos da la seguridad de que en todo momento nuestra API tiene acceso a S3 en producción. No evitará que se produzcan errores en producción, pero sí nos avisará rápidamente del error, dando la posibilidad de que lo arreglemos incluso antes de que lo vean los usuarios.

Distintos tests, distintos beneficios

Resumiendo todo nuestro “viaje” hacia la tranquilidad de la integración con S3, al final, nos hemos quedado con tres tipos de tests.

Tests de integración locales contra una imagen de Docker. Son tests relativamente rápidos que nos dan la tranquilidad de que usamos el SDK de AWS de la forma correcta, y que se van a ejecutar en cada pipeline. Nos pueden proteger de subir a producción errores como URLs mal generadas o subir ficheros sin permisos de lectura o sin las cabeceras adecuadas.
Tests de configuración cuando haya que hacer cambios (config tests en fase de deploy). Si tenemos que cambiar la forma de conectarnos al bucket (o cambiar de bucket), duplicamos las configuraciones y decidimos una u otra en función de una feature flag. No nos protege de desplegar código con errores en producción, pero podemos desactivar ese código y volver a una configuración que funciona correctamente.
Health check de conexión con S3 (monitoring en fase de release o post-release). Es un test que se ejecutará periódicamente en staging y producción que comprobará que seguimos pudiendo hablar con S3 y que tenemos los permisos necesarios. No va a evitar que subamos errores a producción o que algún usuario pueda ver esos errores, pero tendremos una forma rápida de detectar esos errores y poder actuar en consecuencia.

Agradecimientos

Gracias a mis compañeros de Codesai por el feedback y al equipo de B2B de LifullConnect por las conversaciones que han servido para escribir este post.

Referencias

Sleeping is not the best option

2020-10-17T05:00:00+00:00

Introduction.

Some time ago we were developing a code that stored some data with a given TTL. We wanted to check not only that the data was stored correctly but also that it expired after the given TTL. This is an example of testing asynchronous code.

When testing asynchronous code we need to carefully coordinate the test with the system it is testing to avoid running the assertion before the tested action has completed^[1]. For example, the following test will always fail because the assertion in line 30 is checked before the data has expired:

In this case the test always fails but in other cases it might be worse, failing intermittently when the system is working, or passing when the system is broken. We need to make the test wait to give the action we are testing time to complete successfully and fail if this doesn’t happen within a given timeout period.

Sleeping is not the best option.

This is an improved version of the previous test in which we are making the test code wait before the checking that the data has expired to give the code under test time to run:

The problem with the simple sleeping approach is that in some runs the timeout might be enough for the data to expire but in other runs it might not, so the test will fail intermittently; it becomes a flickering test. Flickering tests are confusing because when they fail, we don’t know whether it’s due to a real bug, or it is just a false positive. If the failure is relatively common, the team might start ignoring those tests which can mask real defects and completely destroy the value of having automated tests.

Since the intermittent failures happen because the timeout is too close to the time the behavior we are testing takes to run, many teams decide to reduce the frequency of those failures by increasing the time each test sleeps before checking that the action under test was successful. This is not practical because it soon leads to test suites that take too long to run.

Alternative approaches.

If we are able to detect success sooner, succeeding tests will provide rapid feedback, and we only have to wait for failing tests to timeout. This is a much better approach than waiting the same amount of time for each test regardless it fails or succeeds.

There are two main strategies to detect success sooner: capturing notifications^[2] and polling for changes.

In the case we are using as an example, polling was the only option because redis didn’t send any monitoring events we could listen to.

Polling for changes.

To detect success as soon as possible, we’re going to probe several times separated by a time interval which will be shorter than the previous timeout. If the result of a probe is what we expect the test pass, if the result we expect is not there yet, we sleep a bit and retry. If after several retries, the expected value is not there, the test will fail.

Have a look at the checkThatDataHasExpired method in the following code:

By polling for changes we avoid always waiting the maximum amount of time. Only in the worst case scenario, when consuming all the retries without detecting success, we’ll wait as much as in the just sleeping approach that used a fixed timeout.

Extracting a helper.

Scattering ad hoc low level code that polls and probes like the one in checkThatDataHasExpired throughout your tests not only make them difficult to understand, but also is a very bad case of duplication. So we extracted it to a helper so we could reuse it in different situations.

What varies from one application of this approach to another are the probe, the check, the number of probes before failing and the time between probes, everything else we extracted to the following helper^[3]:

This is how the previous tests would look after using the helper:

Notice that we’re passing the probe, the check, the number of probes and the sleep time between probes to the AsyncTestHelpers::assertWithPolling function.

Conclusions.

We showed an example in Php of an approach to test asynchronous code described by Steve Freeman and Nat Pryce in their Growing Object-Oriented Software, Guided by Tests book. This approach avoids flickering test and produces much faster test suites than using a fixed timeout. We also showed how we abstracted this approach by extracting a helper function that we are reusing in our code.

We hope you’ve found this approach interesting. If you want to learn more about this and several other techniques to effectively test asynchronous code, have a look at the wonderful Growing Object-Oriented Software, Guided by Tests book^[4].

Acknowledgements.

Thanks to my Codesai colleagues for reading the initial drafts and giving me feedback and to Chrisy Totty for the lovely cat picture.

Notes.

[1] This is a nice example of Connascence of Timing (CoT). CoT happens when when the timing of the execution of multiple components is important. In this case the action being tested must run before the assertion that checks its observable effects. That's the coordination we talk about. Check our post about Connascence to learn more about this interesting topic.

[2] In the capturing notifications strategy the test code "observes the system by listening for events that the system sends out. An event-based assertion waits for an event by blocking on a monitor until gets notified or times out", (from Growing Object-Oriented Software, Guided by Tests book).
Some time ago we developed some helpers using the capturing notifications strategy to test asynchronous ClojureScript code that was using core.async channels. Have a look at, for instance, the expect-async-message assertion helper in which we use core.async/alts! and core.async/timeout to implement this behaviour. The core.async/alts! function selects the first channel that responds. If that channel is the one the test code was observing we assert that the received message is what we expected. If the channel that responds first is the one generated by core.async/timeout we fail the test. We mentioned these async-test-tools in previous post: Testing Om components with cljs-react-test.

[3] Have a look at the testing asynchronous systems examples in the GOOS Code examples repository for a more object-oriented implementation of helper for the polling for changes strategy, and also examples of the capturing notifications strategy.

[4] Chapter 27, Testing Asynchronous code, contains a great explanation of the two main strategies to test asynchronous code effectively: capturing notifications and polling for changes.

References.

Growing Object-Oriented Software, Guided by Tests, Steve Freeman and Nat Pryce (chapter 27: Testing Asynchronous Code)
Eradicating Non-Determinism in Tests, Martin Fowler

The value of caring

2020-06-11T05:00:00+00:00

Introduction

We’d like to tell you about a narrative that has been very useful for us in the coaching work we have been doing with several teams during the last year.

Origin

It all started during a consultancy work that Joan Valduvieco and I did at the beginning of 2019 at Trovit. José Carlos Gil and Edu Mateu had brought us to help Trovit’s B2B team. We spent a week with the team asking questions, observing their work and doing some group dynamics to try to understand how we might help them.

After that week of “field work” we had gathered a ton of notes, graphs and insights that we needed to put in order and analyze. This is always a difficult task because it is about analyzing a sociotechnical system (team, knowledge, technology, existing code, organization, pressure, changes,…) which is a complex system in constant flux. In a way, you have to accept that this is something you can’t wholly understand, and even less in a short period of time.

Having that in mind, we tried to do our best to get a first approximation by representing the different dynamics and processes we had observed in several causal loop diagrams. This work helped us clarify our minds and highlight how habits, knowledge, beliefs, culture and practices were creating vicious cycles, (related to some positive feedback loops in the causal loop diagram^[1]), that were amplifying and preserving destructive effects for the team and its software which made their system less habitable and sustainable, and created inefficiencies and loss of value.

After that we started to think about strategies that might break those vicious cycles, either by reducing the effect of some node (a problematic habit, practice or belief), by removing an interaction between nodes in a positive loop, or introducing negative feedback in the system (new practices and habits) to stabilize it.

Donella H. Meadows in her book Thinking in Systems: A Primer talks about different types of leverage points which are places within a complex system where you can try to apply what we call change levers to make the system evolve from its current dynamics into another that might be more interesting for the team.

Different types of leverage points and their relative strength according to Meadows.

We detected several change levers that might be applied to the system at different leverage points to improve the sustainability of the system, such as, “Improving Technical Skills”, “Knowledge Diffusion”, “Knowledge Crystallization”, “Changing Habits”, “All Team Product Owning” or “Remote First”^[2].

All of them attacked vicious cycles that were entrenched in the team’s dynamics, and were valuable in themselves, but we were not sure that they would be enough to change the system’s current dynamics. Something that we observed during our field work was that the team was very skeptical about the probabilities of success of any initiative to improve its situation. They had gone through several failed attempts of “Agile” transformation before, and this has left them in a kind of state of learned helplessness. Why had those previous attempts failed? Would ours succeed using our change levers?

We started to realize that there was a deeper force at play that was exacerbating the rest of the problems and would reduce the effect of any of the other change levers. We realized that they would be useless unless the team had enough slack and company support to apply them. The deeper and stronger force that was inhibiting the possibility of having that slack and support was the very conception of what value meant for the company, it was a cultural problem.

We then came up with a new change lever: “Redefinition of Value”. This was the most powerful change lever of all the ones we had detected because it was a cultural change^[3], and it would increase the probabilities of success of all other change levers. Being a cultural change also made it the most difficult to apply.

Redefinition of Value

What was this “Redefinition of Value” change lever about?

The culture of the team was understanding value only as producing features for their clients as quickly as possible. This definition of value only includes certain kinds of tasks, the ones that directly produce features, but excludes many tasks that don’t directly produce features, but that are necessary for the sustainability of the system (the business and team) itself. The first kind of work is called productive work and the second kind is called caring work^[4].

Believing that only one type of work has value, (productive work), and then focusing only on that type of work is an extractive micro-optimization that might end destabilizing the system^[5].

The redefinition of value we proposed was that not only producing features for the client as quickly as possible is valuable, that there is also value in keeping the sustainability of the business and team. Aside from working on productive tasks, you need to devote energy and time to work on caring tasks which are concerned with keeping the health of the ecosystem composed of the code, the team and the client, so that it can continue evolving, being habitable for the team and producing value. We think that this kind of work (caring work) has value and is strategic for a company. If you think about it, at the bottom, this is about seeing the team as the real product and establishing a healthier and more durable relationship with clients.

This idea of caring work comes from economic studies from a gender perspective. In feminist economics caring work is defined as, “those occupations that provide services that help people develop their capabilities, or the ability to pursue the aspects of their lives that they value” or “necessary occupations and care to sustain life and human survival”.

We thought that for this redefinition of value to be successful, it needed to be stated very clearly to the team from above. This clarity is crucial to avoid the developers having to solve the conflicts that arise when the value of caring tasks is not clear. In those cases, it’s often caring work which gets neglected.

Those conflicts are actually strategic and, as such, they should be resolved at the right level so that the team receives a clear message that gives them focus, and the peace of mind that they are always working in something that is really valued by the company.

In many companies the value of caring only appears in company statements (corporate language), but it’s not part of the real culture, the real system of values of the company. This situation creates a kind of doublespeak that might be very harmful. A way to avoid that might be putting your money where your mouth is.

So with all these ingredients we cooked a presentation for the team lead, the CTO and the CPO of the company^[6], to tell them the strategy we would like to follow, the cultural change involved in the redefinition of value that we thought necessary and how we thought that the possible conflicts between the two types of work should be resolved at their level. They listened to us and decided to try. They were very brave and this decision enabled a wonderful change in the team we started to work with^[7]. The success of this experiment made it possible for other teams to start experimenting with this redefinition of value as well.

Is this not the metaphor of technical debt in a different guise?^[8]

We think that the narrative of caring work, it’s not equivalent to technical debt.

The technical debt metaphor has evolved a lot from the concept that Ward Cunningham originally coined. With time the metaphor was extended to cover more than what he initially meant^[9]. This extended use of the metaphor has been criticized by some software practitioners^[10]. Leaving this debate aside, let’s focus on how most people currently understand the technical debt metaphor:

“Design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal systems qualities - primarily, but not only, maintainability and evolvability.” from Managing Technical Debt: Reducing Friction in Software Development

Technical debt describes technical problems that cause friction in software development and how to manage them.

On the other hand, the caring work narrative addresses the wider concern of sustainability in a software system, considering all its aspects (social, economic and technical), and how both productive and caring work are key to keep a sustainable system. We think that makes the caring work narrative a wider concept than technical debt.

This narrative has created a cultural shift that has allowed us not only to manage technical debt better, but also to create room for activities directed to prevent technical debt, empower the team, amplify its knowledge, attract talent, etc. We think that considering caring work as valuable as productive work placed us in a plane of dialogue which was more constructive than the financial metaphor behind technical debt.

How are we applying it at the moment?

Applying the caring work narrative depends highly on the context of each company. Please, do not take this as a “a recipe for applying caring work” or “the way to apply caring work”. What is important is to understand the concept, then you will have to adapt it to your own context.

In the teams we coach we are using something called caring tasks (descriptions of caring work) along with a variation of the concerns mechanism^[11] and devoting percentages of time in every iteration to work on caring tasks. The developers are the ones that decide which caring work is needed. These decisions are highly contextual and they involve trade offs related to asymmetries initially found in each team and in their evolution. There are small variations in each team, and the way we apply them in each team has evolved over time. You can listen about some of those variations in the two podcasts that The Big Branch Theory Podcast will devote to this topic.

We plan to write in the near future another post about how we are using the concerns mechanism in the context of caring work.

Conclusions

We have been using the redefinition of value given by the caring work for more than a year now. Its success in the initial team made it possible for other teams to start experimenting with it as well. Using it in new teams has taught us many things and we have introduced local variations to adapt the idea to the realities of the new teams and their coaches.

So far, it’s working for us well and we feel that it has helped us in some aspects in which using the technical debt metaphor is difficult like, for example, improving processes or owning the product.

Some of the teams worked only on legacy systems, and other teams worked on both greenfield and legacy systems (all the legacy systems had, and still have, a lot of technical debt).

We think it is important to consider that the teams we have been collaborating with were in a context of extraction^[12] in which there is already a lot of value to protect.

Due to the coronavirus crisis some of the teams have started to work on an exploration context. This is a challenge and we wonder how the caring work narrative evolves in this context and a scarcity scenario.

To finish we’d like to add a quote from Lakoff^[13]:

“New metaphors are capable of creating new understandings and, therefore, new realities”

We think that the caring work narrative might help create a reality in which both productive and caring work are valued and more sustainable software systems are more likely.

Acknowledgements

Thanks to Joan Valduvieco, Beatriz Martín and Vanesa Rodríguez for all the stimulating conversations that lead to the idea of applying the narrative of caring work in software development.

Thanks to José Carlos Gil and Edu Mateu for inviting us to work with Lifull Connect. It has been a great symbiosis so far.

Thanks to Marc Sturlese and Hernán Castagnola for daring to try.

Thanks to Lifull’s B2B and B2C teams and all the Codesai colleagues that have worked with them, for all the effort and great work to take advantage of the great opportunity that caring tasks created.

Finally, thanks to my Codesai colleagues and to Rachel M. Carmena for reading the initial drafts and giving me feedback.

Notes

[1] Positive in this context does not mean something good. The feedback is positive because it makes the magnitude of the perturbation increase (it positively retrofeeds it).

[2] Those were the names we used when we presented what we have learned during the consultancy.

[3] In systems thinking a leverage point is a place within a complex system (a corporation, an economy, a living body, a city, an ecosystem) where a shift can be applied to produce changes in the whole system behavior. It would be a low leverage point if a small shift produces a small behavioral change. It’s a high leverage point if a small shoif causes a large behavioral change. According to Donella H. Meadows the most effective place to intervene a system is:

“The mindset or paradigm out of which the system — its goals, power structure, rules, its culture — arises”.

As you can imagine this is the most difficult thing to change as well. To know more read Leverage Points: Places to Intervene in a System.

[4] Also known as reproductive work. This idea comes from a gender perspective of economics. You can learn more about it reading the Care work and Feminist economics articles in Wikipedia.

[5] Sadly we observe this phenomena at all scales: a business, a relationship, an ecosystem, the planet…

[6] Edu Mateu, Marc Sturlese and Hernán Castagnola were then the B2B team lead, the CTO and the CPO, respectively.

[7] B2B was the first team we worked with. Fran Reyes and I started coaching them in February 2019 but after a couple of months Antonio de la Torre and Manuel Tordesillas joined us. Thanks to their great work of this team, other teams started using the caring work narrative around 6 month after.

[8] Thanks to Fran Reyes and Alfredo Casado for the interesting discussions about technical debt that helped me write this part.

[9] You can listen Ward Cunningham himself explaining what he actually meant with the technical debt metaphor in this video.

[10] Two examples: A Mess is not a Technical Debt by Robert C. Martin and Bad code isn’t Technical Debt, it’s an unhedged Call Option by Steve Freeman.

[11] The concerns mechanism is described by Xavi Gost in his talk CDD (Desarrollo dirigido por consenso).

[12] To know more watch 3X Explore/Expand/Extrac by Kent Beck or read Kent Beck’s 3X: Explore, Expand, Extract by Antony Marcano and Andy Palmer.

[13] From Metaphors We Live By by George Lakoff and Mark Johnson.

References

Books

Articles

Leverage Points: Places to Intervene in a System , Donella H. Meadows
Positive feedback (or exacerbating feedback) (Wikipedia)
Leverage points places to intervene in a system (Wikipedia)
Twelve leverage points (Wikipedia)
Care work (Wikipedia)
Feminist economics (Wikipedia)
System Dynamics (Wikipedia)
Causal loop diagram (Wikipedia)
Technical Debt, Martin Fowler
A Mess is not a Technical Debt, Robert C. Martin
Bad code isn’t Technical Debt, it’s an unhedged Call Option, Steve Freeman
Kent Beck’s 3X: Explore, Expand, Extract, Antony Marcano, Andy Palmer

Talks

SPIDR, criterios para dividir historias de usuario

2020-05-10T16:48:00+00:00

Las historias de usuarios son una gran herramienta para entender lo que se quiere hacer, por qué y para quién. Ron Jeffries en el libro Extreme Programming Installed, describe los tres aspectos críticos de las historias de usuario como Card, Conversation, Confirmation, dónde la tarjeta (Card) simplemente recoge el texto suficiente para que podamos tener una conversación más adelante. Dicho de otro modo, una historia de usuario es el recordatorio de una conversación.

La diferencia con la captura de requisitos clásica, es que los requisitos intentan expresar todos los detalles de manera escrita. Las historias de usuario en cambio buscan obtener esa información mediante una conversación en el momento preciso. Ese momento será cuando quede poco para que la historia de usuario sea abordada.

Uno de los típicos problemas cuando se escriben las historias de usuarios es mantener conversaciones largas y complejas. Esto es probablemente un síntoma de que el tamaño de la historia de usuario abarca demasiados temas. Otro problema común suele producirse más adelante, cuando se tarda mucho en que los usuarios dispongan de la funcionalidad derivada de la historia de usuario, este problema también puede ser causado por el tamaño de las historias.

El arte de crear historias de usuario de tamaño adecuado por tanto es esencial para sacar partido a todo su potencial.

Existen diferentes heurísticas que nos ayudan a detectar y resolver problemas con el tamaño de las historias de usuario. Bill Wake y Mike Cohn tienen un trabajo interesante al respecto. En este articulo nos centraremos en un conjunto de heurísticas que Mike Cohn propuso para partir historias de usuario, y que denominó SPIDR.

SPIDR es el acrónimo de Spike, Paths, Interfaces, Data and Rules, que son en realidad una serie de criterios por los que potencialmente podríamos partir una historia de usuario.

Spike

Algunas veces las historias son demasiado grandes porque el equipo no sabe cómo hacer alguna parte de la historia. Quizás la historia envuelve una tecnología no familiar o una parte del código desconocida. Lo mejor en esto casos es hacer un spike para reducir incertidumbre. Un spike es una actividad de investigación.

Un ejemplo podría ser:

Como miembro, cualquier click es analizado por el Super Sistema de Marketing Automatizado para que pueda recibir un email con información sobre cosas en las que yo parezca estar interesado.

Y al reconocer que nadie conoce cómo funciona el Super Sistema de Marketing Automatizado y puede haber mucha incertidumbre, pasaríamos a crear el siguiente spike

Investigar el Super Sistema de Marketing Automatizado.

Un spike debe tener un timebox para evitar la tentación de parálisis por análisis.

El objetivo de un spike es el aprendizaje, no el desarrollo de una funcionalidad. Los spikes ayudan a reducir incertidumbre sobre cómo construir la funcionalidad. Por otro lado, crear spikes con demasiada frecuencia puede ser un síntoma de que el equipo necesita formación en aspectos concretos (tecnología, dominio, etc).

Paths

A veces se puede considerar que una historia tiene múltiples pasos. El usuario hace X y entonces hace Y y entonces Z. Un ejemplo podría ser:

Como miembro, puedo pagar por una reserva que he realizado.

De la que podemos sacar los siguientes pasos convertidos en historias de usuario:

Como miembro reservando un coche, puedo introducir la información del pago.

Como miembro reservando un coche, puedo introducir la dirección de facturación.

Como miembro reservando un coche, puedo indicar la oficina en la que recogeré el coche reservado.

Las diferentes historias en las que se divide la historia original son independientes y por tanto, si quisiesemos podríamos implementarlas en paralelo. O podríamos optar por realizar una primera release en el que alguno de los caminos sea aún manual.

Por ejemplo, se le podría avisar al usuario que para la parte relativa a “emitir la factura” debe enviar un correo con sus datos fiscales. Posteriormente este correo es respondido por una persona de manera manual hasta que el sistema implemente la generación de la factura.

Interfaces

Algunas historias de usuario son complicadas porque tienen múltiples interfaces. A veces pueden ser user interfaces (mobile, desktop) y otras data interfaces (múltiples APIs).

Si tuviéramos una historia que necesita que funcione en la web, en iOs y Android, una buena opción es partir por tipo de interface, Ejemplo:

Como un usuario de iOS, puedo hacer cualquier cosa.

Como un usuario de Android, puedo hacer cualquier cosa.

Como un usuario usando un browser, puedo hacer cualquier cosa.

Data

Una historia puede ser larga por la cantidad y tipos de datos que debe soportar. Desarrollar una versión inicial que soporte un subset de datos puede ser una gran modo de partir una historia.

También podríamos decidir ignorar algunos tipos de datos de manera eventual. Ignorarlos puede pasar por no coleccionarlos o no procesarlos o validarlos.

Un ejemplo podría ser:

Como turista quiero ver cosas interesantes en la ciudad.

Podríamos partir la historia de acuerdo con los diferentes tipos de “cosas interesantes”, en este caso, museos, tours, actividades, etc.

Rules

Algunas historias de usuario son largas porque implican implementar múltiples reglas. Un ejemplo sería:

Como miembro, puedo reservar un coche

Un miembro no puede reservar un coche con más de 90 días de antelación.
Un miembro no puede tener más de 3 reservas activas a la vez.

Que se podría partir atacando alguna regla en una historia de usuario diferente:

Como miembro, no puedo tener más de 3 reservas activas a la vez

Conclusión

Manejar el tamaño preciso de las historias de usuario nos ofrece ventajas para entregar funcionalidad de manera temprana y focalizarnos en pequeños aspectos de valor. Conocer heurísticas para partir las historias de usuario nos ayuda a visualizar formas de hacerlo. Aunque existen múltiples propuestas a este problema, SPIDR de Mike Cohn ofrece un conjunto simple, fácil de recordar y que nos puede ayudar bastante en la mayoría de los escenarios.

Referencias

Extreme Programming Installed
Essential XP: Card, Conversation, Confirmation By Ron Jeffries
F ive Simple but Powerful Ways to Split User Stories By Mike Cohn
Better User Stories Course By Mike Cohn
Twenty Ways to Split Stories By Bill Wake

¡Habemus podcast!

2020-05-08T09:00:00+00:00

Haciendo caso omiso de todas las recomendaciones sanitarias para este confinamiento hemos decidido, como podréis adivinar por el título, ¡crear un podcast!

La realidad es que ya llevábamos tiempo con ganas de hacerlo y estas últimas fechas no han sido más que la excusa perfecta para encontrar el tiempo que en otras ocasiones no habíamos sido capaces de encontrar. En este podcast hablaremos de los temas que más nos interesan en el mundo que nos apasiona: el desarrollo de software.

Las temáticas no estarán restringidas a ninguna tecnología concreta; intentaremos hablar de temas transversales como por ejemplo buenas prácticas, testing, arquitectura, aprendizaje, nuestro amigo el legacy code y otros muchos. No hablaremos mucho de lenguajes/librerías/frameworks concretos más allá de cuando esto nos sirva para ejemplificar alguna práctica más transversal, que es lo más nos motiva.

Este podcast no es un podcast sólo de Codesai, está abierto a que cualquiera con ganas y algo que decir tenga un espacio para participar. Así que si queréis participar o tenéis un tema del que os gustaría que hablásemos no tenéis más que decirlo.

El nombre, decidido bajo arduo consenso y discusiones interminables de 10 minutos o más, es The Big Branch Theory. Para el quien no pille la tontería, pensad en Trunk Based Development, una práctica de la que hemos hablado en muchas ocasiones… sí, ese es el nivel jaja.

De momento llevamos ya 3 capítulos publicados donde hablamos sobre pair programing, microservicios, y aprendizje, así variadito para empezar. Y como estaréis ya ansios@s, sin más preámbulo podéis escucharlos a continuación:

Podeís agregar el feed del podcast

O simplemente escucharlo a continuación:

¡Bienvenido a Codesai, Rubén!

2020-04-17T17:00:00+00:00

Contamos hoy con una buena noticia, bien recibida dada la situación actual, y es que a partir de ahora somos uno más en Codesai! Queríamos escribir un pequeño post dándole la bienvenida a Rubén, presentándole un poquito desde mi perspectiva y luego la suya.

En su día, junto con Rubén organizamos algunas de las primeras katas y charlas que hicimos en la comunidad de Gran Canaria. Y luego nos volvimos locos y junto con el resto de organizadores montamos el Socracan en Gran Canaria en 2016, que siguió en 2017, 18 y 19 hasta que volvió a Tenerife este año 2020.

Alfredo, Migue y yo pudimos trabajar con Rubén durante más de un año, y no dudamos del valor que puede aportar a un equipo. Consideramos que posee un gran nivel técnico (traducción: es fleje bueno), no tiene miedo a meterse en cualquier área del desarrollo y se alinea mucho con los principios que compartimos en Codesai. En un plano más personal, siempre ha demostrado ser una persona dispuesta a ayudar y a buscar la forma de llegar a acuerdos razonables.

Por lo que en conjunto, hacía ya un tiempo que lo habíamos valorado como un buen candidato para formar parte de Codesai. Y sin enrollarme mucho más, voy a dejar que se presente él mismo un poquito :) Un placer tenerte con nosotros Rubén!

Gracias a Dani y todo el equipo por la calurosa bienvenida. Probablemente no se me conozca tanto en la comunidad como a otros, así que aquí va un poco sobre mí.

Llevo trabajando en esto del desarrollo algo más de 5 años. Alguna gente diría que soy fullstack, pero a mi me gusta más la expresión “soy capaz de meter deuda técnica en varias capas del sistema”. Me encanta trabajar en entornos en los que se siguen prácticas de eXtreme Programming, colaborando con negocio para aportar valor y aprendiendo todo lo posible del resto de personas con las que trabajo.

Hará unos 6 años que conozco a varios miembros de Codesai. Desde 2014 nos juntábamos Miguel, Ronny, Dani y yo para hacer katas, a las que a veces se nos unía gente como Manu Rivero, Alfredo o Fran. También nos cruzamos en muchos eventos de desarrollo, en los que conocí a Toño y Manu Tordesillas. Son gente con la que comparto inquietudes y sus posts/charlas siempre han sido referencia para mí en el aprendizaje. He hablado con Miguel y Dani en alguna ocasión para unirme a Codesai, hasta que finalmente surgió la oportunidad en febrero de este año (justo en el momento de mayor estabilidad laboral, ¿eh?).

Sólo me queda dar las gracias a todo el equipo por acogerme y esperemos que dentro de no mucho podamos hacer un Flejesai presencial y compartir unos días juntos.

El valor de escribir el test primero

2020-02-16T14:00:00+00:00

Toda persona que haya investigado un poco el Test Driven Development estará familiarizada con los 3 pasos que implica:

Red, escribir primero un test que falla
Green, escribir el código de producción para pasar el test
Refactor, evaluar una posible mejora en la implementación
Y repetimos indefinidamente hasta obtener funcionalidades completas

Si bien es cierto que marcan la base del TDD, si nos quedamos ahí no estamos sino arañando la superficie. A medida que lo practicamos y adquirimos fluidez, vamos descubriendo el gran valor que nos aporta seguir estos pasos (o posibles variaciones), pues tienen su razón de ser y a menudo no se aprecia si no le dedicamos el tiempo y la atención suficientes.

He querido desarrollar una charla para hacer hincapié en varios argumentos sobre el por qué de escribir el test primero, en lugar de hacerlo de forma automática puesto que simplemente se trata del primer paso a seguir en el ciclo. También quise ilustrar algunos de esos argumentos con ejemplos de live coding para que se pudiera (espero) apreciar cómo el ser consciente de éstos afecta al flujo de desarrollo. Y sobretodo, intentar que se recuerde el siguiente mensaje:

TDD = Diseñar
Escribir el test primero = Pensar

Tuve la oportunidad de presentarla en esta pasada CAS 2019, y ahora se puede ver en el enlace a continuación.

Muchas gracias a la organización de la CAS 2019, a Autentia por la producción del vídeo, y a toda persona que haya apreciado la charla :)

Las slides se pueden ver en Slideshare

Me vuelvo a Subversion!

2019-12-28T09:00:00+00:00

Estaba el otro día viendo la charla Continuous delivery and the theory of constraints de Steve Smith, que de paso os recomiendo, y en un momento de la charla el autor relatando una experiencia pasada en un equipo que usaba subversion en lugar de git u otro DVCS, decía algo como:

Sometimes bad tools lead to good practices and sometimes good tools lead to very bad practices

Esto me hizo pararme un poco a pensar si realmente con los DVCS, que podríamos decir que se han instalado como un estándar de facto en la industria, hemos ganado tanto o incluso que cosas hemos perdido por el camino.

¿Cómo elegimos nuestro VCS?

Voy a dar por hecho que usar un VCS es algo conveniente en cualquier proyecto, aquí creo que no hay mucho debate. La cuestión es, ¿cuando nos planteamos que VCS usar qué criterios estamos siguiendo para escoger uno u otro?.

Yo soy de la creencia de que las prácticas van primero y las herramientas después, primero tengo que tener claro qué prácticas quiero seguir, por ejemplo la integración continua, y después elijo las herramientas más simples que habiliten la aplicación de dichas prácticas.

Siguiendo con la idea anterior, para mi la integración continua y en consecuencia la posibilidad de hacer deploy continuo, son prácticas que considero muy deseables. Aclarar que cuando me refiero a integración continua quiero decir integrar el trabajo en pequeños incrementos que se miden en minutos o en el peor de los casos en horas. Un escenario donde el trabajo que estoy haciendo ahora se vaya a integrar con el del resto del equipo en días o semanas queda lejos de la idea original de integración continua, aunque tenga dos jenkins y un travis.

¿Y que necesito para esto?, pues poco más que un sistema que me permita ir integrando mis cambios en una línea de desarrollo, no necesito un VCS que me ofrezca un sistema muy sofisticado para crear/mezclar/rebasar ramas como ofrecen muchos DVCS.

La reflexión que considero importante aquí es, ¿estoy eligiendo la herramienta más simple que habilite mis prácticas? o ¿estoy dejando que mis prácticas se definan por el uso de una herramienta que ofrece más posibilidades?.

Commit vs Commit & Push

Gestión de ramas aparte otra diferencia importante cuando usamos un DVCS es que para enviar cambios al repositorio que compartimos con todo el equipo no basta con hacer “commit” sino que después de añadir nuestros cambios al repositorio local tenemos que sincronizarlo con el repositorio compartido, por ejemplo en git haciendo push.

Analizando un poco qué significa esto de commit, la acepción que más encaja con el uso que hacemos en nuestro contexto podría ser:

transfer something to (a state or place where it can be kept or preserved)

En otras palabras, hacer commit es tomar la decisión de que nuestros cambios son suficientemente buenos como para querer guardarlos o preservarlos. En un VCS no distribuido como svn hacer commit requiere un alto grado de compromiso por parte del desarrollador ya que estamos tomando la decisión de que nuestros cambios son suficientemente buenos para considerar que añaden valor al producto e integrarlos con los cambios que están haciendo el resto de compañeros. En un DVCS sin embargo el grado de compromiso para hacer commit es mucho menor, ya que simplemente estamos guardando esos cambios en el repositorio local pero no estamos añadiendo ningún valor al producto ni integrándonos con los cambios del resto de compañeros, en este escenario el compromiso real es cuando hacemos push.

En git es incluso habitual hacer algún tipo de modificación sobre el commit o conjunto de commits previo al push, por ejemplo squash para juntar varios commits en uno sólo, de forma que ese grado de compromiso del que hablaba antes de hacer commit en git es casi nulo, porque antes de hacer push la herramienta nos ofrece multitud de opciones para rehacer esos commits a nuestro gusto. ¿Cuántas veces habéis hecho un commit con algo que sabéis que no está del todo terminado para “no perder los cambios”?, ¡un VCS no es un sistema de backup!. Si estás haciendo esto, salvo que acabes de recibir una llamada porque tu casa está en llamas, es muy probable que tus incrementos sean demasiado grandes.

Lo que ocurre al final cuando dividimos nuestro proceso para integrar cambios en dos fases es lo mismo que ocurre cuando hacemos nuestros cambios sobre una rama para integrarlos posteriormente. Estamos retrasando nuestro compromiso, tomar compromisos es por supuesto algo difícil que no se puede hacer a la ligera, en general siempre que encontramos problemas difíciles o que pueden causar cierto dolor tenemos dos opciones:

Retrasar el dolor en el tiempo, es humano e intuitivo retrasar las situaciones difíciles o que puedan causar cierto dolor.
Hacerlo lo más frecuentemente posible, con el doble objetivo de por un lado minimizar el dolor dividiendo el problema en otros más pequeños y por otro lado aliviar el nivel de dificultad repitiendo el proceso muchas veces, con lo que vamos desarrollando las prácticas y la experiencia que nos permiten hacer de un problema difícil algo cotidiano y más sencillo.

El espíritu del desarrollo ágil siempre ha abogado por esta segunda opción: iteraciones cortas, integración continua o incluso TDD. Todas estas prácticas tienen por objetivo convertir situaciones dolorosas y difíciles en situaciones cotidianas y más sencillas de abordar.

Dicho todo esto, para seguir las prácticas que realmente son importantes para mi no necesito de una herramienta que me permita aplazar el compromiso, es más, diría que es sano que la herramienta no disponga de esta opción y que todo el equipo se habitué como algo natural a que tomar compromisos es algo que hay que hacer con la mayor frecuencia posible y en las dosis más pequeñas posibles.

Conclusión

No es mi objetivo decirle a nadie qué herramienta tiene que usar, en realidad, la discusión sobre la herramienta a usar no es muy relevante. Lo importante, y ya que estamos en unas fechas tan propias para la reflexión a final de año, es que analicemos si la herramienta que estamos usando está alineada con nuestras prácticas y filosofía de desarrollo o si por el contrario nos hemos dejado cegar un poco por la cantidad de opciones que ofrece una herramienta y es precisamente esta última la que está definiendo las prácticas por nosotros.

Funny Docker Workshop to learn from scratch

2019-12-17T21:00:00+00:00

Introduction

In one of our current clients we are taking some learning time for new things outside of our current context/stack. One of the proposals of the team was a Docker workshop because I introduced it for our CI and our local testing environments to avoid connecting to production from the local machines to run the our tests.

So I was the person in charge of preparing it. And here I would like to share a way to learn Docker from scratch I thought of.

Learn by doing

I really believe in the philosophy for learning new things is tighly related with practice, practice, practice… And that’s also in Codesai’s DNA, so I wanted to ideate a way to explain a bit of theory of Docker and exercises to apply that theory. The theory I explained answers the following:

The whys:
- Why Docker?
- Differences with past technologies
- Why is it better than the previous tooling?
The hows:
- How does Docker solve these problems?
- How does Docker improve upon the previous tooling?
- How can Docker help us?

The small exercise consist on assembling two different applications with different languages and let people see one of the advantages of Docker. Removing the complexity of dedicated infrastructure for a concrete language/stack.

And as the last trick I wanted them to see how easy is to build, push an image and publish your Docker container in a famous service like Heroku. So in the last part of the workshop we do that. The steps explaining how to publish your app on Heroku can be also found on the README file inside of the heroku/ folder from the root of the repository.

So I’d like you to check it yourself, give me some feedback and enjoy what I prepared. Let’s Dockerize everything!!.

Here is the repository with the content and the exercises. Each folder has a README.md explaining what to do. The main README.md is just the theory of Docker. Enjoy! Docker Workshop Repo

Playing Fizzbuzz with property-based testing

2019-07-29T05:00:00+00:00

Introduction.

Lately, I’ve been playing a bit with property-based testing.

I practised doing the FizzBuzz kata in Clojure and used the following constraints for fun^[1]:

Add one property at a time before writing the code to make the property hold.
Make the failing test pass before writing a new property.

The kata step by step.

To create the properties, I partitioned the first 100 integers according to how they are transformed by the code. This was very easy using two of the operations on sets that Clojure provides (difference and intersection).

The first property I wrote checks that the multiples of 3 but not 5 are Fizz:

and this is the code that makes that test pass:

Next, I wrote a property to check that the multiples of 5 but not 3 are Buzz (I show only the new property for brevity):

and this is the code that makes the new test pass:

Then, I added a property to check that the multiples of 3 and 5 are FizzBuzz:

which was already passing with the existing production code.

Finally, I added a property to check that the rest of numbers are just casted to a string:

which Id made pass with this version of the code:

The final result.

These are the resulting tests where you can see all the properties together:

You can find all the code in this repository.

Conclusions.

It was a lot of fun doing this kata. It is a toy example that didn’t make me dive a lot into clojure.check’s generators documentation because I could take advantage of Clojure’s set functions to write the properties.

I think the resulting properties are quite readable even if you don’t know Clojure. On the other hand, the resulting implementation is probably not similar to the ones you’re used to see, and it shows Clojure’s conciseness and expressiveness.

Footnotes:

[1] I'm not saying that you should do property-based testing with this constraints. They probably make no sense in real cases. The constraints were meant to make doing the kata fun.

La kata Gilded Rose en PL/SQL: escribiendo los tests

2019-07-07T05:00:00+00:00

Contexto.

En uno de nuestros actuales clientes, Mutua Tinerfeña, estamos trabajando diferentes técnicas para construir software de manera progresiva y confiable. Aunque el equipo es pequeño, sus miembros usan y conocen tecnologías muy diferentes, por lo que necesitábamos practicar dichas técnicas usando como vehículo un lenguaje que dominaran todos los miembros del equipo. Con esto podíamos evitar que algunos miembros del equipo tuvieran que aprender otros paradigmas para poder practicar las nuevas técnicas. Así que elegimos PL/SQL, que era el lenguaje que todos tenían en común, como vehículo de aprendizaje.

Este ejercicio es parte de un curso sobre refactoring de base de datos que estamos preparando con mucho amor. Este curso está pensado para equipos que trabajan con un legacy en el que la mayoría del código se encuentra en la base de datos y puedan incorporar técnicas como testing y empezar a trabajar su legacy con confianza y de forma más sostenible. Esta primera versión del curso está orientado fundamentalmente a Oracle como SGBD, aunque muchas de las ideas pueden ser trasladadas a otros SGBD como SQLServer.

Aprendiendo refactoring y TDD en PL/SQL

Una de las prácticas que hicimos fue resolver la kata Gilded Rose en PL/SQL para practicar refactoring y TDD. En esta kata lo primero que se debe hacer, antes de añadir la funcionalidad que nos piden, es cubrir el código de tests. Estos tests nos permiten refactorizar el código para hacer que, finalmente, sea fácil añadir la nueva funcionalidad usando TDD. En este post contaremos cómo escribimos los tests para la versión PL/SQL de la kata.

Testeando la kata Gilded Rose en PL/SQL usando utPSQL

La herramienta que usamos para testear el código PL/SQL fue utPSQL que es un framework de testing open-source para PL/SQL and SQL. utPSQL nos permite lanzar los tests de manera muy fácil.

Para escribir los tests hay que crear un paquete^[1]. En la especificación del paquete hay que añadir una serie de anotaciones, y, por último, escribir el propio test en el cuerpo del paquete.

Para lanzar todos los tests desde la base de datos^[2] hay que hacer la siguiente llamada a la “librería”:

begin ut.run(); end;

Esta llamada buscará en el schema todos los paquetes que contengan las anotaciones y lanzará sus tests. Existe también la posibilidad de lanzar sólo los tests de un determinado paquete indicándolo como un argumento.

Estos son los tests para la kata Gilded Rose en PL/SQL:

Aunque pueda parecer sorprendente, los tests resultantes son bastante legibles. La legibilidad de los tests, en comparación con otras librerías similares, es uno de los puntos a favor de utPSQL.

Conclusiones

Hemos visto como es posible hacer testing en PL/SQL usando utPSQL. Estos tests crearán una red de seguridad que nos permitirá refactorizar el código, o lo que es lo mismo, mejorar su diseño preservando su comportamiento.

En el próximo post de esta serie enseñaremos como se pueden aplicar técnicas de refactoring y de diseño para mejorar el código PL/SQL de la kata Gilded Rose en pequeños pasos manteniendo los tests en verde en todo momento.

Agradecimientos

Me gustaría agradecer a mi compañero Manuel Rivero por ayudarme a revisar y editar este post, y al equipo de Mutua Tinerfeña por las aportaciones ofrecidas desde su amplia experiencia en este entorno.

[1] Un paquete es una agrupación lógica de procedimientos, funciones, tipos, constantes, etc. Un paquete tiene 2 partes, una especificación y un cuerpo. La especificación es una interfaz para el consumidor y el cuerpo expone la implementación.

[2] También existe la posibilidad de lanzar los tests desde una términal, lo que permite vincularlos a un sistema de integración continua de manera muy sencilla.

An example of listening to the tests to improve a design

2019-06-29T05:00:00+00:00

Introduction.

Recently in the B2B team at LIFULL Connect, we improved the validation of the clicks our API receive using a service that detects whether the clicks were made by a bot or a human being.

So we used TDD to add this new validation to the previously existing validation that checked if the click contained all mandatory information. This was the resulting code:

and these were its tests:

The problem with these tests is that they know too much. They are coupled to many implementation details. They not only know the concrete validations we apply to a click and the order in which they are applied, but also details about what gets logged when a concrete validations fails. There are multiple axes of change that will make these tests break. The tests are fragile against those axes of changes and, as such, they might become a future maintenance burden, in case changes along those axes are required.

So what might we do about that fragility when any of those changes come?

Improving the design to have less fragile tests.

As we said before the test fragility was hinting to a design problem in the ClickValidation code. The problem is that it’s concentrating too much knowledge because it’s written in a procedural style in which it is querying every concrete validation to know if the click is ok, combining the result of all those validations and knowing when to log validation failures. Those are too many responsibilities for ClickValidation and is the cause of the fragility in the tests.

We can revert this situation by changing to a more object-oriented implementation in which responsibilities are better distributed. Let’s see how that design might look:

1. Removing knowledge about logging.

After this change, ClickValidation will know nothing about looging. We can use the same technique to avoid knowing about any similar side-effects which concrete validations might produce.

First we create an interface, ClickValidator, that any object that validates clicks should implement:

Next we create a new class NoBotClickValidator that wraps the BotClickDetector and adapts^[1] it to implement the ClickValidator interface. This wrapper also enrichs BotClickDetector’s’ behavior by taking charge of logging in case the click is not valid.

These are the tests of NoBotClickValidator that takes care of the delegation to BotClickDetector and the logging:

If we used NoBotClickValidator in ClickValidation, we’d remove all knowledge about logging from ClickValidation.

Of course, that knowledge would also disappear from its tests. By using the ClickValidator interface for all concrete validations and wrapping validations with side-effects like logging, we’d make ClickValidation tests robust to changes involving some of the possible axis of change that were making them fragile:

Changing the interface of any of the individual validations.
Adding side-effects to any of the validations.

2. Another improvement: don't use test doubles when it's not worth it^[2].

There’s another way to make ClickValidation tests less fragile.

If we have a look at ClickParamsValidator and BotClickDetector (I can’t show their code here for security reasons), they have very different natures. ClickParamsValidator has no collaborators, no state and a very simple logic, whereas BotClickDetector has several collaborators, state and a complicated validation logic.

Stubbing ClickParamsValidator in ClickValidation tests is not giving us any benefit over directly using it, and it’s producing coupling between the tests and the code.

On the contrary, stubbing NoBotClickValidator (which wraps BotClickDetector) is really worth it, because, even though it also produces coupling, it makes ClickValidation tests much simpler.

Using a test double when you’d be better of using the real collaborator is a weakness in the design of the test, rather than in the code to be tested.

These would be the tests for the ClickValidation code with no logging knowledge, after applying this idea of not using test doubles for everything:

Notice how the tests now use the real ClickParamsValidator and how that reduces the coupling with the production code and makes the set up simpler.

3. Removing knowledge about the concrete sequence of validations.

After this change, the new design will compose validations in a way that will result in ClickValidation being only in charge of combining the result of a given sequence of validations.

First we refactor the click validation so that the validation is now done by composing several validations:

The new validation code has several advantages over the previous one:

It does not depend on concrete validations any more
It does not depend on the order in which the validations are made.

It has only one responsibility: it applies several validations in sequence, if all of them are valid, it will accept the click, but if any given validation fails, it will reject the click and stop applying the rest of the validations. If you think about it, it’s behaving like an and operator.

We may write these tests for this new version of the click validation:

These tests are robust to the changes making the initial version of the tests fragile that we described in the introduction:

Changing the interface of any of the individual validations.
Adding side-effects to any of the validations.
Adding more validations.
Changing the order of the validation.

However, this version of ClickValidationTest is so general and flexible, that using it, our tests would stop knowing which validations, and in which order, are applied to the clicks^[3]. That sequence of validations is a business rule and, as such, we should protect it. We might keep this version of ClickValidationTest only if we had some outer test protecting the desired sequence of validations.

This other version of the tests, on the other hand, keeps protecting the business rule:

Notice how this version of the tests keeps in its setup the knowledge of which sequence of validations should be used, and how it only uses test doubles for NoBotClickValidator.

4. Avoid exposing internals.

The fact that we’re injecting into ClickValidation an object, ClickParamsValidator, that we realized we didn’t need to double, it’s a smell which points to the possibility that ClickParamsValidator is an internal detail of ClickValidation instead of its peer. So by injecting it, we’re coupling ClickValidation users, or at least the code that creates it, to an internal detail of ClickValidation: ClickParamsValidator.

A better version of this code would hide ClickParamsValidator by instantiating it inside ClickValidation’s constructor:

With this change ClickValidation recovers the knowledge of the sequence of validations which in the previous section was located in the code that created ClickValidation.

There are some stereotypes that can help us identify real collaborators (peers)^[4]:

Dependencies: services that the object needs from its environment so that it can fulfill its responsibilities.
Notifications: other parts of the system that need to know when the object changes state or performs an action.
Adjustments or Policies: objects that tweak or adapt the object’s behaviour to the needs of the system.

Following these stereotypes, we could argue that NoBotClickValidator is also an internal detail of ClickValidation and shouldn’t be exposed to the tests by injecting it. Hiding it we’d arrive to this other version of ClickValidation:

in which we have to inject the real dependencies of the validation, and no internal details are exposed to the client code. This version is very similar to the one we’d have got using tests doubles only for infrastructure.

The advantage of this version would be that its tests would know the least possible about ClickValidation. They’d know only ClickValidation’s boundaries marked by the ports injected through its constructor, and ClickValidation`’s public API. That will reduce the coupling between tests and production code, and facilitate refactorings of the validation logic.

The drawback is that the combinations of test cases in ClickValidationTest would grow, and may of those test cases would talk about situations happening in the validation boundaries that might be far apart from ClickValidation’s callers. This might make the tests hard to understand, specially if some of the validations have a complex logic. When this problem gets severe, we may reduce it by injecting and use test doubles for very complex validators, this is a trade-off in which we decide to accept some coupling with the internal of ClickValidation in order to improve the understandability of its tests. In our case, the bot detection was one of those complex components, so we decided to test it separately, and inject it in ClickValidation so we could double it in ClickValidation’s tests, which is why we kept the penultimate version of ClickValidation in which we were injecting the click-not-made-by-a-bot validation.

Conclusion.

In this post, we tried to play with an example to show how listening to the tests^[5] we can detect possible design problems, and how we can use that feedback to improve both the design of our code and its tests, when changes that expose those design problems are required.

In this case, the initial tests were fragile because the production code was procedural and had too many responsibilities. The tests were fragile also because they were using test doubles for some collaborators when it wasn’t worth to do it.

Then we showed how refactoring the original code to be more object-oriented and separating better its responsibilities, could remove some of the fragility of the tests. We also showed how reducing the use of test doubles only to those collaborators that really needs to be substituted can improve the tests and reduce their fragility. Finally, we showed how we can go too far in trying to make the tests flexible and robust, and accidentally stop protecting a business rule, and how a less flexible version of the tests can fix that.

When faced with fragility due to coupling between tests and the code being tested caused by using test doubles, it’s easy and very usual to “blame the mocks”, but, we believe, it would be more productive to listen to the tests to notice which improvements in our design they are suggesting. If we act on this feedback the tests doubles give us about our design, we can use tests doubles in our advantage, as powerful feedback tools^[6], that help us improve our designs, instead of just suffering and blaming them.

Acknowledgements.

Many thanks to my Codesai colleagues Alfredo Casado, Fran Reyes, Antonio de la Torre and Manuel Tordesillas, and to my Aprendices colleagues Paulo Clavijo, Álvaro García and Fermin Saez for their feedback on the post, and to my colleagues at LIFULL Connect for all the mobs we enjoy together.

Footnotes:

[1] See the Adapter or wrapper pattern.

[2] See Test Smell: Everything is mocked by Steve Freeman where he talks about things you shouldn't be substituting with tests doubles.

[3] Thanks Alfredo Casado for detecting that problem in the first version of the post.

[4] From Growing Object-Oriented Software, Guided by Tests > Chapter 6, Object-Oriented Style > Object Peer Stereotypes, page 52. You can also read about these stereotypes in a post by Steve Freeman: Object Collaboration Stereotypes.

[5] Difficulties in testing might be a hint of design problems. Have a look at this interesting series of posts about listening to the tests by Steve Freeman.

[6] According to Nat Pryce mocks were designed as a feedback tool for designing OO code following the 'Tell, Don't Ask' principle: "In my opinion it's better to focus on the benefits of different design styles in different contexts (there are usually many in the same system) and what that implies for modularisation and inter-module interfaces. Different design styles have different techniques that are most applicable for test-driving code written in those styles, and there are different tools that help you with those techniques. Those tools should give useful feedback about the external and *internal* quality of the system so that programmers can 'listen to the tests'. That's what we -- with the help of many vocal users over many years -- designed jMock to do for 'Tell, Don't Ask' object-oriented design." (from a conversation in Growing Object-Oriented Software Google Group).

I think that if your design follows a different OO style, it might be preferable to stick to a classical TDD style which nearly limits the use of test doubles only to infrastructure and undesirable side-effects.

The curious case of the negative builder

2019-05-24T07:00:00+00:00

Introduction.

Recently, one of the teams I’m coaching at my current client, asked me to help them with a problem, they were experiencing while using TDD to add and validate new mandatory query string parameters^[1]. This is a shortened version (validating fewer parameters than the original code) of the tests they were having problems with:

and this is the implementation of the QueryStringBuilder used in this test:

which is a builder with a fluid interface that follows to the letter a typical implementation of the pattern. There are even libraries that help you to automatically create this kind of builders^[2].

The problem.

In this particular case, however, implementing the QueryStringBuilder following this typical recipe causes a lot of problems. Looking at the test code, you may see why.

To add a new mandatory parameter, for example sourceId, following the TDD cycle, you would first write a new test asserting that a query string lacking the parameter should not be valid.

So far so good, the problem comes when you change the production code to make this test pass, in that moment you’ll see how the first test that was asserting that a query string with all the parameters was valid starts to fail (if you check the query string of that tests and the one in the new test, you’ll see how they are the same). Not only that, all the previous tests that were asserting that a query string was invalid because a given parameter was lacking won’t be “true” anymore because after this change they could fail for more than one reason.

So to carry on, you’d need to fix the first test and also change all the previous ones so that they fail again only for the reason described in the test name:

That’s a lot of rework on the tests only for adding a new parameter, and the team had to add many more. The typical implementation of a builder was not helping them.

The "negative builder".

The problem we’ve just explained can be avoided by chosing a default value that creates a valid query string and what I call “a negative builder”, a builder with methods that remove parts instead of adding them. So we refactored together the initial version of the tests and the builder, until we got to this new version of the tests:

which used a “negative” QueryStringBuilder:

After this refactoring, to add the sourceId we wrote this test instead:

which only carries with it updating the valid method in QueryStringBuilder and adding a method that removes the sourceId parameter from a valid query string.

Now when we changed the code to make this last test pass, no other test failed or started to have descriptions that were not true anymore.

Conclusions.

Leaving behind the typical recipe and adapting the idea of the builder pattern to the context of the problem at hand, led us to a curious implementation, a “negative builder”, that made the tests easier to maintain and improved our TDD flow.

Acknowledgements.

Many thanks to my Codesai colleagues Antonio de la Torre and Fran Reyes, and to all the colleagues of the Prime Services Team at LIFULL Connect for all the mobs we enjoy together. Thanks also to Markus Spiske for the photo used in this post and to Pexels.

Footnotes:

[1] Currently, this validation is not done in the controller anymore. The code showed above belongs to a very early stage of an API we're developing.

[2] Have a look, for instance, at lombok's' @Builder annotation for Java.

CAS 2018: Una vida descubriendo Agile

2019-05-23T06:00:00+00:00

“Una vida descubriendo Agile” es el título de la charla que di en la pasada CAS2018 en Alicante.

El vídeo ya está disponible desde hace tiempo (gracias Autentia!), y desde que salió, tenía ganas de hacer este post de “cómo se hizo”.

¿Cómo surgió la idea?

Por motivo de la inauguración de las nuevas oficinas de Sngular en Oviedo el pasado 21 de junio, tuve el honor de que me propusieran para dar la charla inaugural del evento, como representante de la comunidad y como organizador del grupo Agile Asturias. Sentía la relevancia del momento, así que pensé que una charla muy técnica sobre dinámicas o retrospectivas iba a ser poco inspiradora, tenía que ser algo con un poco más de alma.

En ese momento se cumplían casi dos años de mi vuelta a Oviedo, en el que al cierre de un ciclo, se le unía dar las gracias a Madrid, así que necesitaba sentarme a recordar y concretar en algo tangible todas esas experiencias que me marcaron.

Al empezar a hacerlo observé que había un paralelismo entre mi vida profesional y el descubrimiento del mundo del agilismo, así que busqué momentos concretos de mi vida, que a la vez que interesantes en lo autobiográfico, fueran mostrando principios, valores o prácticas ágiles. Sobre todo detalles en los que se pudiera ver reflejado un oyente en su propia experiencia.

Primera iteración

Me quedé bastante contento de cómo fue la charla en Sngular, tanto por el contenido, como por el ‘delivery’, me sentí muy cómodo en el ambiente que se creó. Si tenéis curiosdad podéis ver el vídeo aquí.

Pero lo más importante… ¡ya tenía tema para la CAS! Y lo mejor, ¡la presenté y me la aceptaron! \o/

Y como no es muy habitual tener ya el trabajo hecho, ya que tenía tiempo, pedí feedback a algunos amigos. Entre los que me contestaron estaba José Manuel Beas, para el que dar un feedback trabajado es norma, me comentó que podría darle la estructura del Viaje del Héroe.

Y efectivamente estudiando sobre ella encajaba como un guante. Así que reordené algunos eventos y reforcé algo la épica y el drama de ciertos momentos de la historia para hacerla más atractiva.

CAS 2018

Empezamos!! #CAS2018 pic.twitter.com/4XygBVqFt5
— Toño de la Torre (@adelatorrefoss) December 13, 2018

Y llegó la CAS. Estaba bastante nervioso, así que no me centré demasiado en ninguna charla durante la jornada. A diferencia de otras ocasiones no buscaba tanto la información precisa, si no el clima adecuado para la historia tan personal que quería contar.

Empecé mi charla buscando la complicidad del público, invitándoles más a escuchar que a tomar notas, a que me acompañasen en el viaje. Y creo que funcionó, me sentí muy a gusto desde el primer momento.

Pero no me imaginaba que iba a tener un un ayudante inesperado. ¡El proyector se quemó en mitad de la exposición!

Mientras intentaba continuar, pidiendo a la gente que se quedase conmigo, veía a los técnicos entrar y salir intentando solucionar el problema.

Olé la capacidad de improvisación de @adelatorrefoss ante la adversidad técnica 🔝#CAS2018 #Keepitreal #keepcalm 💆🏻‍♂️ pic.twitter.com/YkzTogDMDW
— Laura Azcona (@lauraazcona) December 13, 2018

Cuando ya vinieron a informar que no había remedio, hubo un fugaz momento que pensé en cancelar. Pero enseguida decidí que había que seguir, porque aunque las imágenes eran interesantes, era mucho más relevante toda la emoción que había volcado en mi pequeña historia y quería tranmitirla.

Así que solventamos el problema dando la vuelta al portátil y pidiendo a la gente que ocupase las primeras filas de la sala.

@adelatorrefoss luchando contra el entorno y abriéndose a la audiencia como un campeón. ¡Enhorabuena Toño!
Veníamos sobre todo a escuchar tu experiencia, aunque las fotos fueran chulas. #CAS2018 pic.twitter.com/hMmaJlaPhY
— Enrique de la Cruz Martínez (@encrumar) December 13, 2018

Así terminó la charla, como dice Enrique en este tweet, desnudándome (un poco) ante los asistentes y con una sensación muy agradable de haber compartido mi camino en un ambiente de confianza.

Gracias por el feedback! #CAS2018 pic.twitter.com/lxNd9MCu7K
— Toño de la Torre (@adelatorrefoss) December 13, 2018

El feedback fue muy bueno, tanto el que dejaron en la urna, como el que me fueron dando el resto del día y todo el día siguiente: Bastantes personas se acercaron a felicitarme por la charla y por superar con aparente naturalidad el problema del proyector; y lo más valioso para mi, compartir que se vieron identificadas en algunas partes del relato.

Así que quedé muy satisfecho con el trabajo de recordar 14 años de mi vida, con transparencia y honestidad de los momentos buenos y no tan buenos, en el que he podido volver a agradecer a varias personas allí presentes lo importantes que fueron en mi vida.

¡Gracias!

Referencias

Fotos oficiales de la CAS2018

Más sobre el Monomito o El viaje del héroe contado por Juan Gómez-Jurado: TODOPODEROSOS #15: Star Wars y los chorizos parrilleros (Star Wars, Vol I)

Killing mutants to improve your tests

2019-05-14T07:00:00+00:00

At my current client we’re working on having a frontend architecture for writing SPAs in JavaScript similar to re-frame’s one: an event-driven bus with effects and coeffects for state management^[1] (commands) and subscriptions using reselect’s selectors (queries).

One of the pieces we have developed to achieved that goal is reffects-store. Using this store, React components can be subscribed to given reselect’s selectors, so that they only render when the values in the application state tracked by the selectors change.

After we finished writing the code for the store, we decided to use mutation testing to evaluate the quality of our tests. Mutation testing is a technique in which, you introduce bugs, (mutations), into your production code, and then run your tests for each mutation. If your tests fail, it’s ok, the mutation was “killed”, that means that they were able to defend you against the regression caused by the mutation. If they don’t, it means your tests are not defending you against that regression. The higher the percentage of mutations killed, the more effective your tests are.

There are tools that do this automatically, stryker ^[2] is one of them. When you run stryker, it will create many mutant versions of your production code, and run your tests for each mutant (that’s how mutations are called in stryker’s’ documentation) version of the code. If your tests fail then the mutant is killed. If your tests passed, the mutant survived. Let’s have a look at the the result of runnning stryker against reffects-store’s code:

Notice how stryker shows the details of every mutation that survived our tests, and look at the summary the it produces at the end of the process.

All the surviving mutants were produced by mutations to the store.js file. Having a closer look to the mutations in stryker’s output we found that the functions with mutant code were unsubscribeAllListeners and unsubscribeListener. After a quick check of their tests, it was esay to find out why unsubscribeAllListeners was having surviving mutants. Since it was a function we used only in tests for cleaning the state after each test case was run, we had forgotten to test it.

However, finding out why unsubscribeListener mutants were surviving took us a bit more time and thinking. Let’s have a look at the tests that were exercising the code used to subscribe and unsubscribe listeners of state changes:

If we examine the mutations and the tests, we can see that the tests for unsubscribeListener are not good enough. They are throwing an exception from the subscribed function we unsubscribe, so that if the unsubscribeListener function doesn’t work and that function is called the test fails. Unfortunately, the test passes also if that function is never called for any reason. In fact, most of the surviving mutants that stryker found above have are variations on that idea.

A better way to test unsubscribeListener is using spies to verify that subscribed functions are called and unsubscribed functions are not (this version of the tests includes also a test for unsubscribeAllListeners):

After this change, when we run stryker we got the following output:

No mutants survived!! This means this new version of the tests is more reliable and will protect us better from regressions than the initial version.

Mutation testing is a great tool to know if you can trust your tests. This is event more true when working with legacy code.

Acknowledgements.

Many thanks to Mario Sánchez and Alex Casajuana Martín for all the great time coding together, and thanks to Porapak Apichodilok for the photo used in this post and to Pexels.

Footnotes:

[1] See also reffects which is the synchronous event bus with effects and coeffects we wrote to manage the application state.

[2] The name of this tool comes from a fictional Marvel comics supervillain Willian Stryker who was obsessed with the eradication of all mutants.

The Beverages Prices Refactoring kata: a kata to practice refactoring away from an awful application of inheritance.

2019-04-07T07:00:00+00:00

I created the Beverages Prices Refactoring kata for the Deliberate Practice Program I’m running at Lifull Connect offices in Barcelona (previously Trovit). Its goal is to practice refactoring away from a bad usage of inheritance.

The code computes the price of the different beverages that are sold in a coffee house. There are some supplements that can be added to those beverages. Each supplement increases the price a bit. Not all combinations of drinks and supplements are possible.

Just having a quick look at the tests of the initial code would give you an idea of the kind of problems it might have:

If that’s not enough have a look at its inheritance hierarchy:

To make things worse, we are asked to add an optional cinnamon supplement that costs 0.05€ to all our existing catalog of beverages. We think we should refactor this code a bit before introducing the new feature.

We hope you have fun practicing refactoring with this kata.

Our experience at ClojureBridge Bilbao 2018

2019-03-23T07:00:00+00:00

ClojureBridge is an all-volunteer organization inspired by RailsBridge that provides free, introductory workshops to increase diversity in the Clojure community. I first learned about ClojureBridge thanks to a talk by Ali King at EuroClojure 2015 in Barcelona: ClojureBridge, Building a more diverse Clojure community. I really liked the idea and we (the Clojure Developers Barcelona) tried to organize one in Barcelona, but failed to actually do it because we lacked the numbers, money and time. So the moment I knew that my colleague at GreenPowerMonitor, Estíbaliz Rodríguez, and the company where she works, Magnet, were planning to organize a ClojureBridge edition in Bilbao for December 1st 2018, I decided to do my best to help.

I met Estíbaliz and José Ayudarte at the beginning of last summer, when they started working as ClojureScript developers for GreenPowerMonitor, and it’s been a great experience to work with them. They are part of Magnet which is a cooperative of developers, designers and consultants that work with Clojure and ClojureScript. Magnet’s team is distributed across Europe but most of them live in the Basque country.

I told them I’d like to participate as a volunteer. Actually I had already bought the tickets and booked an accommodation for that weekend before asking them. In the worst-case scenario, if I couldn’t participate in ClojureBridge, I’d at least spend a weekend in Bilbao which is a wonderful city. In the end, everything went well and they told me they were delighted to have me there. I participated in a couple of meetings to know the other volunteers and talk about how the event would be structured, the mentoring and the exercises. Magnet was sponsoring the event and most of its team worked very hard to make it possible.

So, on December 1st I was there trying to help people learn a bit of Clojure. There were many women and girls with very diverse backgrounds: professional developers that were using other languages, teenagers with a bit of programming experience from school or without, little girls and women of all ages that had no programming experience. At the beginning, Usoa Sasigain gave a talk to introduce the clojureBridge aim of increasing diversity in technology, the important role women have played in the history of computer science and technology, and Clojure. She also talked about her personal history with technology and Clojure, and explained how technology might be a nice career option for women.

After the introduction, the participants were splitted in groups according to their programming experience. I was assigned to help the group of experienced software developers. They worked through the exercises in Maria Cloud which is a beginner-friendly coding environment for Clojure and I answered to questions about Clojure and helped when they got stuck. I think they got to appreciate Clojure and the possibilities it offers. We did several coffee breaks during the morning and for lunch in which we could talk about many things and I had the opportunity to meet Asier Galdós, Amaia Guridi, Iván Perdomo and other members of Magnet. The lunch was very nice and sponsored by Magnet.

At the end of the first half of the event, some attendees had to go to have lunch with their families. A funny and lovely anecdote for me happened when two girls of about six or eight years old that had been enthusiastically programming all the morning didn’t want to stop and leave with their parents for lunch. I remember with a lot of tenderness seeing them totally engrossed in programming during the morning and celebrating with raised arms every time they succeeded in changing the color or any other feature of the shapes they were working with in Maria Cloud’s exercises.

During the afternoon, we continue working on more advanced Maria Cloud exercises. There were less people, so I changed to work with some women that had no previous experience with programming. It was a very nice experience and we had a good time going through some more Maria cloud’s exercises playing with shapes.

All in all, volunteering in ClojureBridge was a very beautiful experience for me. I enjoyed helping people to know Clojure and programming, and met many nice people with many different backgrounds. I learned several words in basque language. I also had some very interesting conversations with Asier, Usoa, José and Iván about Clojure, Magnet’s experience as a Clojure/ClojureScript cooperative and the interesting platform, Hydrogen, that they are building. We also talked about my doing a desk surfing with them, an idea that I was really excited about, but, unfortunately, I haven’t been able to do yet because I recently started working for a new client in Barcelona.

Before finishing I’d like to thank Magnet for making the first ClojureBridge in Spain possible and for letting me help. I’d also like to send love and good energy to Estíbaliz. I hope you recover soon and we can meet each other in Euskadi or somewhere else.

Charla Pyday Tenerife

2019-01-31T01:00:00+00:00

El pasado 17 de Noviembre tuvo lugar el PyDay Tenerife, un evento que reune a muchos amantes de este lenguaje. Pero no sólo se habla del lenguaje. El evento deja bastante espacio para otras cosas relacionadas con el lenguaje, lo que hace que la diversidad de temas sea amplia y eso se nota también en el público que asiste.

Con este panorama me animé a presentar una charla sobre TDD relacionada con mi reciente experiencia usando el lenguaje a pesar de no tener una gran experiencia con el mismo. Mi intención era aportar mi granito de arena a otras comunidades locales de las que habitualmente participo.

Aunque en la charla hay una introducción a TDD, la idea principal es hablar sobre la importancia de escuchar a los tests ( algo de lo que ya hablamos en este post ). Otro aspecto destacable son las pequeñas variaciones en el ciclo que son propuestos en el GOOS y que vertebran la charla.

A continuación les dejo la grabación de la charla.

Nota: Hay un pequeño problema de sincronización de imagen así que dejo las slides con la intención de ayudar a mejorar la experiencia.

Muchísimas gracias a la organización por hacer tan fácil la participación y crear un ambiente muy confortable. Espero participar en la siguiente edición.

Avoid using subscriptions only as app-state getters

2019-01-03T07:00:00+00:00

Introduction.

Subscriptions in re-frame or re-om are query functions that extract data from the app-state and provide it to view functions in the right format. When we use subscriptions well, they provide a lot of value^[1], because they avoid having to keep derived state the app-state and they dumb down the views, that end up being simple “data in, screen out” functions.

However, things are not that easy. When you start working with subscriptions, it might happen that you end up using them as mere getters of app-state. This is a missed opportunity because using subscriptions in this way, we won’t take advantage of all the value they can provide, and we run the risk of leaking pieces of untested logic into our views.

An example.

We’ll illustrate this problem with a small real example written with re-om subscriptions (in an app using re-frame subscriptions the problem would look similar). Have a look at this piece of view code in which some details have been elided for brevity sake:

this code is using subscriptions written in the horizon.domain.reports.dialogs.edit namespace.

The misuse of subscriptions we’d like to show appears on the following piece of the view:

Notice how the only thing that we need to render this piece of view is next-generation. To compute its value the code is using several subscriptions to get some values from the app-state and binding them to local vars (delay-unit start-at, delay-number and date-modes). Those values are then fed to a couple of private functions also defined in the view (get-next-generation and delay->interval) to obtain the value of next-generation.

This is a bad use of subscriptions. Remember subscriptions are query functions on app-state that, used well, help to make views as dumb (with no logic) as possible. If you push as much logic as possible into subscriptions, you might achieve views that are so dumb you nearly don’t need to test, and decide to limit your unit tests to do only subcutaneous testing of your SPA.

Refactoring: placing the logic in the right place.

We can refactor the code shown above to remove all the leaked logic from the view by writing only one subscription called next-generation which will produce the only information that the view needs. As a result both get-next-generation and delay->interval functions will get pushed into the logic behind the new next-generation subscription and dissappear from the view.

This is the resulting view code after this refactoring:

and this is the resulting pure logic of the new subscription. Notice that, since get-next-generation function wasn’t pure, we had to change it a bit to make it pure:

After this refactoring the view is much dumber. The previously leaked (an untested) logic in the view (the get-next-generation and delay->interval functions) has been removed from it. Now that logic can be easyly tested through the new next-generation subscription. This design is also much better than the previous one because it hides how we obtain the data that the view needs: now both the view and the tests ignore, and so are not coupled, to how the data the view needs is obtained. We might refactor both the app-state and the logic now in get-next-generation and delay->interval functions without affecting the view. This is another example of how what is more stable than how.

Summary

The idea to remember is that subscriptions by themselves don’t make code more testable and maintainable. It’s the way we use subscriptions that produces better code. For that the logic must be in the right place which is not inside the view but behind the subscriptions that provide the data that the view needs. If we keep writing “getter” subscriptions” and placing logic in views, we won’t gain all the advantages the subscriptions concept provides and we’ll write poorly designed views coupled to leaked bunches of (very likely untested) logic.

Acknowledgements.

Many thanks to André Stylianos Ramos and Fran Reyes for giving us great feedback to improve this post and for all the interesting conversations.

Footnotes:

[1] Subscriptions also make it easier to share code between different views and, in the case of re-frame (and soon re-om as well), they are optimized to minimize unnecessary rerenderings of the views and de-duplicate computations.

Eventos como la Software Crafters Barcelona 2018

2018-11-05T20:00:00+00:00

El sábado 15 de Septiembre por la noche aterrizaba en Madrid después de haber pasado más de un año viviendo fuera, muy lejos allá en tierras niponas. Y no era sino dos semanas más tarde que iba a asistir a la Software Crafters Barcelona, pues había conseguido pillarme de antemano (y con suerte :) una entrada.
Había sido un año complicado profesionalmente hablando, con no mucho tiempo libre y un proyecto complejo durante el cual conseguimos superar, no sin dificultad, algunas situaciones delicadas, todo ello mientras estaba 100% remoto en una zona horaria diferente trabajando de noche con el horario al revés. Me hallaba en una etapa en la que no me apetecía apenas dedicarle tiempo al desarrollo fuera del horario de trabajo, y quería darle la vuelta a la tortilla una vez pusiese pie en España de nuevo. Qué mejor manera que asistir a uno de los mayores eventos de Software Crafters?

Cuando me planteé por primera vez ir a una conferencia lo que me venía a la mente era una serie de charlas interesantes, impartidas por personas muy cualificadas, y una oportunidad de conocerlas e intercambiar un par de preguntas. Con esa idea asistí a la CAS 2015 y me encontré con lo que esperaba y algo más. Ese algo más se fue potenciando según asistía a diversos eventos por España llegando hasta la SCBCN 18, y ha pasado a ser el otro gran pro de los eventos.

El valor que no logré visualizar en mi inicio no es sino el más importante: las personas que conforman la comunidad. Haciendo reflexión, creo que es un poco difícil de imaginar hasta que se experimenta.
Es la primera vez, y de no conocer a prácticamente nadie según pones un pie en el recinto, sales al cabo de un par de días habiendo intercambiado opiniones y experiencias con todo un abanico de personas. En este punto quisiera enfatizar el valor de dar un paso adelante y hablar con quien no conoces, pero no importa si al inicio los nervios te pueden. Si sigues participando, aunque sea poco a poco irás sintiéndote cada vez más miembro de esta comunidad, y luego resulta que un buen día te das un salto por otra ciudad y quedas para participar en un evento de la comunidad local, o te ves para tomar unas cervezas y ponerte al día. En ocasiones tienes la suerte de conocer a personas muy afines y en un sólo evento ya habréis logrado forjar una buena amistad.

La Software Crafters Barcelona no decepciona. Gracias a la organización por un evento muy sólido, sobretodo teniendo en cuenta la cantidad de personas, tracks y charlas, que no es nada fácil! Por darnos la oportunidad a todos los asistentes de impregnarnos de conocimiento a la par que nos reunimos con personas de ideas tan similares como diferentes a las propias. Este año me vi asistiendo a charlas como:

The Science of Not Estimating de Anemari Fiser y Javier Sánchez.
Dame tus tipos Pegaso de Jorge Barroso.
Calisthenics, Smells, SOLID, Cohesion and Coupling Connecting the dots de Pedro Santos.

Y además en el Open Space a:

React Architecture con Gorka y Mikel de 540.
Object-Oriented Design Workshop de nuevo con Pedro Santos.
Y también participé junto con Antonio en la sesión de Let’s talk about Cooperativism propuesta por Ángel en la que quisieron contar con nuestro punto de vista con respecto a las ideas que hay detrás de haber montado una Cooperativa.

Pero he de decir que también me salté otras tantas charlas por quedarme a hablar con una persona u otra. Las charlas pueden aportar una gran motivación a nivel técnico, pero considero que también hace falta un buen grado de motivación personal y que sin ello es difícil ponerse en marcha. Ahí es donde la comunidad que organiza y asiste a un evento se hace notar y es lo que me lleva al punto que intento expresar.
Desde un debate técnico, a un intercambio de opiniones sobre cualquier tema y el cómo te va la vida, o en mi caso en esta ocasión ¿qué ha sido de ti en Japón? Son el inamovible complemento que considero distingue a un evento, por contar con personas con objetivos parecidos y mentalidades similares a las propias, que te permiten resurgir con mucha más energía una vez finalizado que cuando cruzaste la entrada el primer día.

Doy fe de que tenemos una comunidad genial en España!
Muchas gracias!

Giving new life to existing Om legacy SPAs with re-om

2018-10-02T21:00:00+00:00

Introduction.

We’re pleased to announce that our client GreenPowerMonitor has allowed us to open-source re-om, an event-driven functional framework which is giving new life to an existing legacy SPA that uses Om.

Why re-om?

1. The problem with our SPA: imperative programming everywhere.

We are working on a legacy ClojureScript SPA, called horizon, that uses Om.

This SPA might have had some kind of architecture in some moment in the past but technical debt, lack of documentation and design flaws had blurred it. Business logic (in this case, pure logic that decides how to interact with the user or data transformations) and effectful code were not clearly separated.

This lack of separation of concerns was making the SPA hard to evolve because its code was difficult to understand and to test. This resulted in a very low test coverage that amplified even more the problems to evolve the code safely and at a sustainable pace. This was generating a vicious circle.

Even more, conflating pure and effectful code destroys the advantages of functional programming. It doesn’t matter that we’re using a language like Clojure, without clear isolation between pure and effectful code, you’ll end up doing imperative programming.

2. A possible solution: effects and coeffects.

Using effects and coeffects is a way of getting the separation of concerns we were lacking. They help achieve a clear isolation of effectful code and business logic that makes the interesting logic pure and, as such, really easy to test and reason about. With them we can really enjoy the advantages of functional programming.

Any piece of logic using a design based on effects and coeffects is comprised of three parts:

Extracting all the needed data from “the world” (using coeffects for getting application state, getting component state, getting DOM state, etc).
Using pure functions to compute the description of the side effects to be performed (returning effects for updating application state, sending messages, etc) given what was extracted from “the world” in the previous step (the coeffects).
Performing the side effects described by the effects returned by the pure functions executed in the previous step.

At the beginning, when re-om wasn’t yet accepted by everyone in the team, we used coeffects and effects which were being manually created to improve some parts of the SPA, (have a look at Improving legacy Om code (I) and Improving legacy Om code (II)), but this can get cumbersome quickly.

3. An event-driven framework with effects and coeffects: re-frame.

Some of us had worked with effects and coeffects before while developing SPAs with re-frame and had experienced how good it is. After working with re-frame, when you come to horizon, you realize how a good architecture can make a dramatic difference in clarity, testability, understandability and easiness of change.

Having a framework like re-frame removes most of the boilerplate of working with effects and coeffects, creating clear boundaries and constraints that separate pure code from effectful code and gives you a very clear flow to add new functionality that’s very easy to test and protect from regressions. In that sense re-frame’s architecture can be considered what Jeff Atwood defined as a pit of success because it is:

“a design that makes it easy to do the right things and annoying (but not impossible) to do the wrong things.”

4. Why not use re-frame then?

In principle using re-frame in our SPA would have been wonderful, but in practice this was never really an option.

A very important premise for us was that a rewrite was out of the question because we would have been blocked from producing any new feature for too long. We needed to continue developing new features. So we decided we would follow the strangler application pattern, an approach which would allow us to progressively evolve our SPA to use an architecture like re-frame’s one, while being able to keep adding new features all the time. The idea is that all new code would use the new architecture, if it were pragmatically possible, and that we would only change bit by bit those legacy parts that needed to change. This means that during a, probably long, period of time inside the SPA, the new architecture would have to coexist with the old imperative way of coding.

Even though, following the strangler application pattern was not incompatible with introducing re-frame, there were more things to consider. Let’s examine more closely what starting to use re-frame would have meant to us:

4. 1. From Om to reagent.

re-frame uses reagent as its interface to React. Although I personally consider reagent to be much nicer than Om because it feels more ‘Clojurish’, as it is less verbose and hides React’s complexity better that Om (Om it’s a thinner abstraction over React that reagent), the amount of view code and components developed using Om during the nearly two years of life of the project made changing to reagent too huge of a change. GreenPowerMonitor had done a heavy investment on Om in our SPA for this change to be advisable.

If we had chosen to start using re-frame, we would have faced a huge amount of work. Even following a strangler application pattern, it would have taken quite some time to abandon Om, and in the meantime Om and reagent would have had to coexist in our code base. This coexistence would have been problematic because we’d have had to either rewrite some components or add complicated wrapping to reuse Om components from reagent ones. It would have also forced our developers to learn and develop with both technologies.

Those reasons made us abandon the idea of using re-frame, and chose a less risky and progressive way to get our real goal, which was having the advantages of re-frame’s architecture in our code.

5. re-om is born.

André and I decided to do a spike to write an event-driven framework using effects and coeffects. After having a look at re-frame’s code it turned out it wouldn’t be too big of an undertaking. Once we had it done, we called it re-om as a joke.

At the beginning we had only events with effects and coeffects and started to try it in our code. From the very beginning we saw great improvements in testability and understandability of the code. This original code that was independent of any view technology was improved during several months of use. Most of this code ended being part of reffectory.

Later our colleague Joel Sánchez added subscriptions to re-om. This radically changed the way we approach the development of components. They started to become dumb view code with nearly no logic inside, which started to make cumbersome component integration testing nearly unnecessary. Another surprising effect of using re-om was that we were also able to have less and less state inside controls which made things like validations or transformation of the state of controls comprised of other controls much easier.

A really important characteristic of re-om is that it’s not invasive. Since it was thought from the very beginning to retrofit a legacy SPA to start using an event-driven architecture with an effects and coeffects system, it’s ideal when you want to evolve a code base gradually following a strangler application pattern. The only thing we need to do is initialize re-om passing horizon’s app-state atom. From then on, re-om subscriptions will detect any changes made by the legacy imperative code to re-render the components subscribed to them, and it’ll also be able to use effect handlers we wrote on top of it to mutate the app-state using horizon’s lenses and do other effects that “talk” to the legacy part.

This way we could start carving islands of pure functional code inside our SPA’s imperative soup, and introduced some sanity to make its development more sustainable.

re-om & reffectory

We’ve been using re-om during the last 6 months and it has really made our lives much easier. Before open-sourcing it, we decided to extract from re-om the code that was independent of any view technology. This code is now part of reffectory and it might be used as the base for creating frameworks similar to re-om for other view technologies, like for example rum, or even for pure Clojure projects.

Acknowledgements.

We’d like to thank GreenPowerMonitor for open-sourcing re-om and reffectory, all our colleagues at GreenPowerMonitor, and the ones that are now in other companies like André and Joel, for using it, giving feedback and contributing to improve it during all this time. We’d also love to thank the re-frame project, which we think is a really wonderful way of writing SPAs and on which we’ve heavily inspired re-om.

Give it a try.

Please do have a look and try re-om and reffectory. We hope they might be as useful to you as they have been for us.

Cursos en abierto en Canarias

2018-09-04T07:00:00+00:00

En la primera mitad de este año no habíamos podido hacer ningún curso de TDD en abierto. Nos absorbió el trabajo diario, la agenda de eventos en los que participamos, y todas las reuniones, decisiones y papeleos que tuvimos para lanzar nuestra cooperativa. Era una pena porque nos encanta hacer cursos en abierto por el entusiasmo y las ganas de trabajar y de aprender con las que vienen las personas que asisten a ellos. Para nosotros estos cursos son también muy interesantes porque nos permiten conocer a personas, que, en ocasiones, acaban colaborando con Codesai. Ese fue, por ejemplo, mi caso o el de Luis.

Por eso, justo después de constituir la cooperativa, Fran y yo decidimos liarnos la manta a la cabeza y anunciar que haríamos un curso en abierto en Tenerife un mes después, a mitad de Julio, justo antes del comienzo de las vacaciones para muchos. Teníamos muy poco tiempo para anunciarlo, pero era una oportunidad muy buena para empezar a movernos como cooperativa y para seguir refinando el nuevo material que ya habíamos usado en los cursos de TDD que hemos hecho este año en Merkle y Gradiant. Una vez empezamos a organizarlo, pensé que podría dar otro curso en Gran Canaria con Ronny para aprovechar el viaje. Con lo que al final dimos dos cursos en abierto en una semana: el 9 y 10 de Julio en Las Palmas de Gran Canaria y el 12 y 13 de Julio en Santa Cruz de Tenerife.

Al curso de Gran Canaria vinieron seis personas. La mayoría de ellas trabajaban en AIDA, una empresa con la que trabajamos durante muchos años y con la que tenemos una relación muy cercana. El curso fue intenso porque el nivel de conocimiento de las personas que vinieron era muy dispar. Trabajamos mucho con las parejas durante los ejercicios prácticos e incluso hicimos una sesión extra una semana después en las oficinas de AIDA en la que terminamos de hacer el último ejercicio del curso. Ronny y yo acabamos muy satisfechos y recibimos muy buen feedback de los asistentes, tanto en persona, como en los formularios para dejar tu opinión de forma anónima que siempre suelo enviar unas semanas después. El curso nos sirvió también para experimentar con algunas nuevas secciones sobre cómo usar dobles de prueba de forma sostenible, y sacamos bastante información para aplicar en próximos cursos.

Al día siguiente volé a Tenerife, donde me esperaba Fran en el aeropuerto, y nos fuimos a su casa donde hicimos los últimos preparativos, y descansamos hasta el día siguiente en que empezaba el curso. Al curso de Tenerife asistieron siete personas que venían de diferentes empresas. La gran mayoría eran personas que habían sido antiguos compañeros de Fran, entre ellos, algunos de sus antiguos mentores, por lo que fue un curso muy especial para él. Yo también disfruté mucho. En este curso el nivel de los asistentes era bastante alto y salieron debates muy interesantes. De nuevo recibimos muy buen feedback al terminar.

Una novedad de estos cursos fue que ofrecimos por primera vez un descuento del 50% para colectivos poco representados en la tecnología. Este descuento es algo que hemos decidido ofrecer de ahora en adelante en nuestros cursos en abierto.

Viendo los cursos en perspectiva después de unos meses, creo que aprendimos varias cosas:

Un mes es muy poco tiempo para promocionar un curso (cómo no ㋡), sobre todo en un mercado tan pequeño como Canarias. Sólo gracias a nuestra red de contactos y a empresas con las que ya habíamos trabajado en el pasado individualmente o como Codesai pudimos conseguir gente suficiente para hacer el curso rentable.
El nuevo material está funcionando bastante bien. Estamos consiguiendo mantener el nivel de satisfacción que había con el curso anterior, al mismo tiempo que estamos pudiendo profundizar en temas que el material anterior no tocaba o lo hacía de forma muy superficial.
Los canales de comunicación que usamos habitualmente para promocionar nuestros cursos, Twitter y LinkedIn no fueron suficiente para atraer a personas de colectivos poco representados en la tecnología. Sólo dos asistentes aprovecharon el descuento del 50%. Tenemos que buscar otras formas de llegar a estas personas. De hecho, si lees esto y conoces a gente a la que le pudiese interesar, por favor, corre la voz.

Personalmente me alegro mucho de haber decidido mover estos cursos, porque he conocido a gente muy interesante y muy agradable con la que espero seguir en contacto, ¡muchas gracias a todos!, por la satisfacción del trabajo en sí mismo, y por los buenos ratos y conversaciones que tuve con mis compañeros Ronny y Fran. Esto es algo que es muy valioso e importante porque al estar distribuidos en diferentes regiones (e incluso países) y trabajar en diferentes clientes se echa de menos el contacto humano con los compañeros. Por eso cada curso y/o cada consultoría presencial que hacemos en pareja es una gran oportunidad para reforzar la relación que nos une. Ronny, Fran, muchísimas gracias por la acogida y todos los buenos ratos.

Antes de terminar quería dar las gracias a Manuel Tordesillas por el gran trabajo que hizo preparando todas las katas del curso en C#.

PS: Nuestro próximo curso en abierto de TDD será el 18 y 19 de Octubre en Barcelona, y de nuevo haremos un descuento del 50% para colectivos poco representados en la tecnología. Corre la voz ㋡

Gradiant, mi primer Curso de TDD

2018-08-20T06:00:00+00:00

A principios del pasado Junio volvimos a las oficinas de Gradiant en Vigo para impartir nuestro Curso de TDD. Gradiant es el acrónimo en inglés del Centro Tecnolóxico de Telecomunicacións de Galicia (Galician Research and Development Center in Advanced Telecommunications). Este centro aplica los conocimientos y experiencia de sus profesionales de investigación para aportar valor a empresas y organizaciones mediante la transferencia de conocimiento y el diseño de productos especializados.

Además el campus en el que se encuentran sus oficinas está en medio del bosque, y tienen una vista preciosa desde las oficinas. Seguro que compensa el extra de tiempo de desplazamiento.

Nos hizo muchísima ilusión cuando nos llamaron para impartir el curso, no sólo porque volvieran a confiar en Codesai para formar a sus desarrolladores, sino también, porque recordamos con mucho cariño el curso de TDD que impartimos allí a finales de 2016, de la mano de Manu Rivero y Luis Rovirosa.

En esta ocasión impartimos el curso Manu Rivero y yo. Nos gusta impartir nuestros cursos en pareja siempre que podemos porque creemos que el nivel de atención que reciben las parejas durante las sesiones prácticas es mucho mejor. Además dar cursos juntos es una gran oportunidad para trabajar presencialmente y compartir experiencias con compañeros que trabajan normalmente en proyectos diferentes.

Como habéis podido intuir del título del post, fue mi primer curso de TDD. No soy novato dando formaciones y no me es extraño enfrentarme a esa situación en la que te observa una clase, pero hasta ahora no había tenido la oportunidad de dar nuestro curso de TDD.

Como os podéis imaginar dar una formación no es llegar allí el primer día y leer las transparencias. El trabajo que lleva detrás es importante, incluso sorprende, porque este tipo de cursos no tienen una gran carga teórica, son muy prácticos. Pero no se trata de prepararse la teoría únicamente, pues en conjunto es muy poco tiempo, sino, sobre todo de hacer previamente varias veces cada uno de los ejercicios, identificar los puntos de mayor dificultad, discutir las posibles soluciones, y extraer las lecciones de cada uno de ellos.

Esas lecciones tienen que tener una base firme, porque no se trata solo de detectar que algo te huele mal, o intuir que por ahí van los tiros. Se trata de entender las razones por las que algo es una buena práctica o es una buena decisión de diseño. Profundizar en estos fundamentos y principios me resultó muy útil, no sólo para impartir esta formación, sino también para mi día a día en el trabajo.

Al final, preparar este curso nos ha llevado unas 8 semanas de trabajo, dedicando algunas horas, fuera de los proyectos en los que cada uno estamos trabajando.

Ya hablando más concretamente del curso, fue realmente bien. Disfruté mucho viendo trabajar al equipo en cada kata. Como ya pasó en el curso de 2016, la heterogeneidad de los asistentes era muy grande, debido a la gran variedad de proyectos, tecnologías y tipos de sistemas que se desarrollan en Gradiant, (C empotrado para procesado de señales o IOT, APIs REST con Java o node, análisis de datos con Scala, diversas aplicaciones en Java o C++, etc.). Esta diversidad hizo que surgieran conversaciones y debates muy interesantes durante el curso.

El nivel de los asistentes a este curso fue más alto que el que encontramos en el grupo del curso de Diciembre de 2016. Esto creo que se debe en gran parte a la gran labor que Fernando Vilas y sus compañeros llevan realizando durante estos últimos años en Gradiant (organizando katas, charlas, etc), y a la vibrante actividad de las comunidades de Vigo.

Se notaba que habían estado trabajando internamente, porque las bases eran sólidas y pasamos rápido sobre ellas, y esto nos permitió ir un paso más allá y poder trabajar más en profundidad los detalles de cada ejercicio.

Esto fue interesante tanto para ellos como para los formadores, ya que nos plantearon preguntas en las que muchas veces había varias respuestas posibles y había que pararse a profundizar un rato entre todos. Conversaciones que fácilmente se extendían a las pausas de los cafés.

Algunos de los temas que salieron en las charlas:

Usar métodos del código de producción en los tests
DRY vs WET (Write Explicit Tests).
Trabajo de la persona lejos del teclado.
Dobles de clases que no son nuestras
Crear interfaz del colaborador o no.
Equilibrio entre tests de integración vs Unitarios con Dobles.

Como bola extra, la tarde del jueves Fernando nos invitó a acercarnos a un evento de la comunidad de desarrollo de Vigo y me sorprendió lo bien organizada que está. Me contó que durante el año 2017 hubo tal explosión de grupos de desarrollo que vieron la necesidad de organizarse alrededor de lo que han llamado la Vigo Tech Alliance (www.vigotech.org), que si entráis en su página veréis que lo forman nada menos que 15 grupos de tecnología con un calendario tan activo que marea. Mucho que aprender y llevar a las comunidades de desarrollo que hay en Asturias, especialmente a Agile Asturias. (https://www.meetup.com/es-ES/Agile-Asturias/).

Tanto para Manu como para mi fue un gran placer volver a colaborar con Gradiant. Muchas gracias por confiar en nosotros de nuevo. Además darle las gracias especialmente a Fernando Vilas por toda su ayuda. Y por supuesto a Manu por compartir un par de días en un lugar tan fantástico como Vigo.

Data clumps, primitive obsession and hidden tuples

2018-08-15T04:00:00+00:00

During the writing of one of our posts about connascence some of us were discussing whether we could consider a data clump a form of Connascence of Meaning (CoM) or not. In the end, we agreed that data clumps are indeed a form of CoM and that introducing a class for the missing abstraction reduces their connascence to Connascence of Type (CoT).

I had wondered in the past why we use a similar refactoring to eliminate both primitive obsession and data clump smells. Thinking about them from the point of view of connascence has helped me a lot to understand why. It also gave me an alternative path to get to the same conclusion, in which a data clump gets basically reduced to an implicit form of primitive obsession. The reasoning is as follows:

The concept of primitive obsession might be extended to consider the collections that a given language offers as primitives. In such cases, encapsulating the collection reifies a new concept that might attract code that didn’t have where to “live” and thus was scattered all over. From the point of view of connascence, primitive obsession is a form of CoM that we transform into CoT by introducing a new type and then we might find Connascence of Algorithm (CoA) that we’d remove by moving the offending code inside the new type. The composing elements of a data clump only make sense when they go together. This means that they’re conceptually (but implicitly) grouped. In this sense a data clump could be seen as a “hidden or implicit tuple”.

Having this “hidden or implicit tuple” in mind is now easier to see how closely related the data clump and primitive obsession smells are. In this sense, when we refactor a data clump what we do is removing the data clump by encapsulating a collection which is its “hidden or implicit tuple”, inside a new class. Again, from the point of view of connascence, this encapsulation reduces CoM to CoT and might make evident some CoA that will make us move some behavior into the new class that becomes a value object.

This “hidden or implicit tuple” concept helped me to make more explicit the mental process that was leading me to end up doing very similar refactorings to remove both code smells. I think that CoM unifies both cases much more easily than relating the two smells. The fact that the collection (the grouping of the elements of a data clump) is implicit also makes it more difficult to recognize a data clump as CoM in the first place. That’s why I think that a data clump is a more implicit example of CoM than primitive obsession, and, thus, we might consider its CoM to be stronger than the one in primitive obsession.

Improving legacy Om code (II): Using effects and coeffects to isolate effectful code from pure code

2018-07-21T07:30:00+00:00

Introduction.

In a previous post, we applied the humble object pattern idea to avoid having to write end-to-end tests for the interesting logic of a hard to test legacy Om code, and managed to write cheaper unit tests instead. Then, we saw how those unit tests were far from ideal because they were highly coupled to implementation details, and how these problems were caused by a lack of separation of concerns in the code design.

In this post we’ll show a solution to those design problems using effects and coeffects that will make the interesting logic pure and, as such, really easy to test and reason about.

Refactoring to isolate side-effects and side-causes using effects and coeffects.

We refactored the code to isolate side-effects and side-causes from pure logic. This way, not only testing the logic got much easier (the logic would be in pure functions), but also, it made tests less coupled to implementation details. To achieve this we introduced the concepts of coeffects and effects.

The basic idea of the new design was:

Extracting all the needed data from globals (using coeffects for getting application state, getting component state, getting DOM state, etc).
Using pure functions to compute the description of the side effects to be performed (returning effects for updating application state, sending messages, etc) given what was extracted in the previous step (the coeffects).
Performing the side effects described by the effects returned by the called pure functions.

The main difference that the code of horizon.controls.widgets.tree.hierarchy presented after this refactoring was that the event handler functions were moved back into it again, and that they were using the process-all! and extract-all! functions that were used to perform the side-effects described by effects, and extract the values of the side-causes tracked by coeffects, respectively. The event handler functions are shown in the next snippet (to see the whole code click here):

Now all the logic in the companion namespace was comprised of pure functions, with neither asynchronous nor mutating code:

Thus, its tests became much simpler:

Notice how the pure functions receive a map of coeffects already containing all the extracted values they need from the “world” and they return a map with descriptions of the effects. This makes testing really much easier than before, and remove the need to use test doubles.

Notice also how the test code is now around 100 lines shorter. The main reason for this is that the new tests know much less about how the production code is implemented than the previous one. This made possible to remove some tests that, in the previous version of the code, were testing some branches that we were considering reachable when testing implementation details, but when considering the whole behaviour are actually unreachable.

Now let’s see the code that is extracting the values tracked by the coeffects:

which is using several implementations of the Coeffect protocol:

All the coeffects were created using factories to localize in only one place the “shape” of each type of coeffect. This indirection proved very useful when we decided to refactor the code that extracts the value of each coeffect to substitute its initial implementation as a conditional to its current implementation using polymorphism with a protocol.

These are the coeffects factories:

Now there was only one place where we needed to test side causes (using test doubles for some of them). These are the tests for extracting the coeffects values:

A very similar code is processing the side-effects described by effects:

which uses different effects implementing the Effect protocol:

that are created with the following factories:

Finally, these are the tests for processing the effects:

Summary.

We have seen how by using the concept of effects and coeffects, we were able to refactor our code to get a new design that isolates the effectful code from the pure code. This made testing our most interesting logic really easy because it became comprised of only pure functions.

The basic idea of the new design was:

Extracting all the needed data from globals (using coeffects for getting application state, getting component state, getting DOM state, etc).
Computing in pure functions the description of the side effects to be performed (returning effects for updating application state, sending messages, etc) given what it was extracted in the previous step (the coeffects).
Performing the side effects described by the effects returned by the called pure functions.

Since the time we did this refactoring, we have decided to go deeper in this way of designing code and we’re implementing a full effects & coeffects system inspired by re-frame.

Acknowledgements.

Many thanks to Francesc Guillén, Daniel Ojeda, André Stylianos Ramos, Ricard Osorio, Ángel Rojo, Antonio de la Torre, Fran Reyes, Miguel Ángel Viera and Manuel Tordesillas for giving me great feedback to improve this post and for all the interesting conversations.

Somos cooperativa

2018-07-17T07:00:00+00:00

Estamos muy contentos de anunciar que, tras varios meses de papeleos, por fín, somos una cooperativa. Era un paso que decidimos tomar en nuestro último Flejesai* en Febrero, y que nos parecía muy natural dada la manera en que ya intentábamos funcionar.

Desde el principio, en Codesai hemos intentado funcionar sin jerarquías, tomando decisiones de una manera horizontal y democrática, y tratando de ser fieles a nuestros principios. Para tomar decisiones tratamos primero de buscar un consenso, que si no conseguimos, resolvemos mediante votación.

Tomar decisiones de esta manera no es siempre sencillo. Por un lado, debido a la gran cantidad de puntos de vista, este proceso es más ruidoso de lo que suele ser en una empresa más jerárquica. Hay muchas conversaciones para buscar consenso y tomar decisiones. Por otro lado, a veces el grupo no decide lo que a algunas personas les gustaría. Esto lleva a algunas personas a pensar que la búsqueda de consenso no es una forma adecuada de tomar decisiones en una empresa.

El mayor número de puntos de vista y la cantidad de debate es algo que, al principio, choca cuando uno viene de empresas más tradicionales, pero a lo que uno puede acostumbrarse y con lo que aprende a vivir. Lo que (aparentemente) se pierde en rapidez de decisión, se gana en mayor sentido de pertenencia porque no somos engranajes en una máquina, sino que somos personas con capacidad de influencia y control sobre lo que hacemos como empresa. Por otro lado, aceptar las decisiones del grupo cuando no se toma la decisión que a uno le hubiera gustado, dejar atrás nuestras posiciones iniciales y nuestro ego, y apoyar lo que se ha decidido, exige una gran madurez como personas y como equipo. Además, esta forma de funcionar, requiere también un cambio de mentalidad: ya no somos empleados, ahora somos socios, lo que conlleva un rango de responsabilidades más amplio que el que muchos estábamos acostumbrados a tener o con el que nos sentimos cómodos.

La forma en que funcionamos no es ni mejor ni peor que la forma en que funcionan otras empresas. Son tan sólo las reglas del juego que hemos decidido darnos a nosotros mismos. Cada empresa hace lo que puede. Todas luchamos en contra de las probabilidades, muchas desaparecen después de un tiempo. Nadie puede asegurar que no sigamos el mismo destino, pero, por ahora, aquí seguimos, haciendo todo lo que podemos, con nuestras disfunciones y virtudes, con nuestros éxitos y fracasos, creciendo juntos y sobreviviendo siendo fieles a nuestros principios y valores. En cierta manera, creemos que el mero hecho de que sobrevivamos ya es disruptivo en sí mismo, porque puede servir como una narrativa alternativa** en la que un modelo de empresa de software diferente también puede ser viable.

Son muchos desafíos juntos. ¿Cómo los estamos resolviendo? Según se nos presentan y como buenamente podemos. No somos perfectos, pero con empatía y paciencia unos con otros vamos mejorando paulatinamente. Es un proceso de aprendizaje conjunto. Aunque reconocemos que aún somos un poco disfuncionales, coincidimos en que Codesai es uno de los grupos más fecundos en los que hemos trabajado.

En resumen, intentamos hacerlo lo mejor que podemos en cada momento, aprendiendo juntos y disfrutando del camino.

* Los Flejesais son encuentros presenciales que duran varios días que hacemos unas cuantas veces al año.
** En Hope in the Dark: Untold Histories, Wild Possibilities, Rebecca Solnit profundiza en la idea de la necesidad de disponer de narrativas alternativas a las habituales a la corriente general para inspirar y dar esperanza a más personas haciendo ver que hay más caminos posibles.

Improving legacy Om code (I): Adding a test harness

2018-07-07T07:30:00+00:00

Introduction.

I’m working at GreenPowerMonitor as part of a team developing a challenging SPA to monitor and manage renewable energy portfolios using ClojureScript. It’s a two years old Om application which contains a lot of legacy code. When I say legacy, I’m using Michael Feathers’ definition of legacy code as code without tests. This definition views legacy code from the perspective of code being difficult to evolve because of a lack of automated regression tests.

The legacy (untested) Om code.

Recently I had to face one of these legacy parts when I had to fix some bugs in the user interface that was presenting all the devices of a given energy facility in a hierarchy tree (devices might be comprised of other devices). This is the original legacy view code:

This code contains not only the layout of several components but also the logic to both conditionally render some parts of them and to respond to user interactions. This interesting logic is full of asynchronous and effectful code that is reading and updating the state of the components, extracting information from the DOM itself and reading and updating the global application state. All this makes this code very hard to test.

Humble Object pattern.

It’s very difficult to make component tests for non-component code like the one in this namespace, which makes writing end-to-end tests look like the only option.

However, following the idea of the humble object pattern, we might reduce the untested code to just the layout of the view. The humble object can be used when a code is too closely coupled to its environment to make it testable. To apply it, the interesting logic is extracted into a separate easy-to-test component that is decoupled from its environment.

In this case we extracted the interesting logic to a separate namespace, where we thoroughly tested it. With this we avoided writing the slower and more fragile end-to-end tests.

We wrote the tests using the test-doubles library (I’ve talked about it in a recent post) and some home-made tools that help testing asynchronous code based on core.async.

This is the logic we extracted:

and these are the tests we wrote for it:

See here how the view looks after this extraction. Using the humble object pattern, we managed to test the most important bits of logic with fast unit tests instead of end-to-end tests.

The real problem was the design.

We could have left the code as it was (in fact we did for a while), but its tests were highly coupled to implementation details and hard to write because its design was far from ideal. Even though, applying the humble object pattern idea, we had separated the important logic from the view, which allowed us to focus on writing tests with more ROI avoiding end-to-end tests, the extracted logic still contained many concerns. It was not only deciding how to interact with the user and what to render, but also mutating and reading state, getting data from global variables and from the DOM and making asynchronous calls. Its effectful parts were not isolated from its pure parts. This lack of separation of concerns made the code hard to test and hard to reason about, forcing us to use heavy tools: the test-doubles library and our async-test-tools assertion functions to be able to test the code.

Summary.

First, we applied the humble object pattern idea to manage to write unit tests for the interesting logic of a hard to test legacy Om view, instead of having to write more expensive end-to-end tests. Then, we saw how those unit tests were far from ideal because they were highly coupled to implementation details, and how these problems were caused by a lack of separation of concerns in the code design.

Next.

In a future post we’ll solve the lack of separation of concerns by using effects and coeffects to isolate the logic that decides how to interact with the user from all the effectful code. This new design will make the interesting logic pure and, as such, really easy to test and reason about.

Back at Merkle in 2018

2018-06-26T07:00:00+00:00

In the last quarter of 2017 we delivered several TDD trainings at Merkle’s offices in Barcelona and did several consulting session with their JavaScript and Java teams. Merkle is a company with high quality standards for the software they develop, so we were very happy when they contacted us to collaborate again this year doing several TDD trainings and consulting sessions.

So far we have done the first round of consulting sessions and the first of the TDD trainings. It was a very special one because it was the first test drive of our revamped training material. We have used the feedback from former training attendees to refine our TDD training material. We edited some parts that we thought were less valuable, and added new modules that reflects better the way we understand TDD at Codesai, so that the course is now more dynamic and easier to follow. We are looking forward to having the next consulting sessions and TDD trainings.

TDD training

We know that a two days introductory TDD training is not enough for a team to start doing TDD in a real environment. After the training, once the team returns to work, a lot of questions arise and the way to apply TDD is not always clear to them. In order to help Merkle’s teams in this process we are supplementing the TDD training with, on one hand, several rounds of consulting sessions in which we address together the difficulties that arise on the teams daily job, and, on the other hand, with one of the main novelties of this year’s collaboration with Merkle: a 4 months deliberate practice program. This program is aimed to improve the skills of a group of about 22 Merkle’s developers in object-oriented design, refactoring and TDD. We will give more details about it in a future post.

Deliberate Practice Program

Before finishing this post, we would love to thank Merkle (and especially Nelson Cardenas) for trusting us again to train their developers and help them grow their skills.

Socrates Canaries 2018

2018-06-14T09:00:00+00:00

This year, I had the pleasure to attend my second Socracan, an unconference organised in the Canary Islands that brings together people from the Craft Community. This conference had been organised in the past by the Software Crafters community in Canary Islands and most of the great groundwork done by them has been really helpful in. On this point I would like to give my personal perspective as an organiser jumping from the bench.

Thanks Rachel for the picture.

As I live away from the islands, I could not help with most of the preparations that took place before the event. I would like to thank my colleagues Dácil and Miguel for that. My objective was to be of support at the event and I have to say that apart from providing materials and setting a few things up I had not much else to do. That is something I did not expect and I believe that is one of the great things of this event.

When you have such a great facilitator as Adrian Perreau and such a great group of attendees, magic is there just waiting to happen and every moment lived with the group is a learning opportunity. I would like to thank Tobias Goeschel for helping with the Open Space rules, Jason Peper for always going the extra mile and publishing the program online, Rubén for becoming another backup organiser just like me and everyone else that attended because in the end, the community is what makes the event worth it :)

As with any event, not only the talks and workshops are the only opportunities for taking a learning pill back home. Conversations in the halls, on the beach, over dinner or over coffee are one of the reasons why I will be back next year. The quality of the talks was amazing and with many formats, there were roundtables to share experiences about remote working, creating a community with a culture of learning and how the movement can become more inclusive. Wolfram Kriesing presented us his experience in teaching TDD to kids taking away all the noise and boiling it down into a spreadsheet and Tobias made a great Event Storming express workshop.

Thanks Eddie for the picture.

But at Socracan there was also time for partying! Our colleague Dácil and her band Heisenberg rocked the stage in one of most iconic venues in the city. Thanks Carlos for organising it :)

As with any event, there were things that worked better than others. That is why we have written down all the feedback given during and after the event, and we are open to any suggestions for the next event. See you next year :)

Thanks Bernard for the picture.

Improve your reds

2018-06-08T09:00:00+00:00

Improving your reds is a simple tip that is described by Steve Freeman and Nat Pryce in their wonderful book Growing Object-Oriented Software, Guided by Tests.

It consists in a small variation to the TDD cycle in which you watch the error message of your failing test and ask yourself if the information it gives you would make it easier to diagnose the origin of the problem in case this error appears as a regression in the future. If the answer is no, you improve the error message before going on to make the test pass.

From Growing Object-Oriented Software by Nat Pryce and Steve Freeman.

Investing time in improving your reds will prove very useful for your colleagues and yourself because the clearer the error message, the better the context to fix the regression error effectively. Most of the times, applying this small variation to the TDD cycle only requires a small effort.

As a simple example, have a look at the following assertion and how it fails

assertThat(new Fraction(1,2).add(1), is(new Fraction(3,2)));

java.lang.AssertionError:
Expected: is <Fraction@2d8e8c3a>
     but: was <Fraction@2d8e84b8>

Why is it failing? Will this error message help us know what’s happening if we see it in the future?

The answer is clearly no, but with little effort, we can add a bit of code to make the error message clearer (implementing the toString() method).

@Override
public String toString() {
  return "Fraction{" +
    "numerator=" + numerator +
    ", denominator=" + denominator +
    '}';
}

java.lang.AssertionError:
Expected: is <Fraction{numerator=3, denominator=2}>
     but: was <Fraction{numerator=1, denominator=2}>

This error message is much clearer than the previous one and will help us to be more effective both while test-driving the code and if/when a regression error happens in the future, and we got this just by adding an implementation of toString() generated by our IDE.

Take that low hanging fruit. Start improving your reds!

A small spying and stubbing library for Clojure and ClojureScript: test-doubles

2018-04-21T21:30:00+00:00

As you may know from a previous post I’m working for GreenPowerMonitor as part of a team that is developing a challenging SPA to monitor and manage renewable energy portfolios using ClojureScript.

We were dealing with some legacy code that was effectful and needed to be tested using test doubles, so we explored some existing ClojureScript libraries but we didn't feel comfortable with them. On one hand, we found that some of them had different macros for different types of test doubles and this made tests that needed both spies and stubs become very nested. We wanted to produce tests with as little nesting as possible. On the other hand, being used to Gerard Meszaros’ vocabulary for tests doubles, we found the naming used for different types of tests doubles in some of the existing libraries a bit confusing. We wanted to stick to Gerard Meszaros’ vocabulary for tests doubles.

So we decided we'd write our own stubs and spies library.

We started by manually creating our own spies and stubs during some time so that we could identify the different ways in which we were going to use them. After a while, my colleague André Stylianos Ramos and I wrote our own small DSL to create stubs and spies using macros to remove all that duplication and boiler plate. The result was a small library that we've been using in our ClojureScript project for nearly a year and that we've recently adapted to make it work in Clojure as well:

I’m really glad to announce that GreenPowerMonitor has open-sourced our small spying and stubbing library for Clojure and ClojureScript: test-doubles.

In the following example written in ClojureScript, we show how we are using test-doubles to create two stubs (one with the :maps option and another with the :returns option) and a spy:

We could show you more examples here of how test-doubles can be used and the different options it provides, but we’ve already included a lot of explained examples in its documentation.

Please do have a look and try our library. You can get its last version from Clojars. We hope it might be as useful to you as it has been for us.

A small kata to explore and play with property-based testing

2018-04-11T11:30:00+00:00

1. Introduction.

I’ve been reading Fred Hebert’s wonderful PropEr Testing online book about property-based testing. So to play with it a bit, I did a small exercise. This is its description:

1. 1. The kata.

We’ll implement a function that can tell if two sequences are equal regardless of the order of their elements. The elements can be of any type.

We’ll use property-based testing (PBT). Use the PBT library of your language (bring it already installed). Follow these constraints:

You can’t use or compute frequencies of elements.

Work test first: write a test, then write the code to make that test pass.

If you get stuck, you can use example-based tests to drive the implementation on. However, at the end of the exercise, only property-based tests can remain.

Use mutation testing to check if you tests are good enough (we’ll do it manually injecting failures in the implementation code (by commenting or changing parts of it) and checking if the test are able to detect the failure to avoid using more libraries).

2. Driving a solution using both example-based and property-based tests.

I used Clojure and its test.check library (an implementation of QuickCheck) to do the exercise. I also used my favorite Clojure’s test framework: Brian Marick’s Midje which has a macro, forall, which makes it very easy to integrate property-based tests with Midje.

So I started to drive a solution using an example-based test (thanks to Clojure’s dynamic nature, I could use vectors of integers to write the tests.

which I made pass using the following implementation:

Then I wrote a property-based test that failed:

This is how the failure looked in Midje (test.check returns more output when a property fails, but Midje extracts and shows only the information it considers more useful):

the most useful piece of information for us in this failure message is the quick-check shrunken failing values. When a property-based testing library finds a counter-example for a property, it applies a shrinking algorithm which tries to reduce it to find a minimal counter-example that produces the same test failure. In this case, the [1 0] vector is the minimal counter-example found by the shrinking algorithm that makes this test fails.

Next I made the property-based test pass by refining the implementation a bit:

I didn’t know which property to write next, so I wrote a failing example-based test involving duplicate elements instead:

and refined the implementation to make it pass:

With this, the implementation was done (I chose a function that was easy to implement, so I could focus on thinking about properties).

3. Getting rid of example-based tests.

Then the next step was finding properties that could make the example-based tests redundant. I started by trying to remove the first example-based test. Since I didn’t know test.check’s generators and combinators library, I started exploring it on the REPL with the help of its API documentation and cheat sheet.

My sessions on the REPL to build generators bit by bit were a process of shallowly reading bits of documentation followed by trial and error. This tinkering sometimes lead to quick successes and most of the times to failures which lead to more deep and careful reading of the documentation, and more trial and error. In the end I managed to build the generators I wanted. The sample function was very useful during all the process to check what each part of the generator would generate.

For the sake of brevity I will show only summarized versions of my REPL sessions where everything seems easy and linear…

3. 1. First attempt: a partial success.

First, I wanted to create a generator that generated two different vectors of integers so that I could replace the example-based tests that were checking two different vectors. I used the list-distinct combinator to create it and the sample function to be able to see what the generator would generate:

I used this generator to write a new property which made it possible to remove the first example-based test but not the second one:

In principle, we might think that the new property should have been enough to also allow removing the last example-based test involving duplicate elements. A quick manual mutation test, after removing that example-based test, showed that it wasn’t enough: I commented the line (= (count s1) (count s2)) in the implementation and the property-based tests weren’t able to detect the regression.

This was due to the low probability of generating a pair of random vectors that were different because of having duplicate elements, which was what the commented line, (= (count s1) (count s2)), was in the implementation for. If we’d run the tests more times, we’d have finally won the lottery of generating a counter-example that would detect the regression. So we had to improve the generator in order to increase the probabilities, or, even better, make sure it’d be able to detect the regression.

In practice, we’d pragmatically combine example-based and property-based tests if we needed to. However, my goal was learning more about property-based testing, so I went on and tried to improve the generators (that’s why this exercise has the constraint of using only property-based tests).

3. 2. Second attempt: success!

So, I worked a bit more on the REPL with the goal of creating a generator that would always generate vectors with duplicate elements. For that I used test.check’s let macro, the tuple, such-that and not-empty combinators, and Clojure’s core library repeat function to build it.

The following snippet shows a summary of the work I did on the REPL to create the generator using again the sample function at each tiny step to see what inputs the growing generator would generate:

Next I used this new generator to write properties that this time did detect the regression mentioned above. Notice how there are separate properties for sequences with and without duplicates:

Finally, I managed to remove a redundant property-based test and got to this final version:

4. Conclusion.

All in all, this exercise was very useful to think about properties and to explore test.check’s generators and combinators. Using the REPL made this exploration very interactive and a lot of fun. You can find the code of this exercise on this GitHub repository.

A couple of days later I proposed to solve this exercise at the last Clojure Developers Barcelona meetup. I received very positive feedback, so I’ll probably propose it for a Barcelona Software Craftsmanship meetup event soon.

Examples lists in TDD

2018-03-20T17:30:00+00:00

1. Introduction.

During coding dojos and some mentoring sessions I’ve noticed that most people just start test-driving code without having thought a bit about the problem first. Unfortunately, writing a list of examples before starting to do TDD is a practice that is most of the times neglected.

Writing a list of examples is very useful because having to find a list of concrete examples forces you to think about the problem at hand. In order to write each concrete example in the list, you need to understand what you are trying to do and how you will know when it is working. This exploration of the problem space improves your knowledge of the domain, which will later be very useful while doing TDD to design a solution. However, just generating a list of examples is not enough.

2. Orthogonal examples.

A frequent problem I’ve seen in beginners’ lists is that many of the examples are redundant because they would drive the same piece of behavior. When two examples drive the same behavior, we say that they overlap with each other, they are overlapping examples.

To explore the problem space effectively, we need to find examples that drive different pieces of behavior, i.e. that do not overlap. From now on, I will refer to those non-overlapping examples as orthogonal examples^[1].

Keeping this idea of orthogonal examples in mind while exploring a problem space, will help us prune examples that don’t add value, and keep just the ones that will force us to drive new behavior.

How can we get those orthogonal examples?

Start by writing all the examples that come to your mind.
As you gather more examples ask yourself which behavior they would drive. Will they drive one clear behavior or will they drive several behaviors?
Try to group them by the piece of behavior they’d drive and see which ones overlap so you can prune them.
Identify also which behaviors of the problem are not addressed by any example yet. This will help you find a list of orthogonal examples.

With time and experience you’ll start seeing these behavior partitions in your mind and spend less time to find orthogonal examples.

3. A concrete application.

Next, we’ll explore a concrete application using a subset of the Mars Rover kata:

The rover is located on a grid at some point with coordinates (x,y) and facing a direction encoded with a character.
The meaning of each direction character is:
- "N" -> North
- "S" -> South
- "E" -> East
- "W" -> West
The rover receives a sequence of commands (a string of characters) which are codified in the following way:
- When it receives an "f", it moves forward one position in the direction it is facing.
- When it receives a "b", it moves backward one position in the direction it is facing.
- When it receives a "l", it turns 90º left changing its direction.
- When it receives a "r", it turns 90º right changing its direction.

Let’s start writing a list of examples that explores this problem. But how?

Since the rover is receiving a sequence of commands, we can apply a useful heuristic for sequences to get us started: J. B. Rainsberger’s “0, 1, many, oops” heuristic ^[2].

In this case, it means generating examples for: no commands, one command, several commands and unknown commands.

I will use the following notation for examples:

(x, y, d), commands_sequence -> (x’, y’, d’)

Meaning that, given the rover is in an initial location with x and y coordinates, and facing a direction d, after receiving a given sequence of commands (which is represented by a string), the rover will be located at x’ and y’ coordinates and facing the d’ direction.

Then our first example corresponding to no commands might be any of:

(0, 0, "N"), "" -> (0, 0, "N")
(1, 4, "S"), "" -> (1, 4, "S")
(2, 5, "E"), "" -> (2, 5, "E")
(3, 2, "E"), "" -> (3, 2, "E")
…

Notice that in these examples, we don’t care about the specific positions or directions of the rover. The only important thing here is that the position and direction of the rover does not change. They will all drive the same behavior so we might express this fact using a more generic example:

(any_x, any_y, any_direction), "" -> (any_x, any_y, any_direction)

where we have used any_x, any_y and any_direction to make explicit that the specific values that any_x, any_y and any_direction take are not important for these tests. What is important for the tests, is that the values of x, y and direction remain the same after applying the sequence of commands ^[3].

Next, we focus on receiving one command.

In this case there are a lot of possible examples, but we are only interested on those that are orthogonal. Following our recommendations to get orthogonal examples, you can get to the following set of 16 examples that can be used to drive all the one command behavior (we’re using any_x, any_y where we can):

(4, any_y, "E"), "b" -> (3, any_y, "E")
(any_x, any_y, "S"), "l" -> (any_x, any_y, "E")
(any_x, 6, "N"), "b" -> (any_x, 5, "N")
(any_x, 3, "N"), "f" -> (any_x, 4, "N")
(5, any_y, "W"), "f" -> (4, any_y, "W")
(2, any_y, "W"), "b" -> (3, any_y, "W")
(any_x, any_y, "E"), "l" -> (any_x, any_y, "N")
(any_x, any_y, "W"), "r" -> (any_x, any_y, "N")
(any_x, any_y, "N"), "l" -> (any_x, any_y, "W")
(1, any_y, "E"), "f" -> (2, any_y, "E")
(any_x, 8, "S"), "f" -> (any_x, 7, "S")
(any_x, any_y, "E"), "r" -> (any_x, any_y, "S")
(any_x, 3, "S"), "b" -> (any_x, 4, "S")
(any_x, any_y, "W"), "l" -> (any_x, any_y, "S")
(any_x, any_y, "N"), "r" -> (any_x, any_y, "E")
(any_x, any_y, "S"), "r" -> (any_x, any_y, "W")

There’re already important properties about the problem that we can learn from these examples:

The position of the rover is irrelevant for rotations.
The direction the rover is facing is relevant for every command. It determines how each command will be applied.

Sometimes it can also be useful to think in different ways of grouping the examples to see how they may relate to each other.

For instance, we might group the examples above by the direction the rover faces initially:

Facing East
(1, any_y, "E"), "f" -> (2, any_y, "E")
(4, any_y, "E"), "b" -> (3, any_y, "E")
(any_x, any_y, "E"), "l" -> (any_x, any_y, "N")
(any_x, any_y, "E"), "r" -> (any_x, any_y, "S")
Facing West
(5, any_y, "W"), "f" -> (4, any_y, "W") …

or, by the command the rover receives:

Move forward
(1, any_y, "E"), "f" -> (2, any_y, "E")
(5, any_y, "W"), "f" -> (4, any_y, "W")
(any_x, 3, "N"), "f" -> (any_x, 4, "N")
(any_x, 8, "S"), "f" -> (any_x, 7, "S")
Move backward
(4, any_y, "E"), "b" -> (3, any_y, "E")
(2, any_y, "W"), "b" -> (3, any_y, "W")
…

Trying to classify the examples helps us explore different ways in which we can use them to make the code grow by discovering what Mateu Adsuara calls dimensions of complexity of the problem^[4]. Each dimension of complexity can be driven using a different set of orthogonal examples, so this knowledge can be useful to choose the next example when doing TDD.

Which of the two groupings shown above might be more useful to drive the problem?

In this case, I think that the by the command the rover receives grouping is more useful, because each group will help us drive a whole behavior (the command). If we were to use the by the direction the rover faces initially grouping, we’d end up with partially implemented behaviors (commands) after using each group of examples.

Once we have the one command examples, let’s continue using the “0, 1, many, oops” heuristic and find examples for the several commands category.

We can think of many different examples:

(7, 4, "E"), "rb" -> (7, 5, "S") (7, 4, "E"), "fr" -> (8, 4, "S") (7, 4, "E"), "ffl" -> (9, 4, "N") …

The thing is that any of them might be thought as a composition of several commands:

(7, 4, "E"), "r" -> (7, 4, "S"), "b" -> (7, 5, "S") …

Then the only new behavior these examples would drive is composing commands.

So It turns out that there’s only one orthogonal example in this category. We might choose any of them, like the following one for instance:

(7, 4, "E"), "frrbbl" -> (10, 4, "S")

This doesn’t mean that when we’re later doing TDD, we have to use only this example to drive the behavior. We can use more overlapping examples if we’re unsure on how to implement it and we need to use triangulation^[5].

Finally, we can consider the “oops” category which for us is unknown commands. In this case, we need to find out how we’ll handle them and this might involve some conversations.

Let’s say that we find out that we should ignore unknown commands, then this might be an example:

(any_x, any_y, any_direction), "*" -> (any_x, any_y, any_direction)

Before finishing, I’d like to remark that it’s important to keep this technique as lightweight and informal as possible, writing the examples on a piece of paper or on a whiteboard, and never, ever, write them directly as tests (which I’ve also seen many times).

There are two important reasons for this:

Avoiding implementation details to leak into a process meant for thinking about the problem space.
Avoiding getting attached to the implementation of tests, which can create some inertia and push you to take implementation decisions without having explored the problem well.

4. Conclusion.

Writing a list of examples before starting doing TDD is an often overlooked technique that can be very useful to reflect about a given problem. We also talked about how thinking in finding orthogonal examples can make your list of examples much more effective and saw some useful heuristics that might help you find them.

Then we worked on a small example in tiny steps, compared different alternatives just to try to illustrate and make the technique more explicit and applied one of the heuristics.

With practice, this technique becomes more and more a mental process. You’ll start doing it in your mind and find orthogonal examples faster. At the same time, you’ll also start losing awareness of the process^[6].

Nonetheless, writing a list of examples or other similar lightweight exploration techniques can still be very helpful for more complicated cases. This technique can also be very useful to think in a problem when you’re working on it with someone else (pairing, mob programming, etc.), because it enhances communication.

5. Acknowledgements.

Many thanks to Alfredo Casado, Álvaro Garcia, Abel Cuenca, Jaime Perera, Ángel Rojo, Antonio de la Torre, Fran Reyes and Manuel Tordesillas for giving me great feedback to improve this post and for all the interesting conversations.

6. References.

7. Footnotes.

[1] This concept of orthogonal examples is directly related to Mateu Adsuara’s dimensions of complexity idea because each dimension of complexity can be driven using a different set of orthogonal examples. For a definition of dimensions of complexity, see footnote [4].

[2] Another very useful heuristic is described in James Grenning’s TDD Guided by ZOMBIES post.

[3] This is somehow related to Brian Marick’s metaconstants which can be very useful to write tests in dynamic languages. They’re also hints about properties that might be helpful in property-based testing.

[4] Dimension of Complexity is a term used by Mateu Adsuara in a talk at Socrates Canarias 2016 to name an orthogonal functionality. In that talk he used dimensions of complexity to classify the examples in his tests list in different groups and help him choose the next test when doing TDD. He talked about it in these three posts: Complexity dimensions - FizzBuzz part I, Complexity dimensions - FizzBuzz part II and Complexity dimensions - FizzBuzz part III. Other names for the same concept that I’ve heard are axes of change, directions of change or vectors of change.

[5] Even though triangulation is probably the most popular, there are two other strategies for implementing new functionality in TDD: obvious implementation and fake it. Kent Beck in his Test-driven Development: By Example book describes the three techniques and says that he prefers to use obvious implementation or fake it most of the time, and only use triangulation as a last resort when design gets complicated.

[6] This loss of awareness of the process is the price of expertise according to the Dreyfus model of skill acquisition.

Muchas gracias Luis

2018-03-12T07:30:00+00:00

Luis lleva tiempo centrado en su nueva aventura, Codium, a la vez que colabora con nosotros puntualmente como anteriormente había hecho. Debido a la vorágine del presente, aún no habíamos podido sentarnos a contarlo. Con este post nos gustaría hacerle un pequeño homenaje a Luis y agradecerle todo lo que ha aportado a Codesai hasta ahora, y desearle mucha suerte con Codium. Nuestra colaboración sigue adelante.

Fran: El pragmatismo y la capacidad de evaluar rápidamente costes y beneficios de una decisión son características que junto con su honestidad hacen de Luis un profesional que querrías tener en tu proyecto. Seguiremos aprovechando todo esto de él, aunque ahora le toque dar más foco su proyecto junto con Jordi.

Alfredo: Gracias Luis por todo lo aportado a Codesai durante este tiempo, tu visión y tu forma honesta y pragmática de expresarla siempre ha sido de gran valor para todos nosotros. Lo mejor de Luis es que, además de sus indudables conocimientos técnicos, tiene la capacidad de entender el negocio y enfocar el desarrollo de software siempre desde la perspectiva de aportar valor a ese negocio. Esta combinación de características, capacidad técnica y enfoque en la aportación de valor, es en mi opinión la clave para ser un gran profesional en este sector. Suerte a ti y a jordi en vuestra aventura con Codium!.

Dácil: Gracias, Luis, por sumar tanto al equipo en todo este tiempo, por ser siempre tan sincero, tan directo, por tu sempiterna predisposición. Para nosotros es ilusionante ver crecer tu proyecto y saber que existe un estrecho lazo que lo une a Codesai. Sé con certeza que seguirás sumando cada vez que lo necesitemos y viceversa.

Ronny: Ha sido un auténtico placer compartir esta experiencia contigo Luis. Me has enseñado mucho, no he tenido oportunidad aún de compartir un proyecto contigo, pero en cada discusión me has aportado. Principalmente destaco tu pragmatismo y tu forma de exponer. Para mí ha sido un referente no solo en el apartado técnico sino que también en la comunicación. Me alegra saber que la naturaleza de nuestros proyectos está tan ligada que seguiré teniendo la oportunidad de aprender de ti. De hecho, no descartes que Miguel y yo te volvamos a necesitar un miércoles a las 8 de la tarde para que nos ayudes con el Doctrine. Me hace muy feliz que proyectos como Codium salgan adelante, tenéis mucho que aportar! Mucha suerte!

Miguel: Fue con Luis con quien compartí mi primer proyecto de desarrollo asumiendo responsabilidades en Codesai. Siempre agradeceré la confianza que depositó en mí y las numerosas enseñanzas que me quedan desde entonces. La mentalidad Lean, el obtener feedback lo antes posible, en definitiva, aportar valor en su máximo exponente. Gracias por tus sabios consejos y tu capacidad de dar feedback de forma tan constructiva. Siempre hemos tenido la fortuna de contar con tu opinión y consejos en Codesai y quería expresarte mi gratitud por ello. Sé que en el futuro nuestros lazos seguirán ligados y que estamos aquí para lo que necesites. Gracias por tanto!

Manuel Tordesillas: Aunque no haya tenido el placer de desarrollar codo a codo con Luis, he tenido la gran oportunidad de aprender muchísimo de él tanto en el apartado profesional como en el personal. Su pragmatismo, su capacidad de síntesis y su deseo de aportar valor constantemente le convierten en un gran profesional y en un ejemplo para todos nosotros. Nuestros caminos seguirán cruzándose, mucha suerte con Codium!

Dani: Siempre me ha alucinado la capacidad de Luis para dar con el punto necesario y volver a enfocar la discusión justo cuando ésta empieza a dar vueltas. Muy preocupado por la productividad, cuando estoy con él siento que no va a pasar un minuto bien aprovechado. A destacar su pragmatismo y una forma muy objetiva de enfocar las cosas, estimo increíblemente valiosa su participación en cualquier debate. Desearía haber podido trabajar más juntos porque también estoy al tanto de su calidad como desarrollador y no puedo sino considerarlo un gran profesional lleno de aptitudes, pero sé que seguiremos teniendo oportunidades para hacerlo sin problema colaborando con Codium. También seguiremos coincidiendo en la comunidad, mucha suerte y muchas gracias por todo Luis!

Manuel Rivero: He tenido la suerte de trabajar con Luis en muchas formaciones. Creo que es una persona fiable, sincera, respetuosa, directa y flexible, que sabe tanto dar como recibir feedback. He aprendido muchísimo de él. Creo que su forma de pensar y sus contribuciones han sido valiosísimas para Codesai y es un gran formador. Le tengo mucho aprecio. Seguiremos colaborando juntos en el futuro. ¡Mucha suerte con Codium y muchas gracias por todo Luis!

Antonio: Llevo año y medio en Codesai y durante este tiempo, los momentos de grandes conversaciones y debates han sido frecuentes y en esos casos, la opinión de Luis siempre era valiosa, mesurada y objetiva. Y su trabajo con la comunidad está siendo una fuente de inspiración, ahora que estoy metiendo mucha energía en Agile Asturias; tanto por los repositorios de katas que tiene publicados, auténticas maravillas, como las propuestas de temas en el grupo de Murcia. Gracias!

Kata: Generating bingo cards with clojure.spec, clojure/test.check, RDD and TDD

2018-03-12T07:30:00+00:00

Clojure Developers Barcelona has been running for several years now. Since we’re not many yet, we usually do mob programming sessions as part of what we call “sagas”. For each saga, we choose an exercise or kata and solve it during the first one or two sessions. After that, we start imagining variations on the exercise using different Clojure/ClojureScript libraries or technologies we feel like exploring and develop those variations in following sessions. Once we feel we can’t imagine more interesting variations or we get tired of a given problem, we choose a different problem to start a new saga. You should try doing sagas, they are a lot of fun!

Recently we’ve been working on the Bingo Kata.

The initial implementation

These were the tests we wrote to check the randomly generated bingo cards:

and the code we initially wrote to generate them was something like (we didn’t save the original one): As you can see the tests are not concerned with which specific numeric values are included on each column of the bingo card. They are just checking that they follow the specification of a bingo card. This makes them very suitable for property-based testing.

Introducing clojure.spec

In the following session of the Bingo saga, I suggested creating the bingo cards using clojure.spec.

spec is a Clojure library to describe the structure of data and functions. Specs can be used to validate data, conform (destructure) data, explain invalid data, generate examples that conform to the specs, and automatically use generative testing to test functions.

For a brief introduction to this wonderful library see Arne Brasseur’s Introduction to clojure.spec talk.

I’d used clojure.spec at work before. At my current client Green Power Monitor, we’ve been using it for a while to validate the shape (and in some cases types) of data flowing through some important public functions of some key name spaces. We started using pre and post-conditions for that validation (see Fogus’ Clojure’s :pre and :post to know more), and from there, it felt as a natural step to start using clojure.spec to write some of them.

Another common use of clojure.spec specs is to generate random data conforming to the spec to be used for property-based testing.

In the Bingo kata case, I thought that we might use this ability of randomly generating data conforming to the spec in production code. This meant that instead of writing code to randomly generating bingo cards and then testing that the results were as expected, we might describe the bingo cards using clojure.spec and then took advantage of that specification to randomly generate bingo cards using clojure.test.check’s generate function.

So with this idea in our heads, we started creating a spec for bingo columns on the REPL bit by bit (for the sake of brevity what you can see here is the final form of the spec):

then we discovered clojure.spec’s coll-of function which allowed us to simplify the spec a bit:

Generating bingo cards

Once we thought we had it, we tried to use the column spec to generate columns with clojure.test.check’s generate function, but we got the following error:

ExceptionInfo Couldn’t satisfy such-that predicate after 100 tries.

Of course we were trying to find a needle in a haystack…

After some trial and error on the REPL and reading the clojure.spec guide, we found the clojure.spec’s int-in function and we finally managed to generate the bingo columns:

Then we used the spec code from the REPL to write the bingo cards spec:

in which we wrote the create-column-spec factory function that creates column specs to remove duplication between the specs of different columns.

With this in place the bingo cards could be created in a line of code:

Introducing property-based testing

Property-based tests make statements about the output of your code based on the input, and these statements are verified for many different possible inputs. Jessica Kerr (Property-based testing: what is it?)

Having the specs it was very easy to change our bingo card test to use property-based testing instead of example-based testing just by using the generator created by clojure.spec:

See in the code that we’re reusing the check-column function we wrote for the example-based tests.

This change was so easy because of:

clojure.spec can produce a generator for clojure/test.check from a given spec.
The initial example tests, as I mentioned before, were already checking the properties of a valid bingo card. This means that they weren’t concerned with which specific numeric values were included on each column of the bingo card, but instead, they were just checking that the cards followed the rules for a bingo card to be valid.

Going fast with REPL driven development (RDD)

The next user story of the kata required us to check a bingo card to see if its player has won. We thought this might be easy to implement because we only needed to check that the numbers in the card where contained by the set of called numbers, so instead of doing TDD, we ~~played a bit on the REPL~~ did REPL-driven development (RDD):

Once we had the implementation working, we copied it from the REPL into its corresponding name space

and wrote the quicker but ephemeral REPL tests as “permanent” unit tests:

In this case RDD allowed us to go faster than TDD, because RDD’s feedback cycle is much faster. Once the implementation is working on the REPL, you can choose which REPL tests you want to keep as unit tests.

Some times I use only RDD like in this case, other times I use a mix of TDD and RDD following this cycle:

Write a failing test (using examples that a bit more complicated than the typical ones you use when doing only TDD).
Explore and triangulate on the REPL until I made the test pass with some ugly but complete solution.
Refactor the code.

Other times I just use TDD.

I think what I use depends a lot on how easy I feel the implementation might be.

Last details

The last user story required us to create a bingo caller that randomly calls out Bingo numbers. To develop this story, we used TDD and an atom to keep the not-yet-called numbers. These were our tests:

and this was the resulting code:

And it was done! See all the commits here if you want to follow the process (many intermediate steps happened on the REPL). You can find all the code on GitHub.

Summary

This experiment was a lot of fun because we got to play with both clojure.spec and clojure/test.check, and we learned a lot. While explaining what we did, I talked a bit about property-based testing and how I use REPL-driven development.

Thanks again to all my colleagues in Clojure Developers Barcelona!

Muchas gracias Carlos

2018-03-01T22:30:00+00:00

Queríamos anunciaros que Carlos deja Codesai para emprender un nuevo proyecto personal. Un gran compañero se va y queremos agradecerle toda lo que ha hecho por el equipo. Ha sido fundamental para que Codesai llegase a ser lo que es hoy. Han sido unos años muy intensos y fructíferos en los que hemos aprendido mucho los unos de los otros.

Carlos, nos alegramos mucho viendo la ilusión con la que emprendes tu nuevo proyecto y queremos desearte lo mejor. ¡Muchísima suerte!

Fran: No podría hablar de mi camino profesional sin nombrar a Carlos. Trabajador incansable con el que he podido colaborar durante bastante tiempo de manera directa. Su visión y la capacidad de pensar diferente junto a su habilidad para establecer relaciones han hecho que pudiera aprender de él cosas que es muy difícil encontrar en otros desarrolladores de software. Espero poder seguir aprendiendo de él aunque nuestros caminos se bifurquen un poco. Muchas gracias por tu energía en Codesai y aporte a la comunidad. Tu nuevo camino seguro que deja huella e inspiración para otros.

Alfredo: Fue ya a finales de 2014 cuando gracias a Carlos aparecimos un buen día en Las Palmas cuatro locos: Carlos, Fran, Modesto y yo ilusionados apunto de empezar un nuevo proyecto, que al final resultó ser no sólo un proyecto más sino el germen de lo que hoy es Codesai. Lo mejor de Carlos es la iniciativa que ha tenido siempre para movilizar a la gente y embarcarlos en sus aventuras, ninguno de los que hoy formamos Codesai estaríamos aquí hoy si no fuera por Carlos. ¡Suerte en tus nuevas iniciativas!, y que esto no suene a despedida porque seguro que vamos a seguir colaborando en muchos proyectos.

Dácil: No necesitarás suerte porque eres un auténtico hard-worker de voluntad indomable… Cada nuevo comienzo es una oportunidad para mejorar, para crecer, para aprender. Traza tu propia senda tantas veces como haga falta… Vamosss, darling!! ;-)

Ronny: No sabría definir mis sentimientos, por un lado estoy triste, se va de Codesai un mentor, compañero y gran amigo. Contigo empezó todo para mí, una cena cambió mi vida radicalmente para convertirme en el primer aprendiz de un proyecto apasionante. Has marcado mucho la persona y el profesional que soy hoy. Te agradezco todo lo que has hecho por mí. Por otro lado, siento alegría. Porque como dije antes, por encima de un compañero eres un gran amigo. Soy consciente de la ilusión con la que afrontas tus nuevos proyectos y espero que te vaya fenomenal. Gracias por emprender y gracias por plantar los cimientos para que algo tan bonito como Codesai pueda seguir su rumbo. ¡Muchas gracias por todo y te deseo muchos éxitos con tus próximas aventuras!

Miguel: Es difícil enumerar las veces que Carlos siempre estaba dispuesto a echarte una mano. Siempre he tratado con él como un buen amigo además de un gran compañero de trabajo, siempre dispuesto y colaborador. Desde que te conocí me has abierto muchas puertas y facilitado mi formación y desarrollo como profesional e individuo, nunca estaré lo suficientemente agradecido por ello. Gracias por ser el punta de lanza en la creación de Codesai, permitir que estemos donde estamos hoy y de traer a la gente que hoy nos conforma. Solo me queda desearte mucha suerte en tus nuevos proyectos y que pongas de toda tu pasión y buen hacer para lograr tus propósitos. ¡Un fuerte abrazo y mucho ánimo de ahora en adelante y hasta que nos volvamos a cruzar!

Manuel Tordesillas: Si pienso en Carlos, lo primero que me viene a la cabeza es su imparable necesidad de generar un impacto positivo en su entorno. Hace aproximadamente un año Carlos me ofreció entrar en Codesai. No lo dudé y ha resultado ser una de las mejores decisiones que he tomado en mi vida. Un año después sigo aprendiendo, creciendo como profesional, como persona y descubriendo cosas nuevas cada día. Estoy seguro que en su nuevo camino seguirá luchando su cruzada por mejorar el mundo y generando oportunidades allá donde vaya. Espero tener algún día el mismo impacto positivo en la vida de otros como él ha tenido en la mía.

Dani: Una de las decisiones que te cambian la vida fue la que yo tomé lanzándome sin pensarlo dos veces a un curso de TDD impartido por Carlos en la isla de al lado hace ya casi 3 años. El yo de aquél entonces se estaba aventurando en un mundo de programación de videojuegos porque era la única faceta chula que le veía al mundo del software, mientras hacía alguna que otra kata de vez en cuando en la comunidad. La inyección de pasión y conocimiento que recibí en ese curso de la mano de Carlos desencadenó un cambio progresivo en mí que se hizo más fuerte según más le iba conociendo e iba intercambiando opiniones con él. Lo que al principio empezó como un nuevo y maravilloso camino en el mundo del desarrollo se convirtió en una nueva forma de pensar y ver el mundo, en otro estilo de comunicación basado en la observación y la escucha. Valoro enormemente lo que me has aportado a nivel de persona, lo que me has hecho evolucionar tanto de forma consciente como inconsciente, y no puedo sino esperar impacientemente por el próximo día en el que compartamos una buena charla. Mucha suerte con todo Carlos, nos vemos!

Manuel Rivero: Carlos, muchísimas gracias por introducirme en un grupo humano tan chulo como Codesai. Espero que te vaya muy bien en tu nuevo proyecto. ¡Muchísima suerte!

Antonio: Carlos siempre te agradeceré ser la primera persona que me hizo ver que era factible mi sueño de volver a Asturias después de 12 años fuera de mi tierra. Me has aportado muchas cosas, pero la que más ha cambiado mi vida es empezar a ver el trabajo como un medio para tener una vida mejor. Comprender que uno tiene control sobre cada una de las acciones que hace y eso incluye dónde y cómo se trabaja. ¡Muchísima suerte en tus nuevos proyectos!

Luis: La verdad es que hacia Carlos sólo puedo tener palabras de agradecimiento, pues con él me introduje en TDD hace casi 10 años. Años más tarde me abrió la puerta a la formación con mi primer curso en Ironhack y posteriormente acompañándole a impartir cursos de TDD. En el plano personal admiro su altruismo y la forma que tiene de brindar oportunidades a los demás. Y creo que esa es la clave de tu nueva aventura: seguir ayudando a los demás a trabajar en proyectos chulos, desde donde quieran trabajar y con una mentorización dedicada. Un fuerte abrazo y seguimos en contacto, pues nuestros caminos se cruzarán muchas veces :)

Charla Valores y principios en el diseño del software en CAS17

2017-12-29T00:00:00+00:00

Tras la charla que dimos Alfredo y yo en el AOS en Santiago de compostela de 2016 y el trabajo que hemos hecho en Codesai (en [1], [2] y [3]), especialmente Manuel Rivero, sobre el concepto de Connascence, me apetecía explorar otra perspectiva sobre los elementos del diseño del software en un ámbito más amplio y por tanto menos preciso. Uno de los beneficios de connascence es que elimina cierta ambiguedad que algunos principios (por ejemplo SOLID) pueden introducir al intentar comprenderlos pero por contra el conjunto de elementos que puede explicar es limitado. El objetivo final era añadir más herramientas para apreciar y escribir mejor software.

En la CAS del 2017 de Sevilla tuve la suerte de que mi charla fuera aceptada, lo que me daba la tensión suficiente para trabajar en el tema. No hay nada como buscar la excusa de ofrecer una charla para explorar más en profundidad un tema.

El libro de Kent Beck Implementation patterns (que había ojeado hace tiempo) ofrecía el espacio idóneo. La charla trata sobre como los principios y valores pueden ser aplicados en el diseño del software. El conjunto de valores (Communication, Simplicity, Flexibility) y principios (Local consequences, Minimize Repetition, Logic and Data Together, Declarative Expression, Symmetry, Rate of Change) que son explorados en Implementation patterns son la base de la charla que acompaño de algunos ejemplos.

En el transcurso de la preparación de la charla tuve la oportunidad de interactuar con algunas personas reconocidas en la comunidad como Nat Pryce y el mismo Kent Beck (vean estos hilos en Twitter: [1] y [2]), que amablemente respondieron a algunas de mis dudas y enriquecieron el contenido.

Mi sensación al dar la charla en la CAS fue bastante agridulce. Por un lado el contenido parece que gustó pero por otro lado mis habilidades como ponente aún tienen que mejorar bastante. La esperanza de que la práctica deliberada vaya mejorando este aspecto me consuela.

@fran_reyes genial la charla... Muy instructiva, cada slide es oro :) 100% de acuerdo con todo @confagilespain #CAS2017
— Eduardo Ferro Aldama (@eferro) November 9, 2017

Este es el vídeo de la charla

y estas son las slides.

Para terminar quiero dar las gracias a Autentia por la grabación de la charla, a la organización de la CAS por esforzarse al máximo para que estuvieramos como en casa y a los asistentes por hacer del evento algo memorable.

Estuvimos en Cetelem

2017-12-26T00:00:00+00:00

Hace unos meses Luis y yo hicimos un curso de TDD en Cetelem. Para mi fue una gran experiencia porque los asistentes estaban muy motivados. Este fue el primer curso que hacía con Luis, y me gustó muchísimo trabajar con él. Me encantó el ritmo que Luis le da al curso, su contenido eminentemente práctico y como la teoría se mezcla con la práctica de un modo muy fluido.

En cuanto al contenido, sustituimos la Coffe Machine kata por la Birthday Greetings kata para introducir los dobles de prueba de forma más gradual.

Muchísimas gracias a Cetelem por confiar en nosotros y a todos los asistentes por sus ganas de aprender.

Gráfico TDD de Growing Object-Oriented Software por Nat Pryce and Steve Freeman.
Imagen de Flickr de Cetelem España

Charla Discusiones y decisiones: herramientas para la efectividad en CAS17

2017-12-22T00:00:00+00:00

Hace un mes más o menos tuve el placer de dar una charla titulada “Discusiones y decisiones: herramientas para la efectividad” en la CAS (Conferencia Agile Spain) de este año 2017 que tuvo lugar en Sevilla.

La charla trataba de cómo conseguir que las múltiples reuniones que seguramente tienes al día sean más efectivas. Si te tienes que llevar unas ideas clave de mi charla serían éstas:

Que una reunión es como un juego, que tiene una reglas y un tiempo que todo el mundo se ha propuesto cumplir.
Que este juego se divide en tres partes, la apertura en la que prima el pensamiento divergente donde no hay casi límites a las ideas, una intermedia de exploración y búsqueda de conexiones y un cierre que busca la convergencia en un conjunto de ideas que nos sirvan para dar los siguientes pasos.
Y que en todo momento hay que trabajar con algo tangible: una pizarra, postits, papeles, que nos permita a todos ver lo que estamos construyendo.

Hacía ya casi dos años que quería profundizar en este tema y por eso agradecí tanto a la organización de la CAS que aceptase esta charla. Tengo una especial sensibilidad con la calidad de las reuniones que hago, sobre todo para que todo el que participe se sienta a gusto y lo pueda hacer sin sentirse coaccionado. Esto al principio puede parecer que ocurre porque las personas somos mal educadas, pero investigando me di cuenta que muchas veces se debe a que se confunde la parte exploratoria o divergente, dónde caben las ideas locas que puedan llevar a otras más realistas, con la parte más crítica o convergente, dónde sí que hay que mirar las posibilidades reales de cada opción. Si esta separación queda clara para todos, la discusión se desarrolla mucho más fluidamente.

Mis sensaciones dando la charla fueron agridulces. Sentí que la charla necesitaba aún algo más de rodaje para poder tocar todos los temas que quería en tan poco tiempo. Quería incidir en la parte teórica que fundamenta toda reunión, porque la parte práctica estaba seguro que todos la tenemos más vista. Sin embargo, el feedback de algunas personas me hizo darme cuenta de que podía haberme parado un poco más en los ejemplos prácticos.

Os comparto el video de la charla, espero que os resulte interesante. Quería aprovechar para una vez más darle muchísimas gracias a Autentia por grabarla y por la labor brutal que está haciendo para difundir eventos técnicos.

Y estas son las trasparencias:

Para terminar muchísimas gracias a todos los asistentes y especialmente a todas las personas que hicieron posible la CAS de este año, un super evento que además hizo posible que conociese Sevilla.

¡Nos vemos el próximo año en Alicante!

Gracias a David Gómez (1 y 2) y a Beatriz Zarzo (3) por dejarnos usar sus magníficas fotos.

Tercer curso abierto de TDD del año en Barcelona

2017-12-15T11:25:00+00:00

En vista del éxito que habían tenido los dos cursos abiertos de TDD que habíamos hecho este año en Barcelona, nos decidimos a hacer un nuevo curso abierto en Noviembre. Los cursos en abierto me hacen especial ilusión porque fue en uno de estos cursos abiertos dado por Carlos Blé en 2011 donde tuve la oportunidad de empezar a aprender sobre TDD.

En principio ibamos a dar el curso Luis y yo, pero, desgraciadamente, sufrí el síndrome de Miller Fisher, y al final Luis tuvo que dar el curso en solitario.

Asistieron ocho personas, de las cuales siete venían de la misma empresa, Systelab. ¡Muchas gracias por confiar en nosotros y kudos especiales para las personas que se pagaron el curso de su bolsillo!

El hecho de que casi todo el mundo viniese de la misma empresa hizo que no hubiera tanta variedad de lenguajes como en otros cursos en abierto: todos usaron Java. Las katas salieron de forma bastante fluida y el feedback que recibimos fue bastante bueno.

Finalizado el curso de TDD de @codesaidev facilitado por @luisrovirosa con la mochila de conocimientos a reventar y con enormes ganas de aplicar lo aprendido. Muuuuuuuuuyyyy recomendable!!!!!
— Fernando Monferrer (@Ferniter) 21 de noviembre de 2017

2017 ha sido un año muy fructifero en lo que se refiere a los cursos en abierto de TDD en Barcelona. Hemos tenido la suerte de hacer tres cursos (ver posts sobre el primero y el segundo) y de conocer a un montón de gente estupenda. Muchísimas gracias a todos las personas que asistieron.

Para finalizar quería dar las gracias a Magento, a Ángel Rojo, a Fernando Monferrer y a nuestra compañera Dácil por toda la ayuda que nos prestaron para que estos tres cursos llegaran a suceder.

We were at Lambda World 2017

2017-12-04T08:00:00+00:00

This last 26th and 27th of October I was a proud assistant of the Lambda World. I gathered with some colleagues from Codesai (Manuel Rivero and Antonio de la Torre) and with some friends. It was also my first time on the event so I was kinda hyped.

My main intention coming to the Conference was to be completely disrupted with this software programming paradigm. I’m a newbie when referring to functional programming and I’ve always wanted to learn it on my free time, but I’m usually stuck with topics related of what I want to improve on the clients I work on. So I thought this time it could be a great moment to finally awake that part of me that is waiting to start learning functional programming.

The conference was comprised of three sections: - The first day there was an open space in the morning and several workshops in the afternoon. The second day was a more conventional conference day full of talks.

During the open space I enjoyed quite a lot a session by Rúnar Bjarnason, it was an improvised crash course on Category Theory. I was quite amazed by the fact that he just opened a text editor and started writing every definition and identifying objects and arrows of every category.

I also attended the workshop session: “Don’t fear the monad” by Antonio Leiva. I really liked his session, but it was quite uncomfortable having to follow the examples and doing the exercises on benches without a desk or table to place my laptop. The workshop was great, it covered a lot of topics which were greatly explained. The only downside of the workshop was that we had a really short time to do it ourselves (about only 5 minutes) and it was impossible (at least for me) to end the exercises without being familiar with Kotlin.

On the second day I assisted to many talks. But I particularly enjoyed the ones facilitated by Hadi Hariri and Daniela Sfregola.

“Kotlin 102” (I couldn’t find the link from the conference, so this one is from Devoxx Conference) was a great summary about many of the decisions that Jetbrains has made on designing Kotlin to be more functional-friendly and most importantly, remove unnecessary boilerplate to keep only the necessary tools. The talk was really funny and didactic. I got a deep insight of Kotlin and I can say I can’t wait to try it on any of my side projects.

The second talk by Daniel Sfregola “A Pragmatic Introduction to Category Theory” was a kind of Category Theory Developer Oriented talk. Basically it was a summary of each category, but removing all the abstraction, and explaining it straight from a code implementation. Although the talk itself wasn’t very revealing, in my case, it was a confirmation of everything I had learned during the conference about Category Theory and I felt a little proud of myself :)

Also I assisted to the talk Functional Programming in Kotlin with Kategory by Paco Estevez and Raúl Raja from 47 Degrees. It was an introductory talk about the library they have developed and every feature they have brought into Kotlin. I was mesmerized by how powerful and great it looked. The talk was really enjoyable and dynamic. And my last session was at the Keynote “Profunctor Optics: The Categorical Approach” by Bartosz Milewski. Sadly I didn’t get a single clue of the talk. Too advanced for me. I hope I can watch it again in a year and understand it.

Finally. I would like to thank the organization. The event was fantastic and the venue simply amazing. The only thing that I can think that might be improved are the workshops. I think benches are not a good place to program, but I understand that there was no other place in the venue that might have fixed that problem. That is what tradeoffs are about :D

And I would also like to give some feedback about the conference itself. In my opinion it would be really great having more topics apart from Category Theory, which was, no doubt the most discussed topic on the conference. For instance, I would have liked to have some more talks about dynamic functional languages.

To conclude I’d like to thank everyone I have talked to during the conference. I had a great opportunity to meet new people and spend some time with my Codesai colleagues and friends. I hope I can make it again next year.

I’m glad because I finally had the chance to come to this conference and immerse myself in this FP “world”.

I got a new perspective on applying functional programming for my day-to-day work. I’m happy because I feel that a lot of new paths have suddenly opened in front of me and I love it. I will try to practice more with this paradigm and get a better understanding of it. I hope next year I can understand a 30% of what is told in the conference talks. But for a newbie, understanding a 10% I think it’s a good starting point.

Thanks everybody for an amazing Lambda World 2017!

We were at Merkle

2017-12-02T16:00:00+00:00

Last October Luis Rovirosa, Jordi Anguela and I had the pleasure to give three TDD trainings at Merkle’s impressive offices in Barcelona. Merkle is a consulting company distributed worldwide which is very committed to deliver not only value but also high quality software to their clients.

We worked with three groups comprised of people from different teams. This mix was challenging but also rewarding because the members of each team brought with them different set of problems, skills and practices, which lead to interesting discussions and opportunities to learn. All in all, I think we managed to satisfy the expectations they had about our training.

I delivered two of the trainings with Luis, and Jordi and Luis the other one. Every time it’s possible we try to give our trainings in pairs because we think it makes them much better. Being two we can devote more time to give feedback and help each person with their doubts while they are working through the katas. It also helps us monitor our audience better so that we can adapt our message to their needs.

We loved working with such great people. We’d like to thank them all for the great time we had. We’d also like to specially thank Nelson Cardenas for having contacted us to work with them. We’d love to continue collaborating with this great team in the future.

Native/Browser SPA versions using ClojureScript and re-frame talk at SCBCN17

2017-11-17T08:00:00+00:00

Last month I had the pleasure of giving a talk at the Software Craftsmanship Barcelona 2017 conference about what my colleague Francesc and I have been learning lately while working on the mobile and browser versions of a SPA using ClojureScript and re-frame.

I talked mainly about how re-frame’s effects and coeffects, re-frame’s subscriptions and modelling a UI as FSMs place you in a pit of success, i. e., a design that, according to Jeff Atwood, “makes it easy to do the right things and annoying (but not impossible) to do the wrong things”.

It was my first talk in a big conference and I had some technical problems, so I was very nervous at the beginning. After a while I relaxed and felt better. In the end I received more questions than I expected and very nice feedback.

I’d like to thank Modesto for lending me his computer when mine crashed just before the talk and helping me relax.

This is the video of the talk, (thanks Autentia for recording all the talks and for being so kind to me when I was having technical difficulties). I hope you’ll find it interesting:

and these are the slides that I’ve improved after the talk using Modesto’s feedback (thanks!!): .

Thanks to Francesc and all the people in Clojure Developers Barcelona Group, Green Power Monitor and Codesai that contributed to improve the talk with their feedback. Also thanks to my colleague Antonio for “persuading” me to give a talk in a conference.

Finally, I’d also like to thank Software Craftsmanship Barcelona 2017 conference organizers for giving me the opportunity to talk at such a great conference and for all the effort they put to make this conference better, edition after edition.

Software Craftsmanship Barcelona 2017

2017-11-08T06:00:00+00:00

Four weekends ago, a few colleagues from Codesai and I attended the Software Craftsmanship Barcelona 2017 conference. While some of them had already come in previous years, I was a first timer and my expectations were very high. I have heard very positive comments from attendees to previous editions. For the year I lived in Barcelona, I became a member of the community and tried to attend to all the katas every Monday, where information about the event leaked little by little. I was lucky to get them on the first day on sale.

I would like to thank the organisers and the community, all this anticipation and nerves for getting the tickets were well worth it.

Talks

It was hard to choose which talks to attend to but thanks to autentia, we can watch all the talks over and over again. From every talk I attended to I took home at least one important learning pill.

Native and browser SPA versions using re-frame, ClojureScript and ReactNative Manuel Rivero On this talk, my colleague and mentor Manuel shared his learnings from one of his projects using ClojureScript and re-frame. I found the concept of effects and coeffects very interesting and I am tempted to get over the parentheses (or “elegant weapons for a more civilized age” as he prefers to call them) and start learning Clojure.

Simplicidad (para desarrolladores) Edu Ferro Edu made a very convincing case for the need of developers to put their feet on the ground and design solutions with simplicity in mind. I really liked the concept that he introduced for introducing new features in our systems: refactor the code before integrating that feature for it to fit as if it was designed with the rest of the system from the get go.

Slow Life (Como montárselo bien como programador) Luis Rovirosa, Jordi Anguela Luis and Jordi tried to make us reflect whether we feel we are doing well or not as developers in both our professional and personal lives. I found the talk very insightful, with tips and tricks to prioritize our objectives and to reach the point where we want to be. I felt reflected on most of the points they brought across since I have lived similar moments along my personal and professional career.

TDD: Mi libro de recetas Modesto Sanjuan Modesto made a very practical talk about why he uses TDD and some tools to avoid some of it pitfalls. Very interesting discussions were raised about naming, test structuring and assertions that made me reassess my knowledge about TDD.

The Economics of Continuous Delivery Adrian Perreau Adrian presented a very interesting and mathematical approach on how to sell Continuous Delivery to stakeholders in the language they most commonly understand, MONEY! With the aid of some mathematical formulas he showed us how to calculate the effort and money needed in traditional Integration and Delivery compared with Continuous Delivery. (Hint: Continuous Delivery is the clear winner)

Clean Code, SOLID, CQRS… ¿Y qué hay de nuestros test? Rafa Gómez y Javi Ferrer On their very fun and interesting talk, Rafa and Javi talked about how to test our CQRS architectures. They made a good introduction of the different types of tests they normally use when developing CQRS applications, when they prefer to use them. They also introduced some really interesting test anti-patterns with seriously cool names.

Event Organisation and Food

I would like to take the time to thank again the organisers, they made such a great event possible. We know that growing from 80 to 200 people is not easy but they succeeded. There was always one organiser available when I needed assistance and I always knew what was going on.

I really liked the venue, even if it is not in the most centric part of Barcelona, we had well sized rooms that and some green areas where we could get out and relax. The food during the day was also a high point, with fruit and drinks readily available.

The community

I would also like to thank the Software Craftsmanship community, I am proud to belong to such a group of people where we find a safe space to talk about how to continue improving on both our professional and personal facets of our lives. I have joined many interesting hall talks and finally devirtualized people like Rachel or Modesto. I leave the event with more desire to continue learning than ever. Will be back!

Flejesai 2017 Edición de Otoño

2017-10-20T06:00:00+00:00

Qué es, dónde y por qué

Hace dos semanas organizamos el Flejesai, edición Otoño 2017. Desde que se fundó Codesai el año pasado nos reunimos cada seis meses para vernos, charlar de temas importantes que se hablan mejor en persona y sobre todo fortalecer los lazos que en una empresa totalmente remota hay que cuidar de manera especial.

Es el tercero al que asisto, y después de Las Palmas de Gran Canaria y Madrid, ya tenía ganas de traer a mis compañeros a Asturias. Estoy especialmente orgulloso de lo que puede ofrecer esta tierra.

Además de lo típico en lo que todos estaréis pensando, paisajes y buena comida, lo que realmente me hacía desear hacer un Flejesai aquí, era que quería invitar a mis compañeros a mi pueblo, en Borines.

El cariño que siento por este rincón, la casa en la que nació mi madre y en la que paso muchos fines de semana, no disminuye con el tiempo, y nunca me acostumbraré a las vistas del valle que puedo ver desde la terraza, sí, es la que veis en la foto de arriba. Pues todo esto quería compartir con mis compañeros.

La organización

El evento que queríamos hacer consistía en dos días enteros de charla, por tanto las llegadas y salidas serían el día anterior y posterior. No es poca cosa pensar en todo lo necesario para 11 personas durante cuatro días.

Lo primero fue valorar si podíamos hacer nuestro evento allí, en la casa familiar, y llegamos a la conclusión que no era un buen lugar. Hay que reconocer que no es precisamente un centro de empresas e íbamos a estar un tanto incómodos tantas personas hablando mucho tiempo, queriendo proyectar, etc.

Afortunadamente, a unos 10 minutos caminando encontramos una casa rural que nos iba a resolver tanto alojamiento como salas de reuniones. El resto de la preparación consistió en garantizar que nuestro mayor foco estuviese en hablar de nuestras cosas, así que todas la comidas o las encargamos o fuimos a disfrutarlas a algún sitio cercano.

Y empezamos…

Con todo ya listo llegó el gran día. Los dos objetivos principales eran hablar de los temas que traíamos en la agenda y pasar mucho tiempo juntos, charlando.

De lo primero hubo mucho, hablamos largo y tendido de lo que nos preocupa y tomamos decisiones que ayudarán a seguir fortaleciendo este equipo y afiancen el futuro de nuestra pequeña organización. Luego os comentaré alguna.

De la parte de charla y ocio, menos de lo que nos hubiese gustado. Conversamos mucho entre nosotros, teniendo algún ‘café’ y pudimos conocernos un poco más. Creamos el meme ‘Quiero saber a qué dedica su tiempo libre X’. Puede que un poco forzado, pero entrábamos al trapo, cómo no. Aunque en la retrospectiva estuvimos de acuerdo en que haría falta fijar mejor los horarios de la agenda, reuniones y descansos, para así manejar mejor las expectativas de tiempo libre. Hubo muchos tiempos muertos en los que se nos iba la energía: “¿Paramos o seguimos? … (sloths everywhere)”

Resultados

¿Qué me llevo? (pregunta clásica): mucho.

La mayoría de los temas tratados han sido sobre organización interna, en mi opinión quizá demasiados. Se nota que somos una empresa joven y que hay todavía cimientos que afianzar.

Sí empezamos a hablar de algunos puntos más estratégicos y de cultura que me gustaría seguir trabajando ya poco a poco con el equipo los próximos meses.

El primero que destacaría fue el de la asistencia a eventos y presentar charlas, si las vemos necesarias y a cuáles ir. Todos sentimos que tienen un gran coste en muchos aspectos: económico, de tiempo, familiar, …

Este tema nos llevó a uno más general, sobre qué estrategia de marketing tenemos, el cómo nos damos a conocer. Porque vimos que ir a eventos es una herramienta más, como el blog, la organización de cursos, la participación en comunidades locales o el trabajo más comercial de contacto directo con clientes interesantes con los que colaborar.

Salió la idea de organizar un curso en abierto de “TDD Avanzado”, que ya lo está reclamando mucha gente, y uno de “Refactoring”, pues ya se está impartiendo a empresas.

El segundo punto que destacaría de los temas tratados, es definir mejor nuestra estrategia de formación interna. Fue breve, pero sacamos alguna idea para potenciar lo que considero una de las características que nos definen, el aprendizaje continuo. Actualmente hacemos pairing casi constante y repartimos pequeñas píldoras de conocimiento entre las personas que estamos en el mismo proyecto, pero nos faltaría algo más a medio plazo a nivel de todo el grupo. De aquí salieron ideas como clubes de lectura, katas los viernes, mentoring y charlas internas, … realmente muy potente.

Sensaciones

Cuando nos despedíamos, nos decíamos unos a otros que fue el mejor Flejesai que habíamos hecho hasta ahora. Nos fuimos muy unidos y con mucha energía.

Es que el concepto de ‘retiro’ en casa rural es el que necesitamos, es importante que todos durmamos en el mismo sitio, ser prácticos es menos importante que maximizar las oportunidades de conversación.

Y por supuesto, lo que pasa en el Flejesai, se queda en el Flejesai. Sobre todo lo que a ‘karaokes’ hasta las cinco de la mañana se refiere.

¡Y ahora a gastar esa energía!

Por cierto, una de las decisiones fue que el próximo Flejesai será en febrero/marzo en Tenerife, que no es Asturias, pero tampoco está nada mal, ¿no os parece?

In a small piece of code

2017-08-22T00:00:00+00:00

In a previous post we talked about positional parameters and how they can suffer from Connascence of Position, (CoP). Then we saw how, in some cases, we might introduce named parameters to remove the CoP and transform it into Connascence of Name, (CoN), but always being careful to not hiding cases of Connascence of Meaning, (CoM). In this post we’ll focus on languages that don’t provide named parameters and see different techniquess to remove the CoP.

Let’s see an example of a method suffering of CoP:

In languages without named parameters (the example is written in Java), we can apply a classic^[1] refactoring technique, Introduce Parameter Object, that can transform CoP into CoN. In this example, we introduced the ClusteringParameters object:

which eliminates the CoP transforming it into CoN:

In this particular case, all the parameters passed to the function were semantically related, since they all were parameters of the clustering algorithm, but in many other cases all the parameters aren’t related. So, as we saw in our previous post for named parameters, we have to be careful of not accidentally sweeping hidden CoM in the form of data clumps under the rug when we use the Introduce Parameter Object refactoring.

In any case, what it’s clear is that introducing a parameter object produces much less expressive code than introducing named parameters. So how to gain semantics while removing CoP in languages without named parameters?

One answer is using fluent interfaces ^[2] which is a technique that is much more common than you think. Let’s have a look at the following small piece of code:

This is just a simple test. However, just in this small piece of code, we can find two examples of removing CoP using fluent interfaces and another example that, while not removing CoP, completely removes its impact on expressiveness. Let’s look at them with more detail.

The first example is an application of the builder pattern using a fluent interface^[3].

Applying the builder pattern provides a very specific^[4] internal DSL that we can use to create a complex object avoiding CoP and also getting an expressiveness comparable or even superior to the one we’d get using named parameters.

In this case we composed two builders, one for the SafetyRange class:

and another for the Alarm class:

Composing builders you can manage to create very complex objects in a maintanable and very expressive way.

Let’s see now the second interesting example in our small piece of code:

This assertion using hamcrest is so simple that the JUnit alternative is much clearer:

but for more than one parameter the JUnit interface starts having problems:

Which one is the expected value and which one is the actual one? We never manage to remember…

Using hamcrest removes that expressiveness problem:

Thanks to the semantics introduced by hamcrest^[6], it’s very clear that the first parameter is the actual value and the second parameter is the expected one. The internal DSL defined by hamcrest produces declarative code with high expressiveness. To be clear hamcrest is not removing the CoP, but since there are only two parameters, the degree of CoP is very low^[7]. The real problem of the code using the JUnit assertion was its low expressiveness and using hamcrest fixes that.

For us it’s curious to see how, in trying to achieve expressiveness, some assertion libraries that use fluent interfaces have (probably not being aware of it) eliminate CoP as well. See this other example using Jasmine:

Finally, let’s have a look at the last example in our initial small piece of code which is also using a fluent interface:

This is Mockito’s way of defining a stub for a method call. It’s another example of fluent interface which produces highly expressive code and avoids CoP.

Summary.

We started seeing how, in languages that don’t allow named parameters, we can remove CoP by applying the Introduce Parameter Object refactoring and how the resulting code was much less expressive than the one using the Introducing Named Parameters refactoring. Then we saw how we can leverage fluent interfaces to remove CoP while writing highly expressive code, mentioned internal DSLs and showed you how this technique is more common that one can think at first by examining a small piece of code.

References.

Books.

Refactoring: Improving the Design of Existing Code, Martin Fowler
Growing Object-Oriented Software Guided by Tests, Nat Pryce and Steve Freeman.
Refactoring Ruby, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie

Posts.

Refactoring Ruby: Bad Smells in Code, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie
Builders vs option maps, Kyle Kingsbury
Refactoring tests using builder functions in Clojure/ClojureScript, Manuel Rivero
Remove data structures noise from your tests with builders, Carlos Blé
Two examples of Connascence of Position, Manuel Rivero, Fran reyes
About Connascence, Manuel Rivero

Footnotes:

[1] See Martin Fowler's Refactoring, Improving the Design of Existing Code book.

[2] Of course, fluent interfaces are also great in languages that provide named parameters.

[3] Curiosly there're alternative ways to implement the builder pattern that use options maps or named parameters. Some time ago we wrote about an example of using the second way: Refactoring tests using builder functions in Clojure/ClojureScript.

[4] The only purpose of that DSL is creating one specific type of object.

[5] For us the best explanation of the builder pattern and how to use it to create maintanable tests is in chapter 22, Constructing Complex Test Data, of the wonderful Growing Object-Oriented Software Guided by Tests book.

[6] hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. We love it!

[7] See our previous post about CoP.

Notes on SRP from Agile Principles, Practices and Patterns book

2017-08-17T11:00:00+00:00

I think that if you rely only on talks, community events, tweets and posts to learn about a concept, you can sometimes end up with diluted (or even completely wrong) versions of the concept due to broken telephone game effects. For this reason, I think it’s very useful to try to get closer to the sources of the concepts you want to learn.

Lately I’ve been doing an effort to get closer to the sources of some object-oriented concepts.

These are my notes on Single Responsibility Principle I’ve taken from the chapter devoted to it in Robert C. Martin’s wonderful Agile Principles, Practices and Patterns in C# book:

"This principle was described in the work of [Larry Constantine, Ed Yourdon,] Tom DeMarco and Meilir Page-Jones. They called it cohesion, which they defined as the functional relatedness of the elements of a module" <- [!!!]
"... we modify that meaning a bit and relate cohesion to the forces that cause a module, or a class, to change"
[SRP definition] -> "A class should have only one reason to change"
"Why was important to separate [...] responsibilities [...]? The reason is that each responsibility is an axis of change" <- [related with Mateu Adsuara's complexity dimensions]
"If a class has more than one responsibility the responsibilities become coupled" <- [related with Long Method, Large Class, etc.] <- [It also eliminates the possibility of using composition at every level (functions, classes, modules, etc.)] "Changes to one responsibility may impair or inhibit the class ability to meet the others. This kind of coupling leads to fragile designs" <- [For R. C. Martin, fragility is a design smell, a design is fragile when it's easy to break]
[Defining what responsibility means]
- "In the context of the SRP, we define a responsibility to be a reason for change"
- "If you can think of more than one motive for changing a class, that class has more than one responsibility. This is sometimes difficult to see"
"Should [...] responsibilities be separated? That depends on how the application is changing. If the application is not changing in ways that cause the [...] responsibilities to change at different times, there is no need to separate them." <- [applying Beck's Rate of Change principle from Implementation Patterns] "Indeed separating them would smell of needless complexity" <- [Needless Complexity is a design smell for R. C. Martin. It's equivalent to Speculative Generality from Refactoring book]
"An axis of change is an axis of change only if the changes occur" <- [relate with Speculative Generality and Yagni] "It's not wise to apply SRP, or any other principle if there's no symptom" <- [I think this applies at class and module level, but it's still worth it to always try to apply SRP at method level, as a responsibility identification and learning process]
"There are often reasons, having to do with the details of hardware and the OS [example with a Modem implementing two interfaces DateChannel and Connection], that force us to couple things that we'd rather not couple. However by separating their interfaces, we [...] decouple[..] the concepts as far as the rest of the application is concerned" <- [Great example of using ISP and DIP to hide complexity to the clients] "We may view [Modem] as a kludge, however, note that all dependencies flow away from it." <- [thanks to DIP] "Nobody needs to depend on this class [Modem]. Nobody except main needs to know it exists" <- [main is the entry point where the application is configured using dependency injection] "Thus we've put the ugly bit behind a fence. It's ugliness need not leak out and pollute the rest of the app"
"SRP is one of the simplest of the principles but one of the most difficult to get right"
"Conjoining responsibilities is something that we do naturally"
"Finding and separating those responsibilities is much of what software design is really about. Indeed the rest of the principles we discuss come back to this issue in one way or another"

Agile Principles, Practices and Patterns in C# is a great book that I recommend to read.

For me getting closer to the sources of SOLID principles was a great experience that helped me to remove illusions of knowledge I had developed due to the telephone game effect of having initially learned it through blogs and talks.

I hope these notes on SRP will be useful for you as well.

Comentarios en el código

2017-08-03T11:00:00+00:00

¿Comentamos el código? ¿si o no? Esa pregunta totalmente desprovista de contexto no puede tener una respuesta con la que esté de acuerdo todo el mundo. Sin más contexto, la discusión es inútil. La pregunta realmente es, ¿cuándo documentar el código?.

El objetivo de los comentarios NO es explicar lo que hace el código.

El código debe ser expresar con claridad lo que hace sin necesidad de comentarios, para lo cual disponemos de variables explicativas, funciones y métodos, clases, objetos, y un sin fin de recursos para que el código sea expresivo y no se requiera lenguaje natural para contar lo que hace. El problema de los comentarios que explican lo que está haciendo el código, es que son una excusa perfecta para escribir código que no entiende nadie. Con el tiempo el código se actualiza y cambia, pero nunca he conocido a nadie que actualizase los comentarios. Con lo cual llega un momento en que nos encontramos con un código tremendamente difícil de entender y que además tiene unas líneas de comentario por encima que mienten. Los comentarios están diciendo que el código hace algo que no hace. Doble dilema, código que nadie entiende y comentarios para despistar más todavía.

Cada vez que uno siente la necesidad de poner un comentario sobre un bloque de líneas de código, es una oportunidad para pensar si se puede extraer una función que tenga por nombre lo mismo que se iba a escribir en el comentario. Sobre todo estos bloques típicos que tienen una sospechosa línea en blanco al terminar, como para separarlo del siguiente bloque de código. Esto canta a función/método.

El código se escribe para que lo lean las personas, no las máquinas, ya que son personas quienes tendrán que mantenerlo. Los comentarios han hecho tanto daño que hemos acabando yendo al lado opuesto, a no escribir jamás ningún tipo de comentario. Y de esto quería hablar en este post, de lo mucho que hecho de menos los comentarios y la documentación en los proyectos. Por que los comentarios son muy útiles para contar el contexto, cosa que el código en sí no puede contar por más limpio que sea. Los comentarios nos permiten:

Explicar por qué, para qué y también por qué no, y qué evitar.
Por qué se decidió implementar concretamente de la manera que está.
Por qué se descartó implementarlo de otra manera que quizás parece más obvia o natural.
Para qué se usa ese código, dónde encaja, qué otros posibles usos podría tener. Si existe alguna situación en la que pudiera ser prescindible y borrarse.
Lo que se probó y no funcionó, para que no vuelva a invertir el tiempo la persona que viene.
Lo que se estudió y se descartó. Cuáles fueron las conclusiones de la investigación.
Los efectos colaterales que provocarían cambios aparentemente inocuos. Por ejemplo condiciones de carrera o interbloqueos al cambiar de orden dos líneas de código. Un salto de línea que parece insignificante y hace que luego la importación de un fichero en un sistema externo deje de funcionar…
Si existen parámetros globales de configuración u otros factores externos que podrían afectar a este código o que haya que tener en cuenta para su correcto funciomaniento.
Si en caso de fallo se puede ir a mirar algún tipo de log o cualquier otra forma de depuración. Sobre todo en tests de integración.
Si el sistema puede crecer hasta un punto en que el código dejará de servir. Es decir, si hemos elegido una solución potencialmente de corto recorrido. Por ejemplo una librería que ya no tiene soporte o un sistema que sólo aguantará hasta N usuarios.
Ayudar a entender cómo se comporta una librería o framework cuando interactuamos de cierta forma que podría no estar documentada o ser poco intuitiva.
Sorpresas de software de terceros, para que sólo nos la llevemos una vez.
Describir un API pública de propósito general.

No es que haya que hablar sobre todos los elementos de esta lista en todos los casos. Algunos de estos criterios serán aplicables a veces y otras no. Creo que es evidente que no todo bloque de código llevará comentarios ni muchísimo menos. Todavía oigo a gente decir que todas las rutinas deben llevar comentarios. Así sin más, no tiene sentido. Cuando pongo comentarios además me gusta poner la fecha, aunque se podría mirar en el control de versiones pero me resulta más rápido. Cuanto más viejo el comentario más posibilidades hay de que esté obsoleto. Quizás podría tener sentido poner el nombre del que escribe el comentario como para que otros puedan tener una conversación, aunque la verdad yo no lo hago. Sobre todo porque la mayor parte la hacemos en pares.

¿Y qué hay de los comentarios de cabecera tipo javadoc? Me refiero a los comentarios que se ponen para las herramientas de generación de documentación automática o para el IDE. En lenguajes compilados donde podemos hacer uso de nuestros propios tipos, podemos ahorrarnos muchos de esos comentarios. Cuando se trata del núcleo de lógica de negocio, si usamos tipos con un nombre expresivo en lugar de abusar de los primitivos, no hace falta describir el parámetro. Y es que abusamos muchísimo de los primitivos, que deberían quedar relegados a intercambio de información con sistemas de terceros y a detalles internos de implementación. Personalmente solo documento funciones de APIs que tengan un propósito general, un uso muy horizontal. Por ejemplo cuando he hecho alguna librería. Con lenguajes interpretados como PHP, poner cabeceras en las funciones con los tipos ayuda a que el IDE autocomplete e indexe mejor. Si el comentario aporta un contexto que el código en sí no puede aportar y de verdad no es redundante, es buena idea describir los parámetros de la función y el valor de retorno. Lo que evitaría, nuevamente, es ponerlos siempre en todos los casos aunque sea redundante y para que esté sirviendo de excusa para no diseñar un sistema de clases acorde al dominio.

Los tests son igual de importantes que el código de producción, por lo tanto aplica también la documentación y posibles comentarios. De hecho algunos de los principios de esta lista están extraídos de los tests. Por ejemplo documentar que no se pueden lanzar en paralelo porque se ha introducido deuda técnica que provocaría que fallasen. O explicar que son frágiles porque dependen de esto o aquello que podría cambiar. Suele tener que ve con deuda técnica y código legacy donde hay cajas de pandora ocultas. La idea es al menos hacerlas visibles.

Toda excepción tiene su regla. Me he encontrado con la necesidad de comentar código legado que era muy difícil de entender, escrito por personas que ya no estaban en la empresa. Código que no mejoraba apenas aplicando refactorings seguros como podría ser un renombrado o una extracción de método. Y sin tener
la capacidad de cambiarlo por miedo a romperlo, he comentado lo que he podido descifrar con paciencia. Depurando, con prueba y error. Aunque sepa que en el momento que tenga unos tests podré cambiar el código y prescindir de esos comentarios, en el momento del hallazgo aporta a todo el equipo dejar algo más entendible escrito. Se puede aprovechar a explicar los motivos que han llevado a tener que explicar el código en lenguaje natural.

Además de los comentarios, hay cuestiones transversales que es importante documentar. Ya no solo temas de infraestructura o deuda técnica, sino todo aquello que nos ayude a ser más productivos como podría ser ejecutar los tests desde el propio IDE o afinar bien cualquier otra herramienta. Se pueden usar wikis o simplemente ficheros markdown versionados en la raíz del propio código fuente. Más tarde o más temprano, la documentación quedará obsoleta pero por el camino habrá sido de utilidad al equipo.

En definitiva amigos del código limpio, os invito a tener más presentes los comentarios y la documentación porque a nadie le gusta perder el tiempo más de una vez en descifrar la misma cosa. Es frustrante y desagradecido. Y porque el mejor código del mundo no tiene la capacidad de contarnos cuál es su contexto.

Two examples of Connascence of Position

2017-07-31T00:00:00+00:00

A first example.

As we saw in our previous post about connascence, Connascence of Position (CoP) happens when multiple components must be adjacent or appear in a particular order. CoP is the strongest form of static connascence, as shown in the following figure.

Connascence forms sorted by descending strength (from Kevin Rutherford's XP Surgery).

A typical example of CoP appears when we use positional parameters in a method signature because any change in the order of the parameters will force to change all the clients using the method.

The degree of the CoP increases with the number of parameters, being zero when we have only one parameter. This is closely related with the Long Parameters List smell.

In some languages, such as Ruby, Clojure, C#, Python, etc, this can be refactored by introducing named parameters (see Introduce Named Parameter refactoring)^[1].

Now changing the order of parameters in the signature of the method won’t force the calls to the method to change, but changing the name of the parameters will. This means that the resulting method no longer presents CoP. Instead, now it presents Connascence of Name, (CoN), which is the weakest form of static connascence, so this refactoring has reduced the overall connascence.

The benefits don’t end there. If we have a look at the calls before and after the refactoring, we can see how the call after introducing named parameters communicates the intent of each parameter much better. Does this mean that we should use named parameters everywhere?

Well, it depends. There’re some trade-offs to consider. Positional parameters produce shorter calls. Using named parameters gives us better code clarity and maintainability than positional parameters, but we lose terseness^[2]. On the other hand, when the number of parameters is small, a well chosen method name can make the intent of the positional arguments easy to guess and thus make the use of named parameters redundant.

We should also consider the impact that the degree and locality of each instance of CoP^[3] can have on the maintainability and communication of intent of each option. On one hand, the impact on maintainability of using positional parameters is higher for public methods than for private methods (even higher for published public methods)^[4]. On the other hand, a similar reasoning might be made about the intent of positional parameters: the positional parameters of a private method in a cohesive class might be much easier to understand than the parameters of a public method of a class a client is using, because in the former case we have much more context to help us understand.

The communication of positional parameters can be improved a lot with the parameter name hinting feature provided by IDEs like IntelliJ. In any case, even though they look like named parameters, they still are positional parameters and have CoP. In this sense, parameter name hinting might end up having a bad effect in your code by reducing the pain of having long parameter lists.

Finally, moving to named parameters can increase the difficulty of applying the most frequent refactoring: renaming. Most IDEs are great renaming positional parameters, but not all are so good renaming named parameters.

A second example.

There are also cases in which blindly using named parameters can make things worse. See the following example:

The activate_alarm method presents CoP, so let’s introduce named parameters as in the previous example:

We have eliminated the CoP and now there’s only CoN, right?

In this particular case, the answer would be no. We’re just masking the real problem which was a Connascence of Meaning (CoM) (a.k.a. Connascence of Convention). CoM happens when multiple components must agree on the meaning of specific values^[5]. CoM is telling us that there might be a missing concept or abstraction in our domain. The fact that the lower_threshold and higher_threshold only make sense when they go together, (we’re facing a case of data clump), is an implicit meaning or convention on which different methods sharing those parameters must agree, therefore there’s CoM.

We can eliminate the CoM by introducing a new class, Range, to wrap the data clump and reify the missing concept in our domain reducing the CoM to Connascence of Type (CoT)^[6]. This refactoring plus the introduction of named parameters leaves with the following code:

This refactoring is way better than only introducing named parameters because it does not only provides a bigger coupling reduction by going down in the scale from from CoP to CoT instead of only from CoP to CoM, but also it introduces more semantics by adding a missing concept (the Range object).

Later we’ll probably detect similarities^[7] in the way some functions that receives the new concept are using it and reduce it by moving that behavior into the new concept, converting it into a value object. It’s in this sense that we say that value objects attract behavior.

Summary.

We have presented two examples of CoP, a “pure” one and another one that was really hiding a case of CoM. We have related CoP and CoM with known code smells, (Long Parameters List, Data Clump and Primitive Obsession), and introduced refactorings to reduce their coupling and improve their communication of intent. We have also discussed a bit, about when and what we need to consider before applying these refactorings.

References.

Talks.

Connascence, Fran Reyes & Alfredo Casado (slides)

Books.

Refactoring Ruby, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie

Posts.

Refactoring Ruby: Bad Smells in Code, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie
Ruby 2 Keyword Arguments, Ian C. Anderson
The problem with code smells, Kevin Rutherford
A problem with Primitive Obsession, Kevin Rutherford
About Connascence, Manuel Rivero

Footnotes:

[1] For languages that don't allow named parameters, see the Introduce Parameter Object refactoring.

[2] See Ruby 2.0 introduced keyword arguments.

[3] See our previous post About Connascence.

[4] For instance, Sandi Metz recommends in her POODR book to "use hashes for initialization arguments" in constructors (this was the way of having named parameters before Ruby 2.0 introduced keyword arguments).

[5] Data Clump and Primitive Obsession smells are examples of CoM.

[6] Connascence of Type, (CoT), happens when multiple components must agree on the type of an entity.

[7] Those similarities in the use of the new concept are examples of Conascence of Algorithm which happens when multiple components must agree on a particular algorithm.

Aterrizando en un proyecto con legado

2017-07-24T13:00:00+00:00

El equipo aterriza en nuevo proyecto para evolucionar un producto que lleva 5 años en producción, con un código legado que apenas tiene tests y donde no hay desarrolladores que lo conozcan a fondo. ¿Cómo nos organizamos para aportar el máximo valor?

El contexto hace que unos principios tengan más peso que otros, porque cada situación es particular. Lo primero es evaluar la situación, ponernos en la piel de los stakeholders y usuarios para conocer su realidad. También es importante conocer la historia del producto, las manos por las que ha pasado, el impacto que tiene en la vida de las personas… De los primeros días de toma de contacto conseguimos conocer cuáles son las expectativas de los stakeholders, los riesgos y las metas, sobre todo en el corto plazo. En este post no hablaré de las jornadas de inception del proyecto. Uno de los mayores objetivos es hacer equipo, crear un ambiente de colaboración sana con todas las personas que intervienen en el desarrollo del producto.

Al ser código legacy es imposible hacer estimaciones sobre las tareas porque uno no tiene ninguna tarea que sirva de referencia para hacer estimaciones, por lo cual no merece la pena planificar una iteración con unos compromisos de entrega. Lo que hacemos es montar un kanban con las tareas que son más prioritarias como para tener trabajo para un puñado de días. Para eso evaluamos el impacto en el negocio y la supuesta facilidad de la tarea, buscando aquellas tareas que nos den el mayor beneficio con el mínimo esfuerzo.

La dificultad de esta primera fase es el aterrizaje en el caos y la incertidumbre. Las recetas de los manuales y los libros no encajarán en nuestro contexto. Habrá que tirar de sentido común, de preguntarnos el por qué y para qué de la estrategia que vayamos a seguir.

Los objetivos de esta primera etapa son:

No introducir más bugs. Tener máximo cuidado de no romper nada.
- Al principio no podremos aplicar la regla del Boy Scout todo lo que nos gustaría porque desconocemos el nivel de acoplamiento del código y queremos evitar romperlo a toda costa. Hay que conformarse con pequeños cambios de impacto muy localizado y hacer anotaciones y comentarios para más adelante.
Empezar a cartografiar esa gran masa de código
- Conocer cómo de grande es el código.
- Meter trazas para averiguar qué partes del código están siendo usadas y cuáles no. El objetivo es borrar código no usado en las próximas fases.
- Averiguar en qué zonas hay mayor densidad de bugs.
- Anotar los puntos donde observemos mayores dificultades, ya sea de comprensión, de testing…
- Anotar deuda técnica que encontremos.
- Anotar deuda tećnica que vayamos introduciendo.
- Averiguar cuáles son las funcionalidades de mayor valor y cómo es su código.
- Averiguar si hay zonas útiles pero que no requieren mantenimiento, que llevan mucho tiempo sin tocarse.
- Escanear con herramientas de análisis de código estático para que nos ayuden.
Conocer la infraestructura y los ciclos de puesta en producción
Documentar. Los proyectos no tienen documentación o está tan obsoleta que es inútil.
- Todo lo que echemos en falta para montar el entorno de desarrollo local.
- Todo lo que haga falta para desplegar.
- La arquitectura del proyecto y las convenciones, si las hubiera.
- Añadir comentarios en el código que nos ha costado tiempo entender pero que no podemos cambiar por miedo a romper cosas. Los comentarios en el código son muy útiles en estos casos. Se pueden borrar cuando adquiramos la capacidad de hacer cambios en el código con seguridad de no romper nada.
- Describir cómo se prueba a mano la aplicación para poder hacer pruebas de regresión manual. Algo sencillo como una hoja de cálculo es suficiente como plan de pruebas hasta que vayamos pudiendo automatizar. No hay que hacerlo para todo sino para los casos que sean menos intuitivos o más relevantes.
Ganar la confianza de los stakeholders mostrando resultados visibles a corto plazo
- Si llevaba tiempo sin haber novedades en las releases, lo primero es demostrar que estamos aquí para trabajar por ellos. Evitar que aumente la inestabilidad del sistema por causa de defectos, es justamente lo que merma la confianza.

En definitiva se trata de adquirir conocimiento a nivel global sobre las personas, el producto, el código y la infraestructura. Con este conocimiento, en las siguientes etapas ya podremos hacer mayores cambios en el código y ayudar a planificar releases con conocimiento del tiempo estimado de las tareas.

Arreglar bugs que lleven tiempo reportados es una de las formas que tenemos de empezar a acercarnos al código legado. Se priorizan y se ponen en el kanban. La investigación inicial de esos bugs no tiene por qué ser en pares pero luego la resolución sí. Es especialmente importante hacer pair programming ahora que el código es tan sumamente delicado. Otra opción es dedicarse de tareas que aparentemente sean sencillas como cambiar textos o actualizar alguna librería que haya quedado obsoleta. Conviene medir el tiempo que tardamos en realizar estas pequeñas tareas para que todo el equipo vaya asimilando lo que cuesta cada cosa.

Cuando nos enfrentamos a código legado y queremos dejarlo mejor de lo que lo encontramos, hay que medir muy bien cuánto lo queremos mejorar porque pasado un límite puede que la inversión no merezca la pena. Cuidado con el refactor. En la fase inicial puede que incluso desconozcamos si el código que estamos tocando es relevante para el negocio. Tal vez es una funcionalidad que no se usa. Si este fuera el caso, el refactor sería tirar dinero a la basura porque ni la mejora del código aporta ni el conocimiento que vamos a adquirir nos va a servir. Por otro lado modificar código que tiene muy poco ratio de cambio tampoco tiene un gran retorno de inversión. Nos puede ayudar a entender el negocio pero es preferible borrar los cambios después de haberlos hecho antes que arriesgarnos a romper algo que está funcionando bien. El mejor código para refactorizar es el que nos está impidiendo realizar la tarea en curso. Y lo modificamos lo mínimo necesario para resolver la tarea. En ningún caso dejamos el código peor de lo que está, siempre lo mejoramos aunque sea introduciendo una variable explicativa. Lo que no perdería de vista es que en esta fase inicial, no buscamos explorar en profundo sino en ancho. Buscamos hacernos con una idea global que después nos permita tomar mejores decisiones sobre la economía del software.

Lo deseable es construir una base de conocimiento apoyada de unas métricas que nos permitan llegar a ese día en que podamos ser predecibles y dar información de costes fiable para una planificación que sirva al negocio.

Una de las dificultades será la incomodidad que nos puede generar estar haciendo labores que no son nuestra especialidad. Puede ser que no nos sintamos útiles haciendo tareas de análisis, de documentación, pruebas manuales o hablar con stakeholders… cualquier cosa que no sea programar. Pero nuestro valor más fuerte no está en el código que escribimos. Está en maximizar el impacto del producto y minimizar su coste. Las mejores prácticas de ingeniería no sirven si le dan la espalda al propósito del proyecto. Las dos cosas van unidas.

Un proyecto que lleva 5 años en marcha pasando por diferentes equipos no va a ser domado en menos de un año ni en dos. Hay que tener paciencia y atacar de forma estratégica, dando diferente peso a los principios en función del contexto y rediseñando las prácticas. Poniendo la energía en donde produzca mejor resultado. Nunca hay dos proyectos iguales.

Segundo curso abierto de TDD del año en Barcelona

2017-06-26T16:25:00+00:00

El mes pasado Luis y yo hicimos un curso abierto de TDD en Barcelona. Fue una edición muy interesante en la que probamos algunos cambios en el contenido del curso, y en la que participaron algunos conocidos de la comunidad de Barcelona.

En las últimas ediciones del curso, nos habíamos dado cuenta de que el ejercicio de outside-in TDD, la Bank Kata, que hacíamos el segundo día le estaba resultando muy difícil a los alumnos. En outside-in TDD se usan los dobles de prueba como herramienta de diseño y exploración de interfaces, lo cual resulta muy complicado cuando una persona aún no ha acabado de entenderlos y manejarlos con soltura.

Esta dificultad estaba suponiendo un obstáculo para que acabaran de entender los dobles de prueba. Por ese motivo, decidimos mover el ejercicio de outside-in TDD al principio de un curso más avanzado de TDD que estamos preparando, y hacer otro ejercicio más sencillo en su lugar que les ayudase a asimilar mejor los conceptos.

El nuevo ejercicio que elegimos fue la Coffee Machine Kata. Es una kata muy interesante que ya había probado en un dojo de SCBCN. Creemos que nuestro experimento funcionó bastante bien. Usando esta nueva kata se entiende de forma más gradual y menos traumática cómo y cuándo aplicar cada tipo de doble de prueba. Acabamos muy satisfechos con el resultado de nuestro pequeño experimento y el feedback que recibimos.

Esta edición fue la segunda que hacíamos en lo que va de año, y hubo más gente que en la edición anterior. Esto se debió en gran parte a que vinieron desde Zaragoza cuatro personas que trabajan en Inycom. Muchas gracias por confiar en nosotros.

También nos gustaría darle las gracias a todos los asistentes por su entrega y ganas de aprender. Finalmente, agradecer a Magento, especialmente a Ángel Rojo que nos hayan acogido de nuevo en sus oficinas y toda la ayuda que nos prestaron, y a nuestra compañera Dácil por organizarlo todo.

Testing Om components with cljs-react-test

2017-06-23T12:00:00+00:00

I’m working for Green Power Monitor which is a company based in Barcelona specialized in monitoring renewable energy power plants and with clients all over the world.

We’re developing a new application to monitor and manage renewable energy portfolios. I’m part of the front-end team. We’re working on a challenging SPA that includes a large quantity of data visualization and which should present that data in an UI that is polished and easy to look at. We are using ClojureScript with Om (a ClojureScript interface to React) which are helping us be very productive.

I’d like to show an example in which we are testing an Om component that is used to select a command from several options, such as, loading stored filtering and grouping criteria for alerts (views), saving the current view, deleting an already saved view or going back to the default view.

This control will send a different message through a core.async channel depending on the selected command. This is the behavior we are going to test in this example, that the right message is sent through the channel for each selected command. We try to write all our components following this guideline of communicating with the rest of the application by sending data through core.async channels. Using channels makes testing much easier because the control doesn’t know anything about its context

We’re using cljs-react-test to test these Om components as a black box. cljs-react-test is a ClojureScript wrapper around Reacts Test Utilities which provides functions that allow us to mount and unmount controls in test fixtures, and interact with controls simulating events.

This is the code of the test:

We start by creating a var where we’ll put a DOM object that will act as container for our application, c.

We use a fixture function that creates this container before each test and tears down React’s rendering tree, after each test. Notice that the fixture uses the async macro so it can be used for asynchronous tests. If your tests are not asynchronous, use the simpler fixture example that appears in cljs-react-test documentation.

All the tests follow this structure:

Setting up the initial state in an atom, app-state. This atom contains the data that will be passed to the control.
Mounting the Om root on the container. Notice that the combobox is already expanded to save a click.
Declaring what we expect to receive from the commands-channel using expect-async-message.
Finally, selecting the option we want from the combobox, and clicking on it.

expect-async-message is one of several functions we’re using to assert what to receive through core.async channels:

The good thing about this kind of black-box tests is that they interact with controls as the user would do it, so the tests know nearly nothing about how the control is implemented.</div>

¿Null, vacío o exception?

2017-06-11T10:00:00+00:00

Siempre que imparto una formación aprendo de los participantes. Cuando surgen dudas y debates en el grupo, se abre un espacio ideal para el aprendizaje. Los últimos dos días hemos tenido la suerte de estar con el equipo de Zooplus en Madrid practicando TDD y hablando mucho de diseño de software.

Durante la WordWrap kata algunas personas plantearon casos límite muy interesantes. La firma de la función es esta:

 public String wrap(String text, int columns){...}

Dado un texto de entrada y un ancho de columna, el texto de salida será el de entrada, con tantos saltos de línea añadidos como hagan falta para que todas las líneas tengan una longitud menor o igual al número de columnas.

¿Cómo debería comportarse cuando el primer argumento sea null? ¿y si el primer argumento es texto y el segundo es cero? ¿y un número negativo? y… ¿qué pasa si el primer argumento es null y el segundo es un número negativo?

Son decisiones de comportamiento que hay que tomar. En la conversación había opiniones muy dispares y no llegamos a ningún consenso. El motivo creo que se debe a la falta de principios sobre los que sostener nuestras hipótesis, lo cual hace que parezca una cuestión de gustos algo irracional. Si consensuamos unos principios es más fácil decidir cuál es el comportamiento más adecuado.

Para mí el principio más importante de todos es el de menor sorpresa, no me gusta que el código me sorprenda. Pero además de este necesito otros para tomar estas decisiones:

Simplicidad
Responsabilidad única
Consistencia lógica
Resiliencia
Evitar propagación de nulos
Evitar propagación de excepciones de las que nadie se puede recuperar
Evitar números mágicos

Para mí que el texto sea null es lo mismo que si llega vacío, es ausencia de texto y por tanto veo lógico que la respuesta sea texto vacío. No devolvería null porque la experiencia me dice que los nulos dan mucha guerra. Obligan al llamador a defenderse del nulo, propagando la molestia por todo el código hasta que alguien acabe con ella por algún lado. Es extraño que venga null pero no quiero dar a esta función de bajo nivel dos responsabilidades, la de validación y la propia de wrap que ya tiene. Si quisiera darle la responsabilidad de validación podría lanzar una excepción en este punto. Pero el lanzamiento de excepciones también se progaga por el código como los nulos e incluso peor.

Aquí entra en juego la experiencia que uno tiene enfrentandose a escenarios de ejecución donde ese texto llega a null. Y en la mía estos casos son realmente casos límite. Si he programado todo con TDD desde afuera hacia dentro, habiendo programado primero el llamador de esta función, yo ya sé que mi código no genera ese null a propósito en ningún caso. Por tanto ha de venir de algún caso límite que no he tenido en cuenta. No puede venir de ningún “happy path” porque esos los tengo todos testados. Es muy probable que ese caso límite venga de algún campo de la GUI que se quedó vacío o se le dió un uso inesperado. Si este es el caso, devolver null o lanzar una excepción provocará muy posiblemente que el programa se interrumpa o el usuario vea un error extraño en pantalla. Sin embargo, si devuelvo un texto vacío eso no ocurrirá. Igualmente no va a arrojar ningún resultado pero no dará error. En mi opinión estamos ganando en resiliencia del software. Puesto que soy capaz de darle un sentido lógico a la entrada de un texto nulo y responder con vacío sin causarle sorpresa al lector del código, esta es mi opción preferida. Se comentaba como alternativa que la función podría devolver un “Optional” para posponer la decisión o delegarla al llamador. De alguna manera un tipo opcional sirve como patrón null pero al igual que antes prefiero atajar la situación y frenar la posibilidad de que la burbuja polucione hasta muy arriba.

Ahora supongamos que el texto es una cadena no vacía pero que el número de columnas es cero o negativo. No se me había ocurrido nunca este caso. Si no hay ningún tipo de tratamiento de cero y negativos se provocaría una excepción, seguramente de índices, interrumpiendo el programa. Ante cero o negativo no se me ocurre ninguna respuesta lógica que pueda dar para salir del paso. Verdaderamente no sé cómo procesarlo y solo me queda detener la ejecución. ¿Entonces chequearía el parámetro para lanzar una excepción de validación? Si se trata de mi código y quien lo va a invocar somos nosotros del equipo de desarollo no lo haría. Porque no quiero validaciones en este nivel sino que la función tenga la responsabilidad de partir el texto y nada más. Cuando se produzca la excepción no controlada tendremos acceso a toda la traza y será fácil entenderla. Lo que sí haría es pegarle una revisión al código que va a llamar a esta función para estudiar si allí conviene validar o evitar que eso se produzca. La mejor solución que se me ocurre para quitarnos toda esta problemática es dejar de usar tipos primitivos en la firma de la función. A menudo pecamos de polucionar nuestro núcleo de negocio con primitivos que carecen de la expresividad que necesitamos. La solución sería una firma como esta:

   public Text wrap(Text text, ColumnWidth width){...}

Si el tipo Text implementa algún tipo de patrón vacío o null nos quitamos uno de los problemas. Si el tipo ColumnWidth sólo admite números positivos nos quitamos el otro. Los primitivos son imprescindibles en los límites de nuestro dominio, para interactuar con el exterior, pero dentro de nuestro dominio deberiamos usar nuestros propios tipos dotados de una semántica clara y sin lugar a errores.

Por otra parte si la función es parte de una librería de propósito general que voy a exponer al mundo, preferiría dejar los primitivos y sí que lanzaría una excepción de validación que indicase claramente que ese parámetro no puede ser cero ni negativo. A quien usa una librería le va a resultar muchísimo más fácil darse cuenta que se está equivocando al invocarla si somos explícitos sobre el error. StackOverflow está lleno de gente preguntando por mensajes de error en librerías y frameworks que no son bugs sino un uso erróneo de los mismos, que no fue anticipado por los autores.

Por regla general, sólamente uso excepciones cuando soy incapaz de seguir adelante con la ejecución. Y no veo diferencia entre el cero y los negativos. Algunas personas comentaron que se podía entender que el cero significa “no partir lineas” pero yo evito codificar comportamientos con números mágicos. Por eso descarto esta opción, ya que obliga al llamador a conocer demasiados detalles de implementación.

¿Y si el texto es null y el número de columnas negativo?

Si he decidido no lanzar excepción ante números negativos la función devolverá vacío sin más. Si he decidido controlarlo, entonces por consistencia, cuando el número es cero o negativo lanzaré una excepción que diga que no se puede interpretar ese valor por más que el texto sea nulo.

¿Estamos de acuerdo en estos principios? Si no te gustan tengo otros :-)

Testing tricks for react-redux

2017-06-08T16:00:00+00:00

We are using enzyme and jsdom to write both, integration and unit tests for react-redux apps. Although enzyme’s shallow is very convenient totest components in isolation, the truth is that often those components have children that need to be rendered in order for the parent to do something meaningful so we end up using enzyme’s mount most of the time.

When there is no logic in the component, I want to test the integration with actions, reducers and the store. Otherwise tests don’t provide me with the sense of safety that I am looking for. The top one difficulty when integrating these pieces is the asynchronous nature of redux - tests finish before the expected behavior occurs.

Using the “done()” parameter provided by mocha or jest plus “setTimeout()” in the test is not a reliable combination. The way I do it is spying on certain component or subscribing to changes in the store in order to call “done()”, as explained in previous posts. But if you call “done()” before the expectation, it finishes and no expectation is executed. On the other hand, if the expectation fails “done()” is never called and the test fails with a timeout.

This is a helper function to work around the issue:

where expectation is a callback. That could be used like this:

Things start to get messy if the store is updated several times during that test, as the listener will be invoked when the data is not in the expected state yet. When that happens is time to re-think the design of the system and strive for simpler options.

Sometimes asynchronous tests fail with a timeout because there is some unhandled promise rejection. The console prints out this warning:

 (node:9040) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 97): Error: ...

It’s possible and very useful to configure node so that when rejection happens the execution stops printing the stack trace:

Invoke the function before running the tests.

Apart from asynchronous tests, other issue we had was testing changes in the URL, in the browser history. We have a component that changes the query string when submitting a form. It does not post the form. The same component parses the URL every time it changes or when it loads looking for changes in the query string in order to make requests to the server. The query string serves as a filter. After spending sometime, I didn’t know how to simulate changes in the location with jsdom. All I got were security exceptions so changing the browser history was not a working option unfortunately.

To work around this, given we are using react-router-redux and enzyme’s mount, we connect a stub router to the component explicitly as shown below. Basically react-router-redux connects the router with the component for you by adding a “routing” property to the component that maps to “state.routing” thus causing component’s _ “componentWillReceiveProps”_ to be executed as the router handles a change in the location. In the tests, I have to make this mapping explicitly because the router does not work with jsdom as far as I have researched. The code below will be part of the test file:

The factory - production code:

It’s quite tricky to be honest but it exercises the production code exactly as running the application manually. The code snippet in the test file is not complete as you can imagine, only the relevant lines appear.

Another difficulty we run into recently was simulating a scroll event. At the time of this writing, apparently jsdom does not implement a way to simulate scrolling so calling simulate(‘scroll’) does nothing. To work around this, I invoke the event handler directly as it’s a public method on the component. Well, it’s public because ES6 classes don’t implement private methods. Instance methods can be accessed through enzyme’s _“instance()”, method on the wrapper object. However this method works only on the parent component. If you want to access a child component it gets more tricky. It could be the case of a component that should be child of a draggable in order for drag & drop to work:

The instance of the component under test is the first node.

Eventazo Startupero en Zaragoza, ahí estuvimos.

2017-05-25T08:25:00+00:00

Con un poco de retraso llega este post-celebración del paso de Codesai por el SOSZ en Zaragoza.

Yo, personalmente, nunca había tenido la oportunidad de acudir al SOSZ y este año lo tenía marcado con un corazón en el calendario. Me llamaba la atención por varias razones:

no era en Madrid, lo que últimamente creo que es algo a agredecer y apoyar,
era sobre Startups, un sector con el que queremos desde Codesai tener más relación, y
está organizado por la muchachada aragonesa, que ya solo con eso había que ir a verlo.

Así que nos animamos Alfredo Casado y yo a ir a conocer tan prometedor evento.

Tras un viernes noche de bienvenida que no defraudó en absoluto, comenzó el sábado bien temprano, un Open Space facilitado por Pablo Jimeno de manera a mi parecer fantástica. La justa proporción entre humor y trance para ponernos a todos a punto para la desconferencia.

Las propuesta de sesiones fue muy variada: Temas como financiación, crear empleo, tarifas en tecnología, la España rural, … , dándonos una visión que creemos bastante realista de las necesidades del panorama actual.

Las sesiones fueron muy animadas en su mayoría, aunque algunas de ellas hasta demasiado. Salas masificadas, hacían que no se pudiese llegar a profundizar y concluir el tema como debería.

Pablo Jimeno en su sesión hizo un gran intento de mejorar este problema que estábamos teniendo con la participación y yo creo que le salió muy bien. El tema, la conciliación familiar en este trabajo que tenemos tan absorbente, fue de las que más me tocó y me gustaría dedicarle un artículo específico. Si los que tenemos familia podemos ir a eventos, es porque alguien se está haciendo cargo en ese momento de nuestras obligaciones y hay que agradecerlo.

Otras sesión interesante, fue la que propusimos Alfredo y yo: “El equipo tecnológico, ¿mejor dentro, o fuera?”. Fue una conversación muy animada, dónde estuvimos de acuerdo en este resumen ejecutivo: Cuando estás al principio, necesitas que alguien te guíe, cuando ya estás más lanzado, es importante que ese conocimiento quede en la empresa.

Y también a destacar las sesiones: “Emprender en la España (rural) vacía” y “Creación de empleo de las Startups en comparación con la gran empresa”.

Después del evento fuimos a La Jamonería, lugar de culto de los maños, que no defraudó en absoluto. Además tuve ocasión de hablar un buen rato con el dueño, Félix, que me hizo un pequeño resumen de su interesante historia de emprendedor atípico.

Y así cerramos uno de lo eventos más interesantes a los que he asistido últimamente.

Me llevo un gran descubrimiento: el hecho de conocer a muchos participantes, a priori me hizo pensar que íbamos a hablar de temas técnicos. Pero fue todo lo contrario, solo se habló de negocio, haciendo visible una faceta que no había visto hasta ahora.

Dácil Casanova se une a Codesai

2017-05-18T08:00:00+00:00

A pesar de que se constituye en 2015, Codesai es para mí una vieja conocida. He atendido expectante a su gestación en estos trece años que hace que conozco a Carlos Blé. Existen muchas historias antes de su nacimiento, muchas pruebas, muchos sueños y muchas ganas de hacer las cosas de una forma diferente.

Por eso, aunque mi incorporación oficial se produce ahora, siento que hace mucho que nos acompañamos.

Lo que sí es cierto es que no esperaba en absoluto la calidad humana del equipo que conforma Codesai. Bueno, no es que no lo esperara en absoluto, a algunos de los chicos ya los conocía y sabía de sus cualidades personales pero no había tenido ocasión de ver cómo se desenvolvían laboralmente. Este año he podido asistir a una de las reuniones en las que se convoca a todo el equipo para debatir acerca de a dónde vamos, cómo vamos y qué esperamos. Los internamente famosos “Flejesai” Así pues, los días 18 y 19 de marzo los pasamos recluidos en una sala acondicionada para ello en un hotel de Madrid. Fue muy intenso pero muy alentador, es grandioso ser consciente de que Codesai no busca maximizar el beneficio sino maximizar el bienestar y más grandioso si cabe es ver cómo el equipo rema a una, cómo la empresa no es más que el mero reflejo de aquellos que la componen. Se han tomado muchas decisiones, la mayoría se revisará en el próximo Flejesai, algunas pasarán a formar parte de nuestro modus operandis y otras se desecharán. No existe miedo al cambio, mejor dicho, sí que existe pero simplemente se le hace frente. Creo que la vida en sí misma se ha encargado de gritarnos lo importante que es ser versátil pero nos empeñamos en no escucharla, en meterle calzador a todo, en evitar ser muy reactivo.

Personalmente, ha sido de las experiencias más enriquecedoras que he vivido en un trabajo. Ha supuesto una ruptura total de esquemas. Mi educación como economista no me permitía ver a la persona jurídica como una extensión de la física, los objetivos de la primera no podían ser expresados en algo diferente a unidades monetarias. Ahora empiezo a comprender que la entidad mercantil puede llegar a ser un ente orgánico, con sus valores, sus principios y, en definitiva, con su alma. Me ha ayudado mucho leer acerca de esto en el libro de F. Laloux, Reinventar las organizaciones, pero lo que más me ha motivado, siento repetirme, ha sido la implicación de cada una de las personas que dan vida a Codesai. Gracias a todos por este aporte de energía!!!

Empezamos el camino

Manuel J. Tordesillas joins Codesai

2017-04-13T06:00:00+00:00

It has already been two months since I had the opportunity to become a member of Codesai and I cannot express with words how happy and grateful I am after joining this incredible group.

I have always considered myself as an optimist and nonconformist person, continuously looking ahead and being certain that there is something better out there for us programmers. When I found myself without the knowledge, practice and skill to lead a change from within the organisations I was working for, I decided to have a break to start building the skills required to take such a challenge in the future.

Amongst all good practices, I consider testing a cornerstone for any good and sustainable development. To improve my testing skills, I contacted Carlos to attend their TDD open course in Madrid. I had met him in the Agile Open Space 2013 in Tenerife where I was introduced to Agilism, Open Spaces and katas, being greatly impressed by his knowledge and humility.

After a few talks with Carlos, he offered me to join Codesai as an apprentice and I did not have to think twice about it, I had already decided from the moment he offered! I have to say, it feels like one of the best decisions I have taken in the last few years. Codesai is not only a company with developers that are well known by the community and the industry, we are a group of human beings with aligned purposes and goals that want to make both the world and the industry a better place.

Following Codesai’s spirit of sharing knowledge and teaching, I am currently being mentored by Manu Rivero. We are having weekly sessions to explore concepts and practice skills that are essential for the craft. You can follow our progress at our github repos: Pair of M’s

I joined Codesai because I wanted to learn, I have learned many things already and so many are there waiting, still to be learned. However, I found more than knowledge, I found a group of great people that inspire me every single day.

Thank you for letting me in! :)

Estuvimos en Velneo (VisualMS)

2017-04-12T06:00:00+00:00

El pasado 7 y 8 de marzo de 2017 estuvimos Manuel Rivero y yo, impartiendo un curso de JavaScript para la empresa Velneo, en sus oficinas de Gijón. Estuvimos 10 personas tanto de Velneo, como de otras empresas del grupo.

Este post no sería más que una nota de nuestro día a día, si no fuera porque el empujón definitivo para escribirlo vino de una noticia que salió esta semana. VisualMS (el grupo al que pertenece Velneo) fue reconocida como el mejor lugar para trabajar de España, primer premio Best Place to Work 2017, en la categoría de empresas de 50 a 100 empleados.

Y no nos extraña en absoluto, se nota que tienen una relación especial entre ellos, disfrutamos muchísimo ese par de días compartiendo tiempo y espacio con un grupo de personas fantástico.

¿Qué es Velneo? Pues con mis propias palabras. Velneo es un entorno para crear ERPs. Sus clientes son empresas de desarrollo que configuran, adaptan y amplian, el producto para un cliente final. Puede ser una fábrica, una administración o una compañía de seguros. Han visto que su punto más valorado es la comunicación en español y tienen una fuerte presencia tanto en nuestro país, como en Latinoamérica.

Hablando ahora un poco del curso, fue interesante porque hicimos un contenido ajustado a sus necesidades basado en JavaScript ES5. Actualmente el motor que tienen integrado en el producto no soporta ES6, pero no vimos problema, pues en Codesai somos muy fan del patrón módulo o del patrón Function As Object, por ejemplo.

El curso fue una combinación de teoría y práctica en forma de katas usando TDD. Era un equipo que nunca lo había practicado y se notó que lo pasaron en grande, programando en parejas, pensando los ‘baby steps’, y consiguiendo unos verdes preciosos.

La valoración del curso en general fue muy alta (nos pusieron un 9 de media, ¡gracias!), y además nos dieron un feedback muy valioso. A destacar nos comentaron que hubiesen sacado más chicha de las katas si el tema fuera más alineado con su negocio, pues tardaban demasiado en comprender lo que se quería conseguir. Usaremos este conocimiento sabiamente.

Hemos recopilado la bibliografía que usamos para crear el curso y que también sirve para ampliar conocimientos. Está disponible aquí: Bibliografía del curso

También recopilamos todos los ejemplos que usamos en este repositorio de Github.

Gracias a todo el equipo de Velneo por esta gran experiencia y esperamos coincidir pronto en otros proyectos.

Estuvimos en Women Tech Makers Madrid

2017-04-10T08:00:00+00:00

El equipo de Codesai asistió el pasado 11 de Marzo al Women Tech Makers (WTM) Madrid 2017. Women Techmakers es una iniciativa liderada por Google, que se está expandiendo a un programa a nivel mundial. Con motivo del Día Internacional de la Mujer, se promueven diferentes eventos alrededor del mundo con el objetivo de dar a conocer el trabajo y el conocimiento de las mujeres en el sector técnico.

La organización del evento fue estupenda, estuvieron en todo momento pendientes de que todo estuviera perfecto y que no faltase de nada. ¡Muchas gracias!

Hubo desayuno y almuerzo incluído, donde tuvimos desde churros con chocolate por la mañana, hasta una pequeña variedad de pequeños snacks a la hora de la comida.

Destacar la gran participación que hubo en las charlas y el nivelazo en general. Tenemos grandes desarrollador@s en España….

Asistimos a las siguientes charlas:

BIG DATA & DATA SCIENCE : ¿POR QUÉ TODO EL MUNDO HABLA DE ELLOS?

Inés Huertas nos desveló algunos de los secretos sobre Big Data, una de las disciplinas que más atención están levantando en los últimos años. La industria genera una inmensa cantidad de datos de todo tipo que los Data Scientists se encargan de preprocesar, modelar y validar. Una vez validados sus modelos, pueden encontrar patrones, realizar labores de predicción con un alto porcentaje de acierto o aplicar técnicas de machine learning. Optimizar la frecuencia del transporte público, descubrir nuevos segmentos de mercado o interceptar al consumidor antes de abandonar tu tienda online son algunos de los ejemplos de aplicaciones prácticas que descubrimos en la charla.

EL DESPERTAR DE LA ZONA DE CONFORT

Laura Lacarra se encargó de sacarnos de nuestra zona de confort con una charla muy divertida y con un mensaje con el que en Codesai nos sentimos muy identificados. Laura nos habló de lo peligrosa que es la zona de confort y lo que hace falta para salir de ella y seguir evolucionando como profesionales. También nos habló de la importancia de las comunidades a la hora de compartir conocimiento y de mejorar nuestra industria.

CÓMO ME HE REINVENTADO COMO PROGRAMADORA WEB FRONT-END EN 3 MESES

Rocío Gómez y Fina Pérez nos hablaron sobre el programa de Adalab. Adalab es un proyecto que impulsa a mujeres jóvenes con dificultades de empleabilidad para que se conviertan en profesionales líderes del mundo digital. El programa consiste en dar una formación durante 3 meses sobre tecnologías front-end, seguida de unas prácticas en empresas para consolidar dichos conocimientos previamente adquiridos y así empezar a conseguir experiencia profesional. Durante los 3 meses, a cada alumna se le asigna una mentora que le guiará y ayudará en los problemas que puede encontrar a lo largo del camino el aprendizaje. Además, tendrán varios profesores que les enseñaran las distintas herramientas y buenas prácticas con las que trabajarán en su día a día.

INTERNET OF THINGS PARA TODOS ¿QUÉ COSAS PODEMOS HACER CON LAS COSAS?

Marta Beltrán nos introdujo al fascinante mundo del “Internet de las Cosas” (IoT). En esta charla descubrimos el estado actual y todos los retos que aún quedan por delante para alcanzar un mundo en el que todos los dispositivos imaginables estén interconectados. Nos llamó mucho la atención lo avanzadas que están muchas industrias en este campo y la gran cantidad de estándares y tecnologías que ya existen y están siendo usadas. Los retos de seguridad que se plantean al tener todo inter-conectado parecen apasionantes.

¡LA TECNOLOGÍA TAMBIÉN ES COSA DE NIÑOS!

¡Una pequeña gran ponente! Alejandra, junto con la ayuda de sus padres, nos contó todo lo que había aprendido y sigue aprendiendo sobre la tecnología gracias a su fantástico robot JIMU. Un dinosaurio que ha tenido una aventura épica, la cual nos iba contando Alejandra mientras que JIMU se movía y bailaba.

También asistimos a un taller:

TALLER: ¡ÚNETE A LA REBELIÓN DE LOS BOTS Y LA INTELIGENCIA ARTIFICIAL!

Gisela Torres nos hizo una introducción a los bots y a la inteligencia artificial, enseñándonos a crear nuestro primer bot que sea capaz de responder a las típicas FAQs de nuestra web. Para ello, nos enseñó su propio bot, muy chulo por cierto, donde simulaba un escenario donde la web era una compañía aérea y se nos perdía el equipaje. El bot nos ayudaba a que nos dejase nuestro equipaje en la ubicación que nosotros le indiquemos, haciendo uso de una verificación de dos pasos con un sms, y al resolver la incidencia era capaz de detectar nuestro estado de ánimo, y como simulamos que estábamos enfadados, el bot nos invitaba a entrar en la zona VIP la próxima vez que fueramos al aeropuerto debido a las molestias causadas.

Estuvo muy divertido el taller y aprendimos bastantes cosas que podemos hacer para explotar todo el potencial de los bots y de los cognitive services de Microsoft.

Slides del taller:

Post - Enseña a tu bot las FAQs de tu empresa con QnA Maker

Muchísimas gracias y felicidades a l@s organizador@s del WTMMadrid. ¡El evento fue espectacular!.

Types of actions in a Redux App

2017-04-05T19:00:00+00:00

In the previous post there was a bunch of tests but not the code that make them pass. In the way we’re building apps with Redux, there are different kinds of actions and creators injected in the components. We usually talk just about actions without distinction. These are the various kinds:

Redux action - a plain object: {type: ‘SOME_NAME’, data: someData}

Redux action creator - a function returning an action:

  function actionCreator(){
      return {
          type: 'SOME_NAME',
          data: {some: 'data'}
      };

Potential asynchronous action creators - supported by redux-thunk:

  function middlewarePoweredActionCreator(){
      return function(dispatch){
           return dispatch({
                  type: 'SOME_NAME',
                  data: {some: 'data'
           });
      };
  }

Non-redux related actions:

  function nonReduxAction(fetch, data){
      return fetch(url, {
                  method: 'POST',
                  body: JSON.stringify(data)
              })
              .then((response) => {
                  return Promise.resolve(response.json());
              });
      });
  }

There are situations where the store’s state is not going to change, so there is no need for a reducer. If I just want to send some data to the server, I don’t need the Redux machinery. I just post data from the component to the server through my non-redux-related action. In the previous post about the factory I explained how to map actions to the component. Action creators connected to Redux must be dispatched whereas non-redux actions must not.

Asynchronous action creators are needed when data needs to be fetched from the server or sent to the server and passed through the reducers thus changing the store’s state.

Populating store with data from server:

Processing data and changing the state before sending it to the server:

Redux-thunk middleware provides two arguments to the function, dispatch and getState. The first one triggers the reducers process and the second gets the current state from the store.

Action creators are just functions, they can be easily tested in isolation although we usually test them in integration as described in previous posts.

Testing strategies in Redux

2017-04-05T18:00:00+00:00

In the previous post I explained how to test-drive a Redux app from the outside-in with an example of a coarse-grained test integrating most of the frontend layers. That was just one case but there are more cases, more kind of tests. These are the common things I like to check in my tests:

GUI events or componentDidMount ends up with…
- consistent changes in the store’s state.
- consistent changes in the component’s state.
- an async call to server, which response is properly handled.
- no action calls at all, just display validation errors instead.
- router redirections.
Store’s state is correctly rendered in the GUI

Most of the items in the list are testable in integration using Enzyme’s mount function. Others however are better tested via Enzyme’s shallow, in fact I’ve experienced situations where testing with mount is not possible because the component’s state is not accessible for instance or because the behavior is unpredictable.

Let’s see an example. In our app, the component has a notifier object injected intended to show user messages such as the beginning of a potentially slow operation or the end of it. As some actions are is asynchronous, the test has to wait for all the things we want to happen. Waiting is possible thanks to the done argument provided by the test framework - jest, mocha, jasmine…

When the expectation is not met, the test fails with a timeout because done is never called. However the failed expectation is also shown in the console. It’s a bit tricky because one have to scroll a bit to reach the actual failure reason in the output.

We could further refactor the test above to make it less verbose and easier to change:

The next scenario is similar just a bit more complex. When the component loads, it must fetch data from server to populate the store with it. This is done inside componentDidMount.

The action is async, data is fetched from server and then dispatched via Redux. Thanks to redux-thunk middleware, the promise is resolved once the store has been updated. This is why we can expect the GUI to be refreshed. In the next blog post I’ll write about the various kinds of actions. The test can be refactored like before. I leave that for you.

We could have written a finer test in terms of scope. We could have been checked that server data has populated the store correctly:

We’ve got access to the store instance so we can subscribe to it and make assertions with the final state. Which test is best? it depends on several aspects. I prefer to test-drive with coarse-grained tests but if I feel the need to debug despite of writing small tests, I go for a finer test like this. It’s a trade-off, confidence, brittleness and ease to understand and fix.

There are occasions where checking the store is the only choice. One example is the logout page:

On line 8 I expect the store to be properly populated, before exercising the code under test. As the logout action could be asynchronous, I wait for the store to change via subscribe and then make the assertion.

Up until now all the tests are mounting the component and running asynchronous tests. This technique is good enough when components are simple. Once they get more complex, for instance when they manage itw own state calling this.setState, small isolated tests are required. In these tests I usually stub or spy on actions thus testing the component in isolation. The next example tests a form that dynamically renders input text boxes for every email in a list of emails:

If one of the emails is going to be removed from the list using the form, I want to make sure the action receives the correct list:

Synchronous tests are easier to reason about.

I’ve experienced unpredictable behavior mixing both, synchronous and asynchronous tests in the same suite when the system under test contains components that manage their own state. It’s important to remember that React’s setState is asynchronous although the name of the function doesn’t look like it is. I haven’t got the time to analyze the problem and see whether it’s in React Test Utilities, in Enzyme,… but I just try to keep those tests in separate test suites.

Test-driving a Redux App

2017-04-05T16:00:00+00:00

I like starting every new feature with a failing coarse-grained test that exercises most of the layers I’ll have to cross in order to get the feature done. During that cycle I may write smaller tests to get faster feedback. Pretty much anytime I feel the need to debug my big test, I rather write small tests to confirm that smaller chunks of code work as expected. Some of those tests will stay when development is done and some others will be deleted, they are used only as a scaffolding mechanism. This is one way to approach outside-in TDD. In a frontend app, the boundaries of the system are the server API and the GUI. I usually stub or spy on the server API - a simple AJAX client. However I do use the actual GUI, well, in the case of React the wrapper provided by Enzyme’s mount, because it’s fast anyway and gives me a feeling of realistic behavior. The server API is pretty much the only thing I mock, for everything else I prefer to use the actual artifacts.

For the Profile Page described in the previous post, this would be a good test to start from:

Initially the store contains an empty profile to render the page. At the beginning of the test I wait for the profile to be retrieved from the server. I assume the download is finished as soon as the notifier is called to let the user know about the end of the request. At that point the action should have been dispatched by Redux and I can assert that the form renders the server’s data. Here I am stubbing out the query to the server and spying on the notifier method which is a void function.

In order to make this test pass I must write the action, the reducer and the method in the component. Notice that I am using the factory we saw in the previous post. This would be the code required by the component:

The test above covers the factory which includes the call to connect thus testing mapStateToProps and mapDispatchToProps. It also covers the stores’ configuration and the component including all its children. It integrates pretty much all the layers. Only routing and server side are left out. It’s fast to run and gives me a lot of confidence. I can write additional fine-grained tests for the reducer in isolation or the component using Enzyme’s shallow. In fact, as we’ll explore in an upcoming blog post, Enzyme’s mount is not the best fit for components that handle their own state calling React’s setState.

In case you miss it, this is the rest of the code required by the test:

The action creator above requires react-thunk middleware to work.

Dependency Injection in Redux

2017-04-05T08:00:00+00:00

Redux provides a function called connect that binds the component to the store. This is the place where state and actions are map to component properties and also where the component subscribes to changes in the store. Well, the subscription happens as long as React’s Provider is in place:

We invoke connect from our component factory. An example:

The production code would import ProfilePage - last line. Tests will import and use createProfilePage in order to inject test doubles to mock the API and other dependencies like the notifier - a simple wrapper around an alert dialog. The first connect argument is the function that maps the global state to the component’s state. The second argument makes actions available to the component. We distinguish two kind of actions. Those that impact on the state and those which don’t. If the action is going to be processed by a reducer that in turn is going to change the state, then a call to dispatch is needed - lines 18 & 24. In fact those functions are action creators, they return an object or another function to be dispatched asynchronously with the help of thunk middleware. Function dispatch is provided by Redux, like connect. On the other hand if the action does not alter the state of the frontend app, we just invoke it and return it’s result, which is typically a promise - line 21. We are not using the helper function bindActionCreators from Redux to make it explicit where we need its machinery and where we don’t

In both cases, closures hide the fact that actions require the serverApi to work, making its usage simpler for the component - the consumer. ProfilePage component will invoke the action like this:

I am far from being a Redux expert and I guess some people will find it unusual to not call dispatch every time. Notice that saveProfile is not an action creator but just a function that return a promise. However I find this code simpler, I don’t see the point in going through a reducer when the state is not going to be changed.

Actions and action creators:

Given this factory, in the next blog post I’ll explain how we test-drive the app from the outside-in, as well as the various kind of tests.

Getting started with React & Redux

2017-04-03T08:00:00+00:00

I started learning React and Redux about two months ago. Following the recommendation of my colleagues Dani, Miguel & Ronny, I went to Pluralsight to study from the great training courses carefully crafted by Cory House.

We first watched the introduction to React and Flux. I did not practice with the exercises proposed, just watched the episodes at the maximum speed I could. It’s nice to be able to configure the player’s speed to 1.7x or 2x.

Once I understood React and the Flux pattern I went to the next course on React and Redux.

This time I downloaded the repository that Cory’s got for this course, called Pluralsight-redux-starter and played with the examples along the way. I appreciated specially the episodes in testing since I am a test infected developer and I feel the need for tests as soon as I get started with the development.

Cory has a terrific code repository called React-Slingshot that served us to boot our first Redux project. It’s similar to the Pluralsight Starter but production ready, with an incredibly powerful Webpack setup including all the tests harness, hot reloading, Babel… The repository includes cutting-edge libraries and works perfectly on Linux, Windows and Mac. Ready to work with ES6 which is the JavaScript flavour we’ve been using in the last two years. It saved us a lot of time, I am very grateful Cory!

In the course there is an example where Cory tests a component through the Redux Provider. This one example has been very useful for us because we like to do Outside-in TDD and testing from the Provider allows us to write integration tests that cover the factory and Redux’s connect with our implementations of mapStateToProps and mapStateToActions.

In the following blog post I’ll explain our Outside-in TDD strategy together with the dependency injection which are building blocks that are not covered by the courses.

Stay tuned!

By the way, at the time of this writing there is an offer by Microsoft. Registering at Visual Studio Dev Essentials gives you free access to Pluralsight for three months.

Estuvimos en Biosystems

2017-03-26T10:25:00+00:00

Hace algunas semanas estuve impartiendo el curso de TDD de Codesai en las oficinas de Biosystems en Barcelona.

Se trata de una empresa que lleva más de 30 años investigando, desarrollando y fabricando sistemas analíticos de diagnóstico clínico y agroalimentario para laboratorios de todo el mundo.

Les visité en época de cambios, con nuevos proyectos arrancando, en un momento muy interesante porque las mentes estaban abiertas y había muchas ganas de aprender y compartir.

Posiblemente el motivo de que nos llamasen fue que algunas personas del equipo como Ana Carmona me conocían de eventos como la CAS2015 o la CAS2016 y propusieron a la empresa que nos contratasen. A menudo entramos en las empresas así, por sugerencia de algún miembro del equipo que habla de nosotros a las personas que tienen poder de contratación dentro de su organización.

Lo mejor de todo fue el trato tan cercano y cálido que me brindaron desde el primer momento. No solo durante el trabajo sino después poder irnos juntos a cenar e incluso recogerme en coche para ir hasta la oficina o acompañarme hasta el tren de regreso a casa. Sin duda el equipo humano de Biosystems es excepcional, son el mayor tesoro de la organización.

Desarrollan en el mismo edificio absolutamente todas las piezas de sus productos, tanto el hardware como el firmware como el software. Nada de externalizar la fabricación a otros países, es todo made in Barcelona. Además de la formación estuve como consultor estudiando con el equipo cómo se podrían automatizar los tests de todas las partes, incluyendo los end-to-end que validasen que el software se comunica bien en el firmware y que éste a su vez coordina bien toda la electromecánica de las máquinas. Máquinas muy complejas con varios brazos robóticos que toman muestras, las mezclan y las analizan. Me quedé alucinado cuando ví una de las más grandes desmontada y funcionando, o sea cuando le vi las tripas, sin la carcasa. Estas máquinas operan en tiempo real, cualquier mínimo retraso del firmware provocaría que los brazos colisionasen. Los tests end-to-end manuales son muy costosos porque los procesos pueden durar hasta 15 minutos ya que las máquinas tienen programas de inicio que limpian los inyectores, etc. Por todo ello el reto es muy grande. Lógicamente se están haciendo tests de piezas separadas que hablan con fakes y otros tipos de mocks. Los siguientes pasos son muy interesantes pero no los desvelaré por si se trata de información reservada.

El equipo de ingenieros que desarrolla el firmware tuvo la amabilidad de dedicarme una tarde para mostrarme el código fuente, hecho en lenguaje C, las herramientas de desarrollo, el hardware y la problemática a que se enfrentan. Aproveché para hacer preguntas sobre cómo plataformas como Raspberry o Arduino afectan a la industria, a lo que ellos, aparte de ver que no tengo ni idea de hardware ni firmware, me respondieron que en la industria ellos tienen que comprar piezas industriales (chips, buses, etc) a empresas que les garantizan que al menos por 10 años van a encontrar repuestos. Sus máquinas se diseñan y fabrican para que duren toda la vida. Tienen laboratorios donde hacen pruebas de duración de las diferentes piezas mecánicas, las ponen a funcionar hasta que se rompen para garantizar su calidad.

Usan buses de comunicación de la automoción por su probada estabilidad y resistencia. La gran variedad de chips a elegir y su complejidad (los manuales con los juegos de instrucciones y las patas dan miedo) hace que se necesite muchísima investigación y pruebas para armar las máquinas más robustas posibles. Me contaron que la arquitectura ARM sí está siendo el revulsivo en el sector, al abaratar y simplificar el diseño de chips, permitiendo que salgan cada vez placas más potentes que ocupan poco espacio. Parece que la tendencia es hacia poder usar C++ en más áreas del firmware y disponer de librerías de más alto nivel que reducirían mucho la complejidad actual, incluso con posibilidad de correr Linux. Unido al IoT (Internet de las cosas), el futuro se prevé muy interesante.

La parte software lo que hace es programar los diagnósticos, casando las muestras de los pacientes con los líquidos reactivos que corresponde usar para diagnosticar enfermedades. Software y firmware se comunican mediante eventos.

La colaboración entre los distintos equipos de ingeniería es estupenda, estoy seguro de que se van a seguir superando a sí mismos constantemente. Así que estoy muy contento de haber pasado por allí para compartir y aprender.

Ha sido un placer!

Estuvimos en DeveloperOS Madrid 2017

2017-02-14T08:08:00+00:00

Para comenzar 2017 con buen pie varios miembros de Codesai estuvimos en el DeveloperOS, un Open Space centrado en tecnologías .Net que organizó la comunidad .Net de Madrid el pasado 28 de Enero y del que fuimos uno de los patrocinadores. Aunque era la primera edición de este evento las entradas se acabaron enseguida. Últimamente hay que correr para poder pillar entrada casi para cualquier evento :)

El evento duró desde las 9 de la mañana hasta las 19:30. A lo que hay que sumarle algunas horas más para aquéllos que nos fuimos a tomar unas cervezas y charlar después de la retro y el sorteo de regalitos de los partners.

La organización del evento fue estupenda, como se vio reflejado en la retrospectiva final donde se puede decir que no había nada negativo. No hubo ningún problema de retrasos en las charlas gracias a unos intervalos de 15 minutos entre ellas y al gran trabajo de los organizadores.

Por otro lado fue un puntazo que trajeran el desayuno y la comida para poder comer y hacer networking sin tener que moverse del lugar del evento, por no mencionar que estaba fleje buena ;). Además, siempre estaban disponibles la máquina de café y algunos refrigerios o fruta para todo aquél que se quedase fuera de una charla mientras conversaba con otros asistentes.

También queríamos agradecer a la Universidad Rey Juan Carlos por ceder sus instalaciones para la celebración del evento.

En lo que se refiere a los asistentes hay que destacar la gran participación que hubo en las charlas y el nivelazo en general, las conversaciones de pasillo dieron pie a debates y reflexiones muy interesantes.

Asistimos a las siguientes charlas:

Versionado de APIs REST con ASP.NET Core.

Rodrigo Liberoff nos contó que siempre hay que versionar las APIs REST que hagamos, ya que si no versionamos es porque no queremos. También nos enseñó un paquete de NuGet Microsoft ASP.NET Core API Versioning que ayuda a versionar y con el que nos hizo una demo de las variantes de versionar nuestra API.

Tests de integración de Web APIs

Hugo Biarge nos enseñó una manera sencilla de hacer tests de integración de nuestra Web API. Y además nos hizo una demo con el paquete de NuGet Acheve.Owin.Testing.Security de problemas comunes que te puedes encontrar al hacer este tipo de tests, como, por ejemplo, si un usuario está logueado y entra al sistema, o que esté logueado pero no tiene permisos para entrar en ciertas rutas, etc. Fue una charla muy entretenida.

Estuvimos bastante tiempo metidos en conversaciones de pasillo y conociendo gente nueva, por lo que nos perdimos muchas charlas. Además, dimos varios charlas:

Comunicación No Violenta

Dani propuso una charla sobre Comunicación No Violenta después de leerse un poco menos de la mitad del libro de Marshall Rosenberg en el avión a Madrid. Como le tocó a primera hora, tuvo que improvisar, pero tras una breve introducción el nivel de participación de los asistentes ya era alto. Expuso un poco las bases de los capítulos que había leído y los ejercicios del libro provocaron mucho debate.

Testing behavior instead of components

Ronny propuso un debate sobre testear comportamiento vs testear componentes. Con esto se refería a tratar de aislarse de las implementaciones de diseño y subir el nivel de abstracción de los tests para reducir el acoplamiento. Ronny acompañó el debate mostrando tests reales que han desarrollado en AIDA. Miguel en los últimos minutos también se animó a mostrar algún test. Los asistentes estuvieron muy activos y los ejemplos ofrecían casos límite muy interesantes. Creo que todos tuvimos la oportunidad de aprender y además nosotros salimos muy contentos con el feedback recibido enseñando código. Sin duda, animamos a la comunidad a mostrar su código, obtener feedback de gente tan buena no tiene precio.

Refactoring

Miguel y Ronny montaron una mesa redonda sobre refactoring, hablando sobre estrategias que aplican en sus entornos de trabajo y las herramientas que usan en su día a día para mejorar su flujo. El debate estuvo servido porque los asistentes participaron mucho contando desde su perspectiva el cómo lidiar con personas de negocio y en situaciones no merece la pena afrontar un refactor durante el desarrollo. Sin duda fue una sesión de donde rescatar muchas frases interesantes y de gran valor.

Muchísimas gracias y felicidades a los organizadores de DeveloperOS. ¡El evento fue espectacular!

Charla sobre sequence comprehensions en Clojure

2017-02-10T00:08:00+00:00

Ayer grabamos nuestro tercera charla remota sobre Clojure como parte de las actividades que hacemos en nuestro pequeño grupo de estudio de Clojure/ClojureScript.

El tema de esta charla fue las sequence comprehensions usando for.

Aquí les comparto la grabación de la charla:

y aquí pueden encontrar los ejemplos que usamos.

Una vez más, me gustaría darle las gracias a Ángel por su ayuda y paciencia.

Espero que les resulte útil.

Estuvimos en Test Academy

2017-02-01T08:08:00+00:00

El pasado 25 de Enero tuve la suerte de formar parte de Test Academy en Barcelona, dirigiendo y facilitando una conversación sobre Behavior-driven development (BDD).

El objetivo de Test Academy es reunir a profesionales y expertos de la comunidad de testing y desarrollo de software durante un día para aprender, intercambiar experiencias y hacer networking. Este año hubo 8 sesiones que cubrieron una gran variedad de temas. La organización del evento me pareció brillante, el hotel era estupendo y todo funcionaba perfectamente. La zona de cafés y comida era estupenda para el networking y pude desvirtualizar a mucha gente que todavía no había tenido oportunidad de saludar en persona.

En cuanto a las sesiones, que no fuese la mía, sólo pude asistir a la de Almudena Vivanco sobre Web Performance. El resto de sesiones me las perdí muy a mi pesar, no pude asistir. Me encantó la sesión de Almudena, me apunté un buen set de herramientas imprescindibles como por ejemplo Web Page Test, que da una cantidad de información extremadamente útil. Mil cosas que herramientas como JMeter no permiten medir. Fué una sesión entretenida y muy valiosa.

Mi sesión estaba anunciada como una master class, básicamente porque no me dí cuenta hasta que faltaba poquito para el evento y ya no la pude cambiar. En realidad tratándose de una hora y media, prefería que hubiese participación de los asistentes. Cuando la gente hace preguntas y comparte experiencias puedo centrarme en compartir el conocimiento que creo que más valor les puede aportar. Además las opiniones de los asistentes me permiten aprender a mí también, escuchar las experiencias de los demás es muy enriquecedor. La aportación de Antonio Robres durante mi sesión fue un aporte muy interesante. También permite hacerse una idea de cual es el nivel de adaptación de BDD en diferentes equipos y empresas. La hora y media se me pasó volando y el nivel de participación fue bastante alto pero a haber pillado por sorpresa a los participantes y a que la sala no tenía una distribución cómoda para hacer debate.

Después de la sesión tuve la suerte de poder tomar café con algunas personas que habían estado en la sesión y que comentaban que se llevaban varias idea para poner en práctica, lo cual es una satisfacción.

Estas son las slides que utilicé:

Muchísimas gracias a los organizadores de Test Academy por montar un evento tan guapo y por darme la oportunidad de ser parte de él. Especialmente a Graham Moran, siempre tan amable y atento.

Impartimos un curso abierto de TDD en Barcelona

2017-01-31T08:25:00+00:00

La semana pasada Carlos y yo impartimos un curso de TDD en Barcelona en formato abierto.

Los cursos en abierto son siempre muy gratificantes porque los asistentes vienen con muchísimas ganas de trabajar y de aprender. De hecho, varios de ellos pagaron el curso de su propio bolsillo e incluso vinieron de otras comunidades. Muchísimas gracias a todos por venir y por su entusiasmo. Los cursos en abiertos son también muy interesantes porque en ellos solemos conocer a gente muy apasionada por su trabajo, que, en ocasiones, acaba colaborando con Codesai, como fue mi caso o el de Luis.

Este fue el primer curso que imparto con Carlos. La versión de curso que hace Carlos tiene una estructura más pausada que la de Luis. Se hacen varios ejercicios de testing y de refactoring antes de empezar a hacer TDD, que luego vienen muy bien. Aprendí muchas cosas de Carlos, tanto de sus comentarios como de la forma de tratar a las personas. En algunas cosas pensamos diferente, pero eso añade riqueza al curso.

Hacer los cursos en pareja es una gran ventaja cuando el grupo es grande porque el nivel de atención que recibe cada participante es mucho más alto. Esto es importante, porque nuestra formación es muy práctica, y estamos constantemente contestando a dudas y dando feedback a nuestros alumnos para que asimilen mejor los conceptos que queremos trabajar con cada kata. Además, el hecho de tener backgrounds distintos y personalidades diferentes, enriquece tanto las explicaciones teóricas como las prácticas, ya que podemos aportar un rango de experiencias, técnicas y perspectivas mucho más amplio.

Acabamos muy contentos con las sensaciones que tuvimos durante el curso y con el feedback que recibimos.

Fantastic @codesaidev 2-day #tdd training with @carlosble & @trikitrok. 👏 Lots of insights 🎯 and food for thought 💡 pic.twitter.com/TbjEUooHDH
— Angel (@rojo_angel) 24 de enero de 2017

Genial two-day training sobre TDD impartido por @codesaidev in house aquí en @magento BCN. pic.twitter.com/rKr4ORiSl6
— Rubén Cougil (@rcougil) 24 de enero de 2017

Dos días de TDD training de la mano de @carlosble y @trikitrok. 100% recomendable 😀 pic.twitter.com/8Zj28qBEDs
— Víctor Andevert (@victorandevert) January 24, 2017

Nos gustaría mucho darle las gracias a Magento y especialmente a Ángel Rojo por acogernos en sus oficinas y organizarlo todo tan bien. Tanto la sala como el espacio que reservaron para relajarse y tomar café como el catering estuvieron genial.

About Connascence

2017-01-20T07:15:14+00:00

Lately at Codesai we’ve been studying and applying the concept of connascence in our code and even have done an introductory talk about it. We’d like this post to be the first of a series of posts about connascence.

1. Origin.

The concept of connascence is not new at all. Meilir Page-Jones introduced it in 1992 in his paper Comparing Techniques by Means of Encapsulation and Connascence. Later, he elaborated more on the idea of connascence in his What every programmer should know about object-oriented design book from 1995, and its more modern version (same book but using UML) Fundamentals of Object-Oriented Design in UML from 1999.

Ten years later, Jim Weirich, brought connascence back from oblivion in a series of talks: Grand Unified Theory of Software Design, The Building Blocks of Modularity and Connascence Examined. As we’ll see later in this post, he did not only bring connascence back to live, but also improved its exposition.

More recently, Kevin Rutherford, wrote a very interesting series of posts, in which he talked about using connascence as a guide to choose the most effective refactorings and about how connascence can be a more objective and useful tool than code smells to identify design problems^[1].

2. What is connascence?

The concept of connascence appeared in a time, early nineties, when OO was starting its path to become the dominant programming paradigm, as a general way to evaluate design decisions in an OO design. In the previous dominant paradigm, structured programming, fan-out, coupling and cohesion were fundamental design criteria used to evaluate design decisions. To make clear what Page-Jones understood by these terms, let’s see the definitions he used:

Fan-out is a measure of the number of references to other procedures by lines of code within a given procedure.

Coupling is a measure of the number and strength of connections between procedures.

Cohesion is a measure of the “single-mindedness” of the lines of code within a given procedure in meeting the purpose of that procedure.

According to Page-Jones, these design criteria govern the interactions between the levels of encapsulation that are present in structured programming: level-1 encapsulation (the subroutine) and level-0 (lines of code), as can be seen in the following table from Fundamentals of Object-Oriented Design in UML.

Encapsulation levels and design criteria in structured programming

However, OO introduces at least level-2 encapsulation, (the class), which encapsulates level-1 constructs (methods) together with attributes. This introduces many new interdependencies among encapsulation levels, which will require new design criteria to be defined, (see the following table from Fundamentals of Object-Oriented Design in UML).

Encapsulation levels and design criteria in OO

Two of these new design criteria are class cohesion and class coupling, which are analogue to the structured programing’s procedure cohesion and procedure coupling, but, as you can see, there are other ones in the table for which there isn’t even a name.

Connascence is meant to be a deeper criterion behind all of them and, as such, it is a general way to evaluate design decisions in an OO design. This is the formal definition of connascence by Page-Jones:

Connascence between two software elements A and B means either

that you can postulate some change to A that would require B to be changed (or at least carefully checked) in order to preserve overall correctness, or

that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness.

In other words, there is connascence between two software elements when they must change together in order for the software to keep working correctly.

We can see how this new design criteria can be used for any of the interdependencies among encapsulation levels present in OO. Moreover, it can also be used for higher levels of encapsulation (packages, modules, components, bounded contexts, etc). In fact, according to Page-Jones, connascence is applicable to any design paradigm with partitioning, encapsulation and visibility rules^[2].

3. Forms of connascence.

Page-Jones distinguishes several forms (or types) of connascence.

Connascence can be static, when it can be assessed from the lexical structure of the code, or dynamic, when it depends on the execution patterns of the code at run-time.

There are several types of static connascence:

Connascence of Name (CoN): when multiple components must agree on the name of an entity.
Connascence of Type (CoT): when multiple components must agree on the type of an entity.
Connascence of Meaning (CoM) or Connascence of Convention (CoC): when multiple components must agree on the meaning of specific values.
Connascence of Position (CoP): when multiple components must agree on the order of values.
Connascence of Algorithm (CoA): when multiple components must agree on a particular algorithm.

There are also several types of dynamic connascence:

Connascence of Execution (order) (CoE): when the order of execution of multiple components is important.
Connascence of Timing (CoTm): when the timing of the execution of multiple components is important.
Connascence of Value (CoV): when there are constraints on the possible values some shared elements can take. It’s usually related to invariants.
Connascence of Identity (CoI): when multiple components must reference the entity.

Another important form of connascence is contranascence which exists when elements are required to differ from each other (e.g., have different name in the same namespace or be in different namespaces, etc). Contranascence may also be either static or a dynamic.

4. Properties of connascence.

Page-Jones talks about two important properties of connascence that help measure its impact on maintanability:

Degree of explicitness: the more explicit a connascence form is, the weaker it is.
Locality: connascence across encapsulation boundaries is much worse than connascence between elements inside the same encapsulation boundary.

A nice way to reformulate this is using what it’s called the three axes of connascence^[3]:

4.1. Degree.

The degree of an instance of connascence is related to the size of its impact. For instance, a software element that is connascent with hundreds of elements is likely to become a larger problem than one that is connascent to only a few.

4.2 Locality.

The locality of an instance of connascence talks about how close the two software elements are to each other. Elements that are close together (in the same encapsulation boundary) should typically present more, and higher forms of connascence than elements that are far apart (in different encapsulation boundaries). In other words, as the distance between software elements increases, the forms of connascence should be weaker.

4.3 Stregth.

Page-Jones states that connascence has a spectrum of explicitness. The more implicit a form of connascence is, the more time consuming and costly it is to detect. Also a stronger form of connascence is usually harder to refactor. Following this reasoning, we have that stronger forms of connascence are harder to detect and/or refactor. This is why static forms of connascence are weaker (easier to detect) than the dynamic ones, or, for example, why CoN is much weaker (easier to refactor) than CoP.

The following figure by Kevin Rutherford shows the different forms of connascence we saw before, but sorted by descending strength.

**connascence** forms sorted by descending strength (from Kevin Rutherford's XP Surgery).

5. Connascence, design principles and refactoring.

Connascence is simpler than other design principles, such as, the SOLID principles, Law of Demeter, etc. In fact, it can be used to see those principles in a different light, as they can be seen using more fundamental principles like the ones in the first chapter of Kent Beck’s Implementation Patterns book.

We use code smells, which are a collection of code quality antipatterns, to guide our refactorings and improve our design, but, according to Kevin Rutherford, they are not the ideal tool for this task^[4]. Sometimes connascence might be a better metric to reason about coupling than the somewhat fuzzy concept of code smells.

Connascence gives us a more precise vocabulary to talk and reason about coupling and cohesion^[5], and thus helps us to better judge our designs in terms of coupling and cohesion, and decide how to improve them. In words of Gregory Brown, “this allows us to be much more specific about the problems we’re dealing with, which makes it it easier to reason about the types of refactorings that can be used to weaken the connascence between components”.

It provides a classification of forms of coupling in a system, and even better, a scale of the relative strength of the coupling each form of connascence generates. It’s precisely that scale of relative strengths what makes connascence a much better guide for refactoring. As Kevin Rutherford says:

"because it classifies the relative strength of that coupling, connascence can be used as a tool to help prioritize what should be refactored first"

Connascence explains why doing a given refactoring is a good idea.

6. How should we apply connascence?

Page-Jones offers three guidelines for using connascence to improve systems maintanability:

Minimize overall connascence by breaking the system into encapsulated elements.
Minimize any remaining connascence that crosses encapsulation boundaries.
Maximize the connascence within encapsulation boundaries.

According to Kevin Rutherford, the first two points conforms what he calls the Page-Jones refactoring algorithm^[6].

These guidelines generalize the structured design ideals of low coupling and high cohesion and is applicable to OO, or, as it was said before, to any other paradigm with partitioning, encapsulation and visibility rules.

They might still be a little subjective, so some of us, prefer a more concrete way to apply connascence using, Jim Weirich’s two principles or rules:

Rule of Degree^[7]: Convert strong forms of connascence into weaker forms of connascence.

Rule of Locality: As the distance between software elements increases, use weaker forms of connascence.

7. What’s next?

In future posts, we’ll see examples of concrete forms of conasscence relating them with design principles, code smells, and refactorings that might improve the design.

Footnotes:

[1] See Kevin Rutherford's great post The problem with code smells.

[2] This explains the titles Jim Weirich chose for his talks: Grand Unified Theory of Software Design and The Building Blocks of Modularity.

[3] See the webinar Connascence: How to Measure Coupling by Nick Hodges.

[4] Again see Kevin Rutherford's great post The problem with code smells.

[5] The concepts of coupling and cohesion can be hard to grasp, just see this debate about them Understanding Coupling and Cohesion hangout.

[6] See Kevin Rutherford's post The Page-Jones refactoring algorithm.

[7] Even though he used the word degree, he was actually talking about strength.

References.

Others.

Podemos ser tu equipo

2017-01-18T07:00:00+00:00

Todo el mundo está a la búsqueda de desarrolladores, todos al grito de “we’re hiring!”. Quizás estemos viviendo otra gran burbuja del sector TIC. A las empresas les está costando encontrar y retener talento. Sobre todo, les está costando ensamblar equipos.

El desarrollo de software es un deporte de equipo. Es más importante que las personas trabajen bien en equipo que tener genios individualistas resolutivos en el corto plazo. Sobre todo porque el coste del software se puede disparar con el paso del tiempo debido al mantenimiento y lo que hoy se hace demasiado rápido, mañana se paga con intereses. A menudo se calcula el coste del software contando sólo las horas que lleva poner en producción la primera versión usable, pero en realidad ese coste es pequeño comparado con el de mantener el software, darle soporte y continuidad. El cuello de botella de los proyectos no está en la velocidad con la que añadimos líneas de código, sino en la complejidad innecesaria que generamos. Esta complejidad muchas veces tiene su origen en una mala definición de requisitos por no haber entendido bien el problema que se pretende solucionar. Otras veces se debe a no conocer prácticas y técnicas que ayudan a mantener tu código habitable y fácil de adaptar al cambio.

Por si esto fuera poco, como empleadores, contratar nos parece un gran compromiso. Los proyectos a menudo son de unos pocos meses y uno no quiere tener que despedir a una persona al poco tiempo de haber sido contratada.

Aún consiguiendo reunir un grupo adecuado, las personas que no han trabajado nunca juntas necesitan un tiempo de adaptación para conocerse y conseguir un buen “flow”. La productividad es mayor cuando las personas están acostumbradas a trabajar juntas. Además se necesita tiempo para familiarizarse con las convenciones del equipo, las dinámicas, las herramientas…

Por todo esto, si estratégicamente lo prioritario en tu caso no es formar un equipo, sino simplemente avanzar ya y con calidad en el desarrollo de producto, nosotros podemos ayudarte.

Podemos ser tu equipo, con todas las ventajas que proporciona un equipo de alto rendimiento con el que la colaboración es igual de cercana, intensa y comprometida que si fuesen tus empleados.

Y podemos ofrecerte otro servicio más, si llega un momento en el que necesitas que el software lo evolucionen otras personas, las incorporaremos progresivamente, para transmitirles el conocimiento técnico del producto y nuestros valores y prácticas.

Quizás es una opción que nunca habías valorado, ¿quieres que Codesai sea tu equipo de desarrollo?

Charla sobre distinguir entre problema y solución en la CAS2016

2017-01-13T07:00:00+00:00

En la pasada CAS 2016 di un charla sobre aprender a distinguir entre el problema y solución.

Esta distinción es importante porque uno de los motivos por los que más se desperdicia código, tiempo y dinero, es que confundimos la solución con el problema. No entendemos bien el problema del usuario y nos equivocamos al tomar requisitos.

Esto nos produce la sensación de que el cliente está todo el tiempo cambiando de opinión y de que los requisitos son supervolátiles, pero en muchas ocasiones no es así. Es la comunicación la que falla.

Es normal porque estamos entrenados para buscar soluciones, los desarrolladores somos “solucionólogos”.

Al elegir una solución concreta estamos descartando todas las demás. Si había otras más sencillas y/o convenientes para resolver el mismo problema, ya no nos daremos cuenta nunca, o quizás, lo haremos cuando ya sea demasiado tarde, después de dar demasiadas vueltas.

Creo que ser capaces de distinguir mejor entre problema y solución, es decir, separar lo mejor posible el “Qué” del “Cómo”, nos hace más eficaces y económicos a la hora de solucionar problemas, sin perjudicar la calidad de las soluciones, y por tanto nos hace más ágiles.

Sketch notes de la charla^[1]

Este es el video de mi charla Distinguir entre Problema y Solución que han publicado recientemente nuestros buenos amigos de Autentia ^[2].

Y estas son las slides de la charla:

[1] ¡Muchas gracias Aitor!

[2] ¡Muchas gracias Autentia!

Charla sobre el camino del aprendizaje en la CAS2016

2017-01-05T07:00:00+00:00

En una profesión como la nuestra en la que cada mes tenemos nuevas tecnologías, metodologías, prácticas… sería un grave error caer en el conformismo o pensar que hemos llegado a la cima de nuestro aprendizaje.

Tal y como plantea el libro Apprenticeship Patterns, el camino del aprendizaje es infinito. Como aprendices nunca nos veremos alcanzar la maestría, pero somos conscientes de que el aprendizaje continuo marca una gran diferencia. Creemos que aprender de manera constante es indispensable para asegurar la calidad de nuestro trabajo. Asimismo, consideramos que es esencial entender cómo aprendemos, de manera que, nos permita ser más eficaces a la hora de adquirir nuevos conocimientos o profundizar en otros.

Esta charla, que Modesto y yo presentamos en la pasada CAS 2016, trata principalmente de resumir cómo aprendemos y qué mecanismos podemos utilizar en nuestro día día para mejorar, aprender y compartir tanto dentro como fuera de nuestro trabajo.

Ha sido muy emocionante poder aportar nuestro pequeño grano de arena a la CAS 2016. Fue todo un eventazo y nos gustaría dar las gracias a todos los participantes y organizadores que la han hecho posible. También queremos agradecer todo el feedback que recibimos sobre nuesta charla.

Este es el video de la charla publicado recientemente por nuestros amigos de Autentia ^[1].

[1] ¡Muchas gracias!

Charla sobre funciones en Clojure

2017-01-04T00:08:00+00:00

Hace unas semanas hicimos nuestro segunda charla remota sobre Clojure como parte de las actividades que hacemos en nuestro pequeño grupo de estudio de Clojure/ClojureScript.

Esta vez profundizamos en las diferentes maneras de definir funciones.

Aquí les comparto la grabación de la charla:

y aquí pueden encontrar los ejemplos que usamos.

Una vez más, me gustaría darle las gracias a Ángel y a Magento Barcelona por dejarnos grabar la charla en sus oficinas.

Espero que les resulte útil.

Charla sobre Comunidades de Necesidad vs Comunidades de Soluciones en la CAS2016

2017-01-03T07:00:00+00:00

El pasado 30 de noviembre cogí un avión a las 7 de la mañana para ir a Vitoria. Pocas veces me costó tan poco madrugar porque sabía que me esperaba un evento delicioso. Las expectativas eran altas sabiendo que detrás estaban los de Agile Norte. Y se cumplieron.

Agradezco enormemente que mi charla hubiese sido elegida, porque se que la selección es muy complicada, muchas a escoger y acertar solo con la descripción es difícil.

Mi sesión, titulada “Comunidades de Necesidad vs Comunidades de Soluciones”, tiene su origen en la ALE de 2015 celebrada en Sofía hace dos veranos, donde en la keynote inaugural introdujo este tema Chris Matts.

Me hizo ver que dividimos constantemente los problemas y las personas en dos tipos, los que van a la última y los pragmáticos, muchas veces sin tener en cuenta el problema y únicamente nuestro propio interés.

Desde ahí, elaboré esta sesión basándome en los posts que escribió Chris para preparar la keynote^[1] que me dió un conocimiento mucho más profundo de lo que significa tener opciones antes de decidir.

Mi exposición es un viaje usando el Crossing the Chasm como vehículo para conocer conceptos como ver la necesidad, explorar opciones, probar nuevos contextos, distinguir escenarios de buenas prácticas de otros de prueba y error, valorar las opciones hasta el último momento responsable, principios y prácticas, y vender las mejores soluciones encontradas.

Y si solo te tuvieras que llevar una idea sería esta:

"Si las soluciones encontradas se basan más en los los principios que las crearon que en un conjunto de buenas prácticas, entonces enseñarlas como una receta a aplicar conducirá directo al fracaso. Porque cuando salgan escenarios no contemplados previamente, que saldrán, no sabremos cómo actuar."

Sketch notes de la charla^[2]

Los amigos de Autentia acaban de publicar el video de la charla. Gracias!

Al inicio hago un pequeño y emotivo homenaje a la comunidad agile.

Y aquí tenéis las slides que utilizamos en la charla:

Y al final como siempre saber balancear es la clave de todo.

[1] Referencias:

[2] Tomadas por el gran Javier Alonso (@oyabun). Muchísimas gracias por tu fantástico trabajo.

ES6 en React y resolviendo el binding del this

2017-01-02T14:30:00+00:00

Estás últimas semanas he estado aprendiendo React para un pet project que estoy haciendo con mis compañeros Ronny y Modesto.

Tiramos lo que teníamos de nuestra interfaz hecha con Polymer (que no era mucho tampoco) puesto que nos veíamos incapaces de avanzar de una forma constante ya que nos encontrábamos con problemas a cada momento que decidíamos sentarnos a programar.

Otro motivo para desechar Polymer es que testearlo se nos hacía un poco complicado. Además no nos terminaba de encajar el modelo que Google propone para testear el comportamiento de tu componente empleando la librería de Node.js llamada web-component-tester. Lo malo es que al ejecutar los tests, web-component-tester necesita lanzar una instancia de Webdriver para correr Google Chrome y probar la lógica que quieras probar. Esto nos complica también el hecho de que si quisieramos lanzar los test en un entorno de integración continua, no podríamos ni siquiera usando PhantomJS pues aún no soporta el estándar de Web Components en el que Polymer se basa.

Estas y varias otras razones (compatibilidad con múltiples navegadores, mayor cantidad de documentación y un maravilloso curso de introducción de Corey House en Pluralsight) nos hicieron decantarnos por React.js para fabricar la interfaz web de nuestra aplicación.

En este post quisiera hablar en concreto de dos decisiones que hemos tomado durante el desarrollo:

La primera fue usar ECMAScript 6 en el proyecto. Preferimos ES6 porque no tiene mucho sentido seguir usando ES5 a día de hoy, puesto que ES6 es el estándar.

De entre los approaches que hemos seguido para crear componentes en React, al final hemos optado por emplear las clases de ES6. Aunque no nos parece una solución completamente limpia y nos gusta más el enfoque de usar únicamente funciones en JavaScript, nos parece mejor que usar el React.createClass pasándole el objeto que contiene la definición de nuestras funciones dentro del componente o usar meramente composición. La razón es que abstraernos de la librería nos parecía demasiado esfuerzo para acabar con una solución demasiado compleja.

Aquí tenemos un ejemplo de componente que hemos creado con React. Como vemos es tan sencillo como crear una clase y extender de React.Component.

La decisión que tomamos tiene varias implicaciones, lo cual nos lleva a nuestra segunda decisión. Decidir cuál es el mecanismo para hacer el binding del this cuando la función this.handleChange es pasada como callback a un componente hijo.

Si nos fijamos en el render, al pasarle la función que tenemos asociada en nuestra clase al onChange, lo que ocurre básicamente es que JavaScript no liga el this que usa la función internamente al de la instancia de la clase que pasa esa función. Para resolver esta situación hemos encontrado diversas soluciones:

Usar el React.createClass. Si empleamos la función que nos provee React para crear componentes, esta internamente hará toda la magia por nosotros. Usar el bind cuando pasemos nuestra función como callback al componente hijo: “onChange={this.handleChange.bind(this)}”
Pasarle un Arrow Function con la llamada al método en onChange: “onChange={ value => { this.handleChange(value) }}
Declarar handleChange dentro del constructor empleando un Arrow Function

Estas son las tres maneras más sencillas de resolver nuestro problema sin tener que recurrir a mecanismos externos. Sin embargo, ninguna de ellas nos gustaba, y en caso de tener que adoptar alguna de las tres últimas, preferiríamos optar por emplear React.createClass.

Buscando otras formas de resolver este problema, encontramos un mecanismo que está por implementar en la siguiente especificación del lenguaje (ES2016), que básicamente es el emplear un decorador de función para que te haga el binding automáticamente empleando la librería “autobind-decorator” disponible en NPM. El resultado final sería algo tal que así:

Esta opción tampoco nos acababa de convencer, dado que tenemos que estar importando en cada componente la librería de autobind y no nos parece un solución lo suficientemente limpia como para tenerla en consideración. Una cosa a tener en cuenta para usar este mecanismo, en caso de estar usando Babel 6 para transpilar, debes utilizar también el preset “babel-plugin-transform-decorators-legacy” para que funcione adecuadamente (todo está explicando en su Github de todas maneras).

La opción que al final elegimos fue la última: emplear una Arrow Function en una propiedad de la clase. El problema con el que nos encontramos al usar esta solución, es que la especificación actual del lenguaje no soporta esta característica. Hay dos formas de lograr que funcione. La primera es usar el plugin de Babel “transform-class-properties” y la segunda es establecer el preset “stage-2” de Babel instalando “babel-preset-stage-2” en NPM. Al final, todo quedaría de la siguiente forma:

Un último detalle a tener en cuenta al usar esta solución y el autobind, es que dado que nosotros usamos eslint, tenemos que configurarlo para que soporte ambas features. Para arreglarlo, basta con únicamente usar “babel-eslint” como parser del eslinter y añadir en nuestro .babelrc lo siguiente:

Y listo, con eso, ya estaría todo solucionado.

Esta alternativa es, desde nuestro punto de vista, la que menor ruido genera, y a nivel de legibilidad, la más simple. Al final, una simple Arrow Function conserva el binding del this en el enclosing scope, por lo que todo se hace forma automática y se asemeja a lo que ya estamos acostumbrados en ES6.

Cualquier clase de feedback será bien recibido. Aquí dejo unos enlaces que podrían ser de interés. Un saludo!

An example of introducing symmetry to enable duplication removal

2017-01-02T00:16:00+00:00

Symmetry is a subtle concept that may seem only related to code aesthetics. However, as Kent Beck states in Implementation Patterns,

"...finding and expressing symmetry is a preliminary step to removing duplication. If a similar thought exists in several places in the code, making them symmetrical to each other is a first good step towards unifying them"

In this post we'll look at an example of expressing symmetry as a way to make duplication more visible. This is the initial code of a version of a subset of the Mars Rover kata that Álvaro García and I used in a refactoring workshop some time ago:

This code is using conditionals to express two consecutive decisions:

Which command to execute depending on a command code.
How to execute the command depending on the direction the rover faces.

These decisions are repeated for different responsibilities, displacing the rover and rotating the rover, so the code presents a Case Statements smell. Since those decisions are completely independent, we could mechanically refactor the code to start using polymorphism instead of conditionals. This way we'll end having two consecutive single dispatches, one for each decision.

If we start applying Replace Type Code with State/Strategy refactoring to the code as it is now, there is a subtle problem, though.

Looking carefully more carefully, we can observe that in the case of the rover's displacement, the sequence of two decisions is clearly there:

However, that sequence is not there in the case of the rover's rotations. In this case there's a third decision (conditional) based on the command type which as, we'll see, is not necessary:

This difference between the two sequences of decisions reveals a lack of symmetry in the code. It's important to remove it before starting to refactor the code to substitute the conditionals with polymorphism.

I've seen many cases in which developers naively start extracting methods and substituting the conditionals with polymorphism starting from asymmetrical code like this one. This often leads them to create entangled and leaking abstractions.

Particularly, in this case, blindly applying Replace Type Code with State/Strategy refactoring to the left and right rotations can very likely lead to a solution containing code like the following:

Notice how the Direction class contains a decision based on the encoding of the command. To be able to take that decision, Direction needs to know about the encoding, which is why it's been made public in the Command class.

This is bad... Some knowledge about the commands encoding has leaked from the Command class into the Direction class. Direction shouldn't be taking that decision in the first place. Neither should it know how commands are encoded. Moreover, this is a decision that was already taken and doesn't need to be taken again.

How can we avoid this trap?

We should go back to the initial code and instead of mechanically applying refactoring, we should start by removing the asymmetry from the initial code.

You can see one way of doing it in this video:

After this refactoring all cases are symmetrical (they present the same sequence of decisions)

We've not only removed the asymmetry but we've also made more explicit the case statements (Case Statements smell) on the command encoding and the duplicated switches on the direction the rover is facing:

Now it's clear that the third decision (third nested conditional) in the original rover's rotations code was unnecessary.

If we start the Replace Type Code with State/Strategy refactoring now, it's more likely that we'll end with a code in which Direction knows nothing about how the commands are encoded:

and the encoding of each command is known in only one place:

As we said at the beginning, symmetry is a very useful concept that can help you guide refactoring. Detecting asymmetries and thinking why they happen, can help you to detect hidden duplication and, as in this case, sometimes entangled dimensions of complexity^[1].

Then, by removing those asymmetries, you can make the duplication more visible and disentangle the entangled dimensions of complexity. The only thing you need is to be patient and don't start "obvious" refactorings before thinking a bit about symmetry.

[1] Dimension of Complexity is a term used by Mateu Adsuara in a talk at SocraCan16 to name an orthogonal functionality. In that talk he used dimensions of complexity to group the examples in his test list and help him choose the next test when doing TDD. He talked about it in these three posts: Complexity dimensions - FizzBuzz part I, Complexity dimensions - FizzBuzz part II and Complexity dimensions - FizzBuzz part III. Other names for the same concept that I've heard are axes of change, directions of change or vectors of change.

Estuvimos en Gradiant

2016-12-27T07:25:00+00:00

La semana pasada Luis Rovirosa y yo impartimos una formación de TDD en las oficinas de Gradiant en Vigo.

Gradiant es el acrónimo en inglés del Centro Tecnolóxico de Telecomunicacións de Galicia (Galician Research and Development Center in Advanced Telecomunications) y utilizan los conocimientos y experiencia de sus profesionales de investigación para aportar valor a empresas y organizaciones mediante la transferencia de conocimiento y el diseño de productos especializados.

La naturaleza del centro y su ubicación en el campus de la Universidad de Vigo me recordó bastante a la época en que trabajé en el BSC.

Este fue el segundo curso de TDD de Codesai que imparto con Luis, y era todo un reto, debido al número de asistentes, 18 personas, y, sobretodo, a la gran variedad de tecnologías y tipos de sistemas que desarrollan, que iban desde C empotrado para procesado de señales o IOT, hasta APIs REST con node.js, pasando por diversas aplicaciones en Java, C++ o Scala.

Creo que hacer los cursos en pareja es una gran ventaja. Por un lado, porque podemos atender mucho mejor, sobre todo si el grupo es numeroso, a las parejas durante las sesiones prácticas dándoles feedback y contestando sus dudas, para ayudar a que asimilen mejor los conceptos que persigue trabajar cada kata. Por otro lado, porque nos permite asumir roles diferentes, parecidos a los de conductor y navegador en pair-programming, para percibir mejor el pulso de nuestra audiencia y modular mejor nuestro mensaje. En este sentido, Luis y yo, nos complementamos bastante bien porque, al tener backgrounds bastante distintos y personalidades diferentes, podemos enriquecer tanto las explicaciones teóricas como las prácticas, con un rango de experiencias y perpectivas más amplio, lo que considero que fue muy útil, dada la diversidad del grupo.

Algunos de los desarrolladores que asistieron al curso trabajaban en sistemas empotrados haciendo IOT o procesado de señales en los que cuentan con recursos muy limitados y en entornos en los que testear es bastante complicado. Para tratar de ayudarlos, aparte de responder dudas concretas y de las conversaciones de pasillo, reunimos una compilación de recursos interesantes para hacer testing y TDD con C empotrado.

Nos gustó muchísimo la experiencia de trabajar con las personas que asistieron al curso. Era un grupo muy agradable y con muchísimas ganas de aprender. Además, durante el curso, surgieron preguntas y debates muy interesantes debido a la gran diversidad de tipos de proyecto desarrollados por los asistentes.

Hemos acabado reventados después de dos días intensos... Pero también motivadísimos #tdd #craftmanship https://t.co/eXtEBVssmZ
— Javi Sánchez Rois (@jsrois) December 20, 2016

Mega cursazo! Gracias @trikitrok @luisrovirosa y gracias @Gradiant por traerlos! A ver si vuelven 😉https://t.co/pMuI7aZl2E
— Fernando Vilas (@fer_vilas) December 20, 2016

Como siempre acabamos cansadísimos pero muy contentos porque creo que conseguimos nuestro objetivo de iniciar al grupo en testing y TDD, y de ilusionarlos para empezar a aventurarse en una forma de trabajo diferente.

Antes de terminar quería darle las gracias especialmente a Javi Sánchez Rois y a Fernando Vilas por acogernos, llevarnos a sitios ricos para comer y presentarnos al Dinoseto 😉.

Charla sobre connascence en SCBCN 2016

2016-12-22T06:00:00+00:00

El pasado Octubre Fran y yo preparamos una charla para la Software Craftsmanship Barcelona 2016 explicando el concepto de connascence.

Podemos entender connascence como la relación entre N componentes de software que implica que cuando se cambia uno de esos N componentes los N-1 componentes restantes se tienen que cambiar para mantener la integridad del sistema completo. En otras palabras, lo que nos ofrece connascence es una forma mucho más rica para referirnos y expresar diferentes tipos de acoplamiento. Se podría decir que del mismo modo que los patrones de diseño nos ofrecen un vocabulario para hablar de diseño orientado a objetos, connascence nos ofrece un vocabulario para hablar de acoplamiento.

A partir de esta charla de Jim Weirich nos empezamos a interesar por el tema y decidimos preparar una pequeña charla para profundizar sobre el tema, presentarla a la comunidad y debatir un poco sobre el concepto.

Los amigos de Software Craftsmanship Barcelona acaban de publicar el video de la charla, aunque como Fran no pudo asistir van a tener que aguantarme a mi sólo todo el video, je, je:

Y aquí tenéis las slides que utilizamos en la charla.

Espero que les resulte tan interesante como a nosotros, todos los comentarios son bienvenidos!

Usamos la imagen de tipos de connascence de Kevin Rutherford.

Charla sobre destructuring en Clojure

2016-12-15T10:25:00+00:00

Recientemente me uní a Codesai , y como muchos saben por mi blog personal estoy encantado con Clojure.

Como algunos miembros de Codesai querían aprender Clojure/ClojureScript, decidimos empezar un pequeño grupo de estudio en remoto (Codesai es un equipo distribuido) contando conmigo como mentor.

Para ello creamos un slack, clojuresai, donde voy posteando lecturas (estamos leyendo Clojure for the Brave and True) y ejercicios (estamos haciendo una selección de los ejercicios de 4Clojure) cada semana. Además hay canales donde pueden preguntar dudas o hacer comentarios tanto sobre las lecturas como los ejercicios, y compartir cualquier cosa que encuentren interesante.

A los pocos días de crear el grupo de estudio, algunos compañeros del meetup Clojure Developers Barcelona que están empezando con Clojure, se nos unieron también.

De vez en cuando, hacemos charlas introductorias en remoto usando Google Hangouts para profundizar en algunos temas que hemos leido hace poco en el libro.

Hasta ahora hemos hecho dos charlas. La primera fue sobre las colecciones de Clojure, pero desgraciadamente no la pudimos grabar. De todas formas, les comparto aquí los ejemplos que usamos en esa charla.

Hace un par de semanas hicimos nuestra segunda charla remota. Esta vez profundizamos en el destructuring, y sí que la pudimos grabar, lo cual vino muy bien porque algunos miembros del grupo de estudio no pudieron conectarse.

Esta es la grabación de la charla:

Además pueden encontrar aquí todos los ejemplos que usé para explicar el destructuring .

Me gustaría darle las gracias de manera especial a Ángel y a Magento Barcelona por dejarme hacer la charla desde su oficina (su conexión a internet es muchísimo mejor que la mia).

Antes de terminar quiero mencionar que Miguel de la Cruz, también se ha unido como mentor a nuestro grupo de estudio (¡muchísimas gracias Miguel!). Sabe mucho Clojure y ayudará resolviendo dudas y preparando otras charlas que esperamos compartir pronto.

Espero que les sea útil.

Estuvimos en Ve Interactive

2016-12-09T09:25:00+00:00

Hace unas semanas Luis Rovirosa y yo impartimos una formación de TDD en las oficinas de Ve Interactive en Bilbao.

Luis lleva bastante tiempo impartiendo el curso de TDD de Codesai, tanto en solitario como junto con Carlos Blé, pero para mi era la privera vez. Me gustó mucho la estructura y el ritmo que le da Luis al curso.

Se trata un curso muy intenso y eminentemente práctico que dura dos días, cada uno de los cuales se divide en cuatro bloques de dos horas. Al comienzo de cada bloque presentamos una serie de conceptos teóricos, que comentamos y debatimos con el grupo, y rápidamente pasamos a ponerlos en práctica mediante una serie de katas de complejidad y dificultad creciente, en las que acompañamos continuamente a las parejas dándoles feedback y contestando sus dudas, para que los conceptos acaben de ser asimilados.

Fue todo un placer trabajar con los 14 desarrolladores que asistieron al curso. Era un grupo con una actitud genial y con un nivel muy bueno. A pesar de lo intenso del curso, trabajaron con mucho entusiasmo cada uno de los ejercicios y se produjeron debates muy interesantes y constructivos.

Nos fuimos de Bilbao exhaustos, pero muy contentos, tanto por las personas que conocimos como por el feedback que recibimos. Personalmente, me encanto trabajar con Luis y aprendí muchísimo de él.

Inolvidable CAS2016 Vitoria-Gasteiz

2016-12-08T17:25:00+00:00

Nada más terminar CAS2015 teníamos muy claro que queríamos estar en CAS2016, entre otras cosas por el cariño que tenemos a los organizadores, nuestros buenos amigos del norte, que yo considero referentes en muchos aspectos. Teníamos las expectativas muy altas con respecto a la organización y no solo las han cumplido sino que las han superado con creces.

Nos ofrecimos a patrocinar desde que se abrió el plazo porque sabíamos que se petaría de organizaciones queriendo ser parte de los patrocinadores y así fué. Por cierto, se nos olvidó encargar nuestras pegatinas molonas y no llegamos a poner una en cada bolsa. Si alguien no consiguió pegatina, nos puede escribir y se la enviamos por correo. Aprovecho para agradecer a Luz de Ambidiextro que se puso a trabajar a toda máquina en las pegatinas habíendolas pedido con solo 4 días de antelación y además se desplazó a traerlas en mano a la oficina.

Tuve la suerte de que mi propuesta de charla fue aceptada y encima en la agenda estaba el primer día, al principio del evento. Mi hora preferida. Por un lado la noche anterior me dió mucha pena no ir a la cena con ponentes y organizadores pero la prioridad era descansar para dar mi mejor versión durante mi sesión. Por otro lado, ya el resto del evento me pude centrar en absorber conocimiento y hablar con todo el mundo. En los eventos hablo hasta con las columnas.

Me encontré muy cómodo en el escenario y pude contar lo que quería. Después recibí feedback muy interesante que me llevó a cambiar mis slides antes de colgarlas y a abrir la mente. Tengo comprobado que las charlas me salen como yo quiero cuando las trabajo mucho. Hago un trabajo profundo de divergencia y convergencia para ordenar mis ideas, filtrar los contenidos, escribir un guión, montar las slides... en el escenario parece natural cuando en realidad es bastante artificial, tengo practicamente todas las frases memorizadas de haber hecho la charla como 10 veces en casa. Las primeras veces voy leyendo el guión y midiendo el tiempo que tardo y observando si me siento cómodo o incómodo verbalizando en voz alta el guión, de tal manera que lo voy ajustando a lo que me resulta mas natural decir en voz alta. Decido qué pequeñas bromas quiero hacer y cuales no. El resultado parece natural y fluido, como improvisado, pero mi capacidad de improvisar es limitada y de un tiempo a esta parte no me la juego. Pongo el foco en transmitir el mensaje con eficacia, buscar la forma de causar impacto. En otros eventos como open spaces si me gusta más improvisar. En las últimas charlas que he hecho en inglés últimamente, me ha faltado ensayarlas más veces. Es por este motivo que antes no le veía sentido a repetir la misma charla en diferentes conferencias y ahora sí, cuando la audiencia es diferente y el asunto me parece relevante.

Muchas gracias a todos por venir, especialmente a los que participaron en el turno de preguntas o me dieron feedback directo. No me había dado cuenta que cuando hablé por encima de Design Thinking pudo haber sonado algo despectivo o infravalorado cuando en realidad pienso todo lo contrario, me parece super interesante.

En el taller de Silvia Calvet y Gastón Valle, me dí cuenta que compartimos muchas cosas y me reforzaron la idea de probar la técnica Design Sprint que la conocía gracias a la sesión de Aritz Suescun en AOS2016. El taller me gustó mucho pese a llegar tarde. Tuve un buen intercambio de información con Silvia y Gastón. Les estoy agradecidos a los tres.

Creo que la charla se grabó, si se publica actualizaré este post con el vídeo.

La agenda de esta CAS me resultaba tan interesante que en todos los slots quería ir a tres cosas a la vez. Felicidades a los chairs, a mí la agenda me ha parecido brutal. A menudo eran amigos míos a los que quería ver para poderles dar feedback y hacer un poquito de cobertura en twitter pero era imposible. Algunas sesiones directamente me las perdí porque estaba inmerso en alguna excitante conversación de pasillo y café. De hecho al taller de DS llegué tarde porque ví a Bob Marshall muy solo y aproveché a charlar un ratito con él. Estuvimos hablando de Comunicación no violenta (CNV), de cambio organizacional y hasta del Brexit...

Me pasó lo mismo con Chris Matts que nos pusimos de charla y al final a penas participé en el taller de Event Storming de Vicenç. Conocía a Chris de coincidir en networking en varias conferencias en el extranjero y tenía ganas de verle porque es muy cercano y te cuenta lo último que tiene en mente a poco que le des pié. Tuvo el detallazo de regalarme una copia firmada de su libro Commitment :-D

Vengo siguiendo su corriente de pensamiento desde hace tiempo, junto a Dan North, con lo cual no me sorprende que una de mis slides tuviese un gran martillo y en la suya tambien y ambos dijésemos esto de que cuando uno tiene un martillo todo parecen clavos. Interpreté algunas coincidencias más con mensajes de Chris y Bob como lo de hablar de necesidades. No es casualidad.

Me gustó verles en el evento, agradezco el esfuerzo de la organización por traerles. Sin embargo me sentí algo impotente cuando veía a Bob muy sólo durante la conferencia, parece que quería hablar con la gente pero no se producía acercamiento. La noche del jueves no le ví en la fiesta. Este tema de integrar a los que vienen de fuera, pienso que lo seguimos teniendo pendiente de mejora.

La CAS de Vitoria ha sido un subión constante, mucho cariño y respeto en el ambiente. Veo una evolución en nuestra comunidad que es emocionante. Estoy tremendamente agradecido a la organización por hacerlo posible. El lugar era ideal.
La humildad de los organizadores, su valentia al presentar, el esfuerzo porque todos estuviesen contentos durante la jornada y tambien por la noche, estar todo el tiempo pendientes cuidando de nosotros para que los detalles pequeños como guardar el abrigo y la maleta, o tomar un cafe y una fruta entre horas... es impresionante. Mil gracias y enhorabuena de corazón. Y en la organizacion estoy por supuesto incluyendo a los track chairs.

Aprovecho para dar las gracias a todas las personas con las que pude compartir un ratito. Sin ningún tipo de orden:

Luis Artola, Guillermo Galmazor, David Gonzalez, Alvaro Amor, Alberto Paz, Joaquin Engelmo, David Fernandez, Marta San Martín, David Jímenez, Carlos Valle, Unai Roldán, Gerardo Ponte, Fernando y Arcangel, Primi Cachero, Beatriz Martín, Maica Trinidad, Raquel Lainde, Jose E. Rodriguez Huertas, Roberto Canales, Vicenç García-Altes, Amalia Hernández, Leo Márquez, David Parra, Oriol del Barrio, Oriol Soriano, Roberto Matas, Rafa, Xavier Albaladejo, Pablo Domingo, Silvia Sistaré, Javier Prieto, Patricia Egea, Aritz Suescun, Joserra Díaz, Jorge Uriarte, Rubén Bernardez, Rubén Eguiluz, APA, Gorka Moreno, Pablo Albizu, Iker Mariñelarena, Néstor Salceda, Javier Rubio, Xabi Sáez, Patxi Esteban, Diego Rojas, Andrea Vega, Fernando Palomo.

Agradecimientos especiales a:

Mi compañero Antonio de la Torre por su valentía presentando un tema complejo. Por compartir habitación y cuidar de nosotros. Por hacer una buena cobertura en twitter a Codesai.

Modesto San Juan por encargarse de las pegatinas, ayudarnos a repartirlas y animar a Ronny a copresentar.

Edu Cabrera por transmitirme su visión y darme feedback. Edu enfocó mi mensaje desde el punto de vista de las personas y me animó a pensar en potenciar las virtudes y no solo a buscar problemas. Y que esta busqueda se haga conjuntamente con el equipo para que todo se sientan partícipes, co-descubriendo las virtudes y co-creando la solución. Esto apodera al equipo y cambia la cultura. Así no hay que vender nada a nadie. Hablamos de muchas cosas más, todas muy reveladoras. Como por ejemplo invitar a clientes a restrospectivas y demos internas.

Alberto Gomez por presentarnos a tanta gente interesante y lo estupendo que ha sido poder hablar en persona del proyecto en el que estamos trabajando juntos.

Edu Ferro por compartir sus slides conmigo.

Jose Manuel Beas por las fotos y conversaciones.

Isidro López por animarme a seguir compartiendo.

José Torres y Carlos Seisdedos por aquella conversación nocturna, alejados del ruido.

Oscar Prada y Antonio Lopez por compartir la forma en que están vitaminando a sus equipos.

Mis compañeros de AIDA Software por estar ahí siempre apoyando: Carlos Seisdedos, Jesús Quintana y Miguel A. Umpierrez

Ronny Ancorini por acompañarme a la sala para darme apoyo antes de arrancar mi charla.

Patxi, Alex Ballarin y Gerard Chiva por el viaje de Bilbao a Vitoria. También a Gerar y Tony Tassani por agradable cena.

Carlos Iglesias, Jordi Hernández y Lesmes López por el viaje de Vitoria a Bilbao. Me gustó mucho saber más de Runroom y sus valores.

A Dani Latorre por invitarme a un hangout para intercambiar impresiones para su charla y luego por hablar tan bien de nosotros en el escenario. La presentación de Dani me pareció valiente, sincera y muy divertida.

Carmen por su solidaridad conmigo en Barcelona, pasando miedo juntos con el taxista que conducía como un formula 1 por Barcelona.

Gracias a todos los que me pusieron pegatinas con Kudos (yo perdí los míos y no le puse a nadie). Y a todos los que subieron a twitter fotos de nuestras sesiones.

Me quede con las ganas de hablar con mas amigos, pero no dio tiempo para mas. ¡Nos vemos en CAS2017, donde quiera que sea!

Así viví Codemotion 2016

2016-11-19T18:24:43+00:00

Para mí el primer Codemotion y ha sido impactante, un eventazo de lo mejor. No me explico cómo es que no había estado antes.

Me lo he pasado bomba, he aprendido mucho, me he encontrado con muchísimos amigos, desvirtualizado a mucha gente y me he sentido en un ambiente acogedor y colaborativo, cosa que no es fácil teniendo en cuenta que hemos estado ¿2600 personas? Cuando estuve en la inspiradora ponencia de Jorge Barroso en el Track1, puede contar sentadas unas 400 personas y habíamos decenas de personas de pie. Por cierto que siempre que veo a Jorge aprendo, tanto de valores y cultura como de exponer en público. Me llevo muchas cosas para la saca. Recomiendo verla tranquilamente en casa.

La organización ha hecho un trabajo brillante y los voluntarios han sido encantadores, muy atentos en todo momento.

Hace poquito escribía un post sobre las conferencias y la comida. Curiosamente en Codemotion el tema de la comida se resolvió justo como más me gusta. Había opción vegetariana, vegana y sin gluten y todo estaba en el mismo sitio, con lo cual comer no era un problema. El segundo día llegué tarde y se había agotado lo vegano. Es una buena señal, un dato que puede usarse para que en futuras ediciones vaya aumentando el número de unidades veganas ya que gente no vegana también lo quería comer. Estaba muy rico. Eché de menos que la cafetería no estuviese abierta el sábado. El viernes tuve muy buenas conversaciones en la cafetería, donde además el café y las tostadas eran cojonudas. Poder comer al aire libre fué un plus los dos días.

La cena de ponentes del jueves fue en un lugar ideal para el networking y pasamos unas horas estupendas. Pena que lo único vegano que hubo fue la fruta del postre pero tampoco iba hambriento. Todo un detallazo lo de montar evento de networking para ponentes para ir calentando. Las salas eran ideales para este formato de conferencias y las indicaciones para llegar a las mismas también.

Me ha parecido que el comportamiento de la gente ha sido muy cívico.
Ir el viernes en bus desde Plaza España funcionó estupendamente y para volver ese día también muy bien.
El sabado eché de menos no haberme organizado para compartir taxi al aeropuerto porque había mucha gente en al misma situación y al final se pidieron taxis de más y acabé yendo solo.
El viernes el registro fue rapidísimo. La conexión a internet me funcionó mucho mejor de lo que esperaba habiendo tantísimos dispositivos conectados.
Todas las sesiones a las que fuí me aportaron valor, la gente se había preparado muy bien el material de ponencias y talleres. Como siempre no se puede ir a todo pero tener muchas grabadas resuelve parte del problema. Estoy deseando verlas en casa.

He sido ponente, creo que un poco de rebote porque inicialmente no entró en la agenda mi propuesta pero unas semanas antes del evento me avisaron de que había un hueco y entraba. Quiero dar las gracias a la comunidad ágil por votar la sesión y a la organización por la oportunidad.

Muchas gracias a los asistentes. La había trabajado mucho las semanas anteriores, la había rodado el día anterior en IronHack y tuve suerte de estar fresco ese día y contar las cosas tal como me has había preparado. Así que muy contento.

Me dirigí a la sala casi 15 minutos antes de empezar porque no sabía ni donde estaba ubicada. Al bajar a la planta, enseguida me encontré una cola de gente enorme en el pasillo. Un pasillo muy largo que debe tener más de 50 metros. No sabía de qué era pero conforme caminaba buscando la sala me daba cuenta que era para ir a esta sesión.

La cola era impresionante, nunca había visto una cosa así. Estuvo a reventar y se quedó gente fuera.
Aquí se ven fotos que hice unos minutos antes de la charla, donde ahora que las veo me doy cuenta que hay como 5 personas saludando a la cámara, haciendo gesto de apoyo. Cuando las hacía no me dí cuenta. Daba gusto ver tantas caras conocidas entre los asistentes.

Puesto para mí la parte de interacción con los asistentes es de las más enriquecedoras, he aprendido que para otra ocasión es mejor decirselo así a la gente antes de cerrar la charla, para que no salgan corriendo despues de mi última slide, ya que había reservado tiempo extra precisamente para tener tiempo para preguntas y respuestas tranquilamente. Pedí a la gente que por favor no hicieran ruido al salir y pudimos tener esa sesión de preguntas que me permitió contar más cosas que tenía preparadas. En la ronda de preguntas es donde sale a relucir parte del material que genero preparando la charla, pero que descarto de las slides para asegurarme que hay interacción y así va con más contexto.
Gracias a todos los que expresaron feedback e incluso fotos y palabras de apoyo en twitter y en la agenda del evento:

Ha estado genial la charla de @carlosble, enhorabuena. pic.twitter.com/B8wcaaYwBx
— Jorge Sánchez (@xurxodev) November 18, 2016

Me ha gustado mucho la charla de @carlosble en #Codemotion2016. Interesante y llena de sentido común. pic.twitter.com/noSMAKDvdV
— Vandergil (@LaVandergil) November 18, 2016

Fichad eso. Y preguntad directamente a @carlosble por cómo hay que conocer el contexto... vaya pedazo de charla. 😍😍 #Codemotion2016 pic.twitter.com/CFGixVXQnt
— Salva (@salvadelapuente) November 18, 2016

Hay dos cosas sagradas en el mundo del desarrollo:la religión y el rey.Aquí ambos, con una foto de Felipe al lado @carlosble #Codemotion2016 pic.twitter.com/IJ9i3Y0ktt
— Jose Armesto (@fiunchinho) November 18, 2016

"Hola, me llamo @carlosble y soy desarrollador". Los más grandes no necesitan adornarse ni con corbatas ni con firmas de 10 palabras pic.twitter.com/nyfNOAZ3YU
— Iñaki Pérez (@ialbeniz) November 18, 2016

¡Grande @carlosble! ¡Me ha encantado la charla! Me llevo varias ideas para mejorar 🤓 #Codemotion2016 pic.twitter.com/0ZCRIitaYR
— Juan Lladó (@jllado) November 18, 2016

Gran charla de @carlosble hoy en #Codemotion2016 !! Me llevo varias ideas que pondré en práctica!!
— Rubén Sans Mudoy (@rbn_sans) November 18, 2016

It's incredible what I can bear to listen to @carlosble #Codemotion2016 Great! As usual! pic.twitter.com/Ye7FZ808r9
— Raquel (@bberrycarmen) November 18, 2016

Gran charla de @carlosble con lleno absoluto!! #Codemotion2016
— Sergio (@s_barri) November 18, 2016

Si hubiera grabado el volumen de los aplausos os haríais una idea de lo wenisma que ha sido la charla de @carlosble #Codemotion2016
— Salva (@salvadelapuente) November 18, 2016

Muy muy interesante la charla de Carlos Ble @carlosble en #Codemotion2016 "deja una solución abierta"
— karolrodtor (@karolrodtor) November 18, 2016

La charla también la voy a hacer en CAS2016 en Vitoria-Gasteiz pero desconozco si allí se grabará.

Uno de los puntos fuertes de los eventos es encontrarnos los compañeros de la comunidad Codesai. La comunidad es el equipo de Codesai más los amigos cercanos como Modesto y Laura. Modesto sigue estando en el canal de slack donde compartimos conocimiento y experiencias. Un lujo poder estar un rato con Alfredo, Antonio, Laura y Modesto. La ponencia de Alfredo y Laura me ha encantado, recomiendo estudiarla en casa con tranquilidad porque está repleta de experiencia destilada en materia de tests automáticos. Enhorabuena!

En cuanto a conocimiento técnico me encantado de haber comprendido lo que es una mónada gracias a la ponencia de Juan Manuel Serrano (muy buena para verla en vídeo). Así con un buen ejemplo da gusto. Además la puesta en escena fue muy amena.
Conocí Perceval de la mano de Alvaro del Castillo, herramienta muy interesante para proyectos que tenemos en mente. Nos confirmó que Kibana es una excelente herramienta.
Por otro lado en el taller de Polymer de Jorge del Casar descubrí muchas cosas que no conocía, me quedé con ganas de más.
La charla de Micael Gallego ha reforzado lo que ya Modesto venía sugiriendo de usar TypeScript y ha llegado el momento de probarlo. Usar TypeScript en lugar de ES6 o ES7 en algunos proyectos. De una manera bastante funcional, sin clases, similar a como usamos ES6 pero con la posibilidad de tipar cuando lo veamos adecuado. En definitiva usar la herramienta cuando aporta. Una charla muy divertida y esclarecedora.
En la cafetería y pasillos pude aprender mucho con Salva de la Puente y con Israel Gutierrez sobre lenguajes, linters e incluso de hablar en público.
Las charlas breves de Roberto Canales y Jose Luis Ugia me parecieron ambas muy buenas y me reforzaron ideas que van alineadas con sus mensajes.
El sábado me perdí bastantes charlas entre que llegué tarde y me marche más temprano, las veré grabadas.

Conversaciones muy enriquecedoras con Ricardo Borillo, Jerónimo López, David Bonilla, Yeray Darias, Dani Latorre, Roberto Canales, Nacho Carretero, Félix López, Jose Armesto, Rubén Chavarría, Iván Abascal, Raúl Avila, Carlos Benitez, Joan León, Yamila Moreno, Daniel Piñeiro, Juan Lladó, David Fernández, Jorge del Casar, Joaquín Engelmo, Manuel Castro, Jorge Sánchez, Miguel Angel Bueno, Oscar Torres, Juan José Aguililla, Alvaro Amor, Alberto Paz, Alex Jover, Kiko Beats, Elena Torró, Javi Velasco, Javier Vélez, Jorge Senin, Rubén Díaz, Diego Rojas, Ezequiel, Isabel Rodriguez, Alba Roza, Jose Luis Ugia, Reinaldo Aguilera, Raquel Moreno, Eliezer López, Carlos Gámez, Dani Rey, David Gonzalo, Fran Raya, Daniel Cruz, Jose Turégano, Jaume Jornet, Pablo Domingo, Israel Alcázar, Raúl Navarrete, Alberto Lucas, Alfredo de la Calle, por citar algunos nombres.

Me hubiera gustado poder hablar más tiempo para charlar con colegas y haberme encontrado en persona con otros sólo conozco virtualmente pero que al final ni nos llegamos a encontrar. No parecía que fuésemos tanta gente pero sí que lo éramos porque ni nos vimos.

¡Nos vemos en el próximo Codemotion!

Using effects in re-frame

2016-11-10T22:17:14+00:00

In re-frame, we’d like to use pure event handlers because they provide some important advantages, (mentioned in a previous post about coeffects in re-frame): local reasoning, easier testing, and events replay-ability.

However, as we said, to build a program that does anything useful, it’s inevitable to have some side-effects and/or side-causes. So, there will be many cases in which event handlers won’t be pure functions.

We also saw how using coeffects in re-frame allows to have pure event handlers in the presence of side-causes.

In this post, we’ll focus on side-effects:

If a function modifies some state or has an observable interaction with calling functions or the outside world, it no longer behaves as a mathematical (pure) function, and then it is said that it does side-effects.

Let’s see some examples of event handlers that do side-effects (from a code animating the evolution of a cellular automaton):

These event handlers, registered using reg-event-db, are impure because they’re doing a side-effect when they dispatch the :evolve event. With this dispatch, they are performing an action at a distance, which is in a way a hidden output of the function.

These impure event handlers are hard to test. In order to test them, we’ll have to somehow spy the calls to the function that is doing the side-effect (the dispatch). Like in the case of side-causes from our previous post, there are many ways to do this in ClojureScript, (see Isolating external dependencies in Clojure), only that, in this case, the code required to test the impure handler will be a bit more complex, because we need to keep track of every call made to the side-effecting function.

In this example, we chose to make explicit the dependency that the event handler has on the side-effecting function, and inject it into the event handler which becomes a higher order function. Actually, we injected a wrapper of the side-effecting function in order to create an easier interface.

Notice how the event handlers, evolve and start-stop-evolution, now receive as its first parameter the function that does the side-effect, which are dispatch-later-fn and dispatch, respectively.

When the event handlers are registered with the events they handle, we partially apply them, in order to pass them their corresponding side-effecting functions, dispatch-later for evolve and dispatch for start-stop-evolution:

These are the wrapping functions:

Now when we need to test the event handlers, we use partial application again to inject the function that does the side-effect, except that, in this case, the injected functions are test doubles, concretely spies which record the parameters used each time they are called:

This is very similar to what we had to do to test event handlers with side-causes in re-frame before having effectful event handlers (see previous post). However, the code for spies is a bit more complex than the one for stubs.

Using test doubles makes the event handler testable again, but it’s still impure, so we have not only introduced more complexity to test it, but also, we have lost the two other advantages cited before: local reasoning and events replay-ability.

Since re-frame’s 0.8.0 (2016.08.19) release, this problem has been solved by introducing the concept of effects and coeffects.

Whereas, in our previous post, we saw how coeffects can be used to track what your program requires from the world (side-causes), in this post, we’ll focus on how effects can represent what your program does to the world (side-effects). Using effects, we’ll be able to write effectful event handlers that keep being pure functions.

Let’s see how the previous event handlers look when we use effects:

Notice how the event handlers are not side-effecting anymore. Instead, each of the event handlers returns a map of effects which contains several key-value pairs. Each of these key-value pairs declaratively describes an effect using data. re-frame will use that description to actually do the described effects. The resulting event handlers are pure functions which return descriptions of the side-effects required.

In this particular case, when the automaton is evolving, the evolve event handler is returning a map of effects which contains two effects represented as key/value pairs. The one with the :db key describes the effect of resetting the application state to a new value. The other one, with the :dispatch-later key describes the effect of dispatching the :evolve event after waiting 100 microseconds. On the other hand, when the automaton is not evolving, the returned effect describes that the application state will be reset to its current value.

Something similar happens with the start-stop-evolution event handler. It returns a map of effects also containing two effects. The one with the :db key describes the effect of resetting the application state to a new value, whereas the one with the :dispatch key describes the effect of immediately dispatching the :evolve event.

The effectful event handlers are pure functions that accept two arguments, being the first one a map of coeffects, and return, after doing some computation, an effects map which is a description of all the side-effects that need to be done by re-frame.

As we saw in the previous post about coeffectts, re-frame’s effectful event handlers are registered using the reg-event-fx function:

These are their tests:

Notice how by using effects we don’t need to use tests doubles anymore in order to test the event handlers. These event handlers are pure functions, so, besides easier testing, we get back the advantages of local reasoning and events replay-ability.

:dispatch and :dispatch-later are builtin re-frame effect handlers already defined. It’s possible to create your own effect handlers. We’ll explain how and show an example in a future post.

Segundo Flejesai de 2016

2016-11-04T18:19:11+00:00

En Codesai somos un equipo distribuido. Actualmente trabajamos desde Gran Canaria, Tenerife, Barcelona, Madrid y Oviedo. Hacemos pair programming remoto, mob programming y videoconferencias semanales pero aún es muy importante reunirnos fisicamente un par de veces al año. La primera reunión fue en Las Palmas en Marzo de 2016. Nos sirvió para alinearnos, definir formas de trabajar, tomar decisiones y sobre todo compartir y hacer equipo. Esta segunda edición ha sido también en Las Palmas, los días 27 y 28 de octubre de 2016. El sitio de reunión ha sido espectacular, la sala de formación de la Galería de Arte de Manuel Ojeda, en Triana. Aprovechamos para agradecer a Manuel y Daniel Ojeda esta oportunidad, su amabilidad y su confianza.

Inicialmente esto se llamaba Codesai Summit pero como ahora somos muchos (un fleje), pues se nos ocurrió renombrarlo a Flejesai. Aunque fleje se usa más en la provincia de Las Palmas que en la de Santa Cruz, aceptamos la palabra como canario interinsular :-)

Fue genial contar con Antonio como facilitador durante los dos días de evento, para ponerle foco y sacar todos los temas que queríamos. El jueves facilitó la dinámica Remember the Future donde imaginando que nos encontrábamos 12 meses en el futuro, hablábamos de esos últimos 12 meses como si fueran el pasado. Cada uno tuvo su turno de reflexión y luego de exposición. Alguno tuvo tiempo de escribir El Quijote en 5 minutos. Esto nos permitió a todos expresar metas y objetivos para el año. Ver en qué grado compartimos la visión y en qué grado es divergente. Posteriormente nos quedamos con los puntos más interesantes de todos los que salieron y nos pusimos a analizar juntos el por qué de esos objetivos. Este ejercicio nos sirvió para poner encima de la mesa nuestros valores y principios. Aunque sentimos que compartimos muchos valores y principios, hacerlo explícito nos ayudó a definir y aclarar ideas.

A continuación nuestros principios y valores sin ningún tipo de orden de aparición:

Trabajamos con entrega, lo mejor que sabemos haberlo, aportando el máximo valor que somos capaces.
Contribuir a la evolución profesional de nuestro sector:
- Hacer la vida más fácil a los usuarios.
- Pensamos que los proyectos de desarrollo caóticos deberían ser una excepción y no la norma.
- Eliminar la complejidad innecesaria.
- Transmitir la pasión por lo que hacemos.
Mejorar y aprender constantemente.
La satisfacción del trabajo bien hecho.
Abrirnos a otros puntos de vista.
Alinear trabajo con propósito vital.
Pertenencia y reconocimiento.
Estabilidad y sostenibilidad del grupo en lugar de crecimiento.
Diversidad en el equipo.
Poder dar a los otros lo que nos hubiera gustado tener, por ejemplo una mejor educación técnica.
Poner la tecnología al servicio del bien común.
Evitar hacer daño, evitar que la tecnología se use contra las personas, los animales o el medio ambiente.

En la sesión quedó claro que queremos desarrollar nuevos cursos de formación para armar un catálogo completo. Ya estamos trabajando en ello, recogiendo piedras de conocimiento para luego hacer las composiciones.

Todos pensamos que la web debe expresar mejor lo que hacemos y ser un lugar donde aglutinar nuestras publicaciones, queremos mejorarla. Es muy posible que dejemos wordpress por algo mas simple.

Hemos decidido dejar de utilizar las categorías de Craftsman, Journeyman, Apprentice, Junio y Senior para referirnos a lo que somos, tanto en la web como en las propuestas a clientes. Aunque a priori nos sentimos identificados con la metáfora de la artesanía del software, preferimos que la gente se haga una idea de nosotros a través de nuestros propios principios y valores.

En las propuestas a proyectos para clientes no enviaremos a individuos sino como mínimo parejas. Los costes serán por tanto por parejas o grupos más grandes pero no por persona. Realmente no necesitamos categorizar a nadie. Y queremos trabajar en pares o en grupo como lo venimos haciendo.

Queremos seguir teniendo presencia en eventos importantes de la comunidad, incluso dar el salto a eventos de fuera como SocratesUK. Organizar una nueva edición de Socrates Canaries nos ilusiona.

Queremos balancear la carga entre trabajo de mentor y desarrollador. Nos gusta el desarrollo de producto y por eso buscamos disponer de más días donde somos desarrolladores y no mentores. Nos encanta hacer formación y mentoring pero no que sea lo mayoritario.

Queremos mejorar nuestro conocimiento en el paradigma funcional porque pensamos que puede mejorar la calidad de los productos que hacemos. Mantenernos al día con nuevas tecnologías, por ejemplo temas como React y Redux. Practicar más con arquitecturas como CQRS, Event Sourcing, modelo de actores...

Seguir dándole cuerpo a nuestro programa de aprendices y dar la bienvenida a nuevos aprendices, y si conseguimos que sean chicas mucho mejor.
No queremos crecer en número, crecer por crecer no es ningún objetivo. Pero si llega un momento en que nos sentimos cómodos y nos queremos comprometer a tener un nuevo compañero, pues nos gustaría que fuese una compañera.

Durante el evento aparte de pasar todo el día juntos, tuvimos largas cenas y sesiones nocturnas de charlas técnicas y no tan técnicas hasta la madrugada, donde pudimos compartir conocimiento, que es una de las cosas que más nos gusta del grupo. Echarnos unas risas juntos y algo de trolleo entre nosotros pero en plan sanote.

Hicimos retrospectiva, con un formato muy abierto donde todo el mundo podía expresar su punto de vista y nos ha salido una buena lista de acciones a realizar. Todo queda apuntado para revisarlo periódicamente y cuando nos juntemos en el próximo semestre mirar atrás y ver el avance.

Estos encuentros semestrales son muy motivadores. Ya tenemos ganas del próximo.

Damos la bienvenida a Manuel Rivero

2016-11-02T22:17:14+00:00

Menudo notición! Manuel Rivero se une al equipo Codesai! Fue algo antes de Software Craftsmanship Barcelona 2016 cuando Manuel me escribió expresando su intención de venir. La verdad es que no estabamos buscando crecer en número, pero a todo el equipo le encantó la idea. La mayoría le conocíamos y le tenemos como referente en el aprendizaje, en la comunidad y en muchos otros temas como la programación funcional. Manuel es fuente de conocimiento y no dudamos ni un segundo en aprovechar la oportunidad.

Este post escrito en su blog habla acerca de su motivación para venir, en primera persona.

Le conocí hace ya años en un curso abierto de TDD que impartí en Madrid. Es una de esas personas que se pagó el curso de su bolsillo, incluyendo viaje a otra ciudad, gastos de hotel y días de vacaciones. Este tipo de acciones dicen mucho de un profesional, no dejo de admirar a los que lo hacen y he aprendido mucho de todos ellos, además de que les sigo la pista todo lo que puedo. Desde entonces nos hemos encontrado muchas más veces en Barcelona, por ejemplo en una edición posterior del mismo curso donde me estuvo ayudando y en eventos de la comunidad. Es alucinante observar su evolución a lo largo de estos años. En todas las katas que he estado con Manuel, he aprendido cosas relevantes. Recuerdo, por ejemplo, el double dispatch de Kent Beck que pese a haberlo leído no lo interioricé hasta que nos lo mostró con un ejemplo. Estamos muy ilusionados con todo lo que nos va a aportar, la mejor persona que puede entrar al equipo es aquella que tiene mucho que enseñarte. Desde ya, es nuestro Jedi del Clojure y del paradigma funcional.

Ahora podemos decir que Codesai tiene presencia física en Barcelona, otro motivo más para visitar más a menudo esta maravillosa ciudad.

Este cambio nos ha vuelto a motivar para retomar la preparación de nuevos cursos: Diseño Orientado a Objetos, Patrones, Refactoring y pronto seguro que también nos animamos con lo funcional. También está echando una mano desde ya con el desarrollo de productos para clientes, desarrollos que estamos llevando a cabo en estos momentos, participando en las sesiones de pair programming y mob programming.

Aunque lo anunciamos ahora, ya hace algunas semanas que estamos trabajando juntos. La semana pasada celebramos nuestro encuentro semestral, el Codesai Summit ahora renombrado como Flejesai (#flejesai16) y tuvimos la suerte de que aún estaba Modesto así que estabamos practicamente todos en el mismo lugar y lo pasamos genial. Pronto habrá un post sobre el Flejesai :-)

Aunque no estamos buscando crecer, es decir que no tenemos por objetivo ser más personas, sí tiene que ocurrir nos gustaría mucho que fuese una chica. Pensamos que la diversidad es muy importante. Ahí lo dejo ;-)

Estuvimos en la Software Craftsmanship BCN 2016

2016-11-02T16:14:56+00:00

Descripción del evento

Este año varios miembros de Codesai estuvimos en la Software Craftsmanship de Barcelona. Todo un logro viendo que las primeras entradas fueron arrasadas, algo que habla muy bien de un evento que plantea dudas sobre si debería crecer más.

Por fortuna, aunque las entradas se hayan vendido tan rápido, ha habido mucha cara nueva en el evento, lo que es realmente positivo viendo que el año pasado tardaron casi una semana en terminarse y que en un principio se pensaba que la mayoría de participantes habrían acudido en anteriores ediciones.

A diferencia de la Pamplona Software Craftsmanship que se realizó este mismo año el 17 y 18 de junio, el evento consta principalmente de charlas que se eligen después de que los ponentes las hayan presentado durante el C4P. Durante el último día del evento se dan unas cuantas horas para proponer sesiones para el Open Space. Contar con estos contrastes entre eventos dentro de la propia comunidad es algo muy valioso. Con cada evento al que asistimos nos percatamos que experiencias pasadas de otros eventos acaban reflejándose en mejoras para los siguientes.

Los sponsors del evento han servido a los asistentes con una camiseta chulísima con la temática del evento y nos ofrecieron una bolsa genial con merchandising muy útil durante el evento que nos encantó a la mayoría de los asistentes. También mencionar sobre el lugar, un verdadero acierto, aunque a veces las salas se llenaban mucho y sentarse era una utopía, era muy cómodo estar en ellas y estaban muy bien ventiladas. Algo que se agradece de verdad.

Gracias a la organización!

Sin duda, un gran evento está respaldado por una gran organización. La Software Craftsmanship BCN 16 contó con una de las mejores ;). Había disponible un tablón de feedback desde la primera hora al que le echaban un ojo y procuraban asistir en lo posible. Durante la apertura se explicó el evento, las charlas fueron sobre ruedas, sin retrasos y durante el cierre se realizó una gran retrospectiva. Si es que no se encontraron problemas por ningún lado, muchas gracias y genial trabajo!

Todas las charlas fueron grabadas con el apoyo de Codely.tv y los miembros de la organización, lo cual es un fantástico aporte, pues siempre hay horas en las que no sabes a qué charla ir :)

Durante el evento se agradeció el tener varios momentos en los que era sencillo disfrutar del networking.

El desayuno y la comida (compuesta básicamente por pequeños snacks de la mano de un catering) se ofrecían en mesas repartidas en dos salas. Todo el mundo se dirigía a picar algo de pie mientras charlaba. Se generaba buen ambiente y se abrían las puertas al networking. Por no mencionar que la comida estaba genial!

Además, siempre estaban disponibles la máquina de café y algunos refrigerios para todo aquél que se quedase fuera de una charla mientras conversaba con otros asistentes.

La primera noche del evento se organizó una gran cena en un enorme local muy cerca del evento, a la que asistió casi todo el mundo. Ello permitió que el primer día no acabase a las 19h00 como marcaba la agenda, sino que se extendió hasta bastante tarde (de madrugada para los valientes ;). La cena ayudó a que se dieran más oportunidades para conocer gente y en general aumentó la sensación de participación en el evento más allá de lo que es asistir a las charlas.

Charlas a las que asistimos

Néstor Salceda: Experiencias con Interaction Driven Design.

Néstor nos contó la experiencia de su grupo usando Interaction Driven Design. Nos sorprendió muy gratamente observar cómo grupos distintos, que no tienen mucha comunicación de forma regular, hayan llegado a conclusiones tan similares en el uso de esta arquitectura.

Nos valió para confirmar muchas de nuestras propias ideas. Una charla realmente agradable donde varias personas se animaron a poner código para mostrarnos sus aproximaciones y recibir feedback, entre ellos Alfredo y Ronny.

Carlos Villuendas: Reactjs desde las trincheras, un año después

Carlos asistió el año pasado al evento dando la primera parte de esta charla. En ella comentaba que Fotocasa se había propuesto emplear React.js como librería de Frontend. Un año más tarde, vuelve a comentar cómo ha sido la experiencia. Dando todo un manual en el uso de esta librería basándose en la propias vivencias de su grupo. Una charla genial donde Carlos se mostró dispuesto a explicar con detalle cada cosa que se le preguntaba. Muy inspiradora.

Sergi González y Javier Ferrer: Desarrollar un chat con Scala, Akka y WebSockets desde 0. ¡¿Qué puede salir mal?!

Sergi y Javi nos contaron como en su empresa surgió la necesidad de meter en la aplicación un chat. Ello llevó a una primera implementación de un legacy escrito en PHP y cómo las necesidades de escalabilidad les plantearon usar modelo de actores con Akka y usar Scala como lenguaje de desarrollo. Empezando con una visión pero gran desconocimiento sobre el tema, consiguieron terminarlo después de un año y nos sirven de toda esa experiencia para hablarnos sobre ello, y acabar con nuestras mentes.

Joel Rodríguez: Embracing flow for maximum productivity

Joel nos estuvo contando la complejidad que implica alcanzar el flow y las tácticas que le han resultado efectivas en su experiencia. El flow siempre es algo que nos parece muy abstracto pero que sabemos detectar cuando lo estamos experimentando. Joel intenta convertirlo en algo que alcancemos de forma más consciente.

Xavi Gost: CDD (Desarrollo dirigido por consenso)

Xavi nos estuvo explicando cómo están aplicando esta filosofía de equipo en Flywire. A destacar el rechazo del argumento de autoridad, que implica no obedecer ciegamente a otra persona con mayor autoridad. El argumento siempre debería ser analizado y contra argumentado si fuera necesario, siempre dentro de lo razonable. Rechazar un argumento de autoridad no significa rechazar una mayor experiencia. De forma muy resumida, los equipos están organizados en squads que hacen pairing y no se hacen Pull Requests, sino que todos los miembros del equipo leen el código y son libres de añadir un Concern en una feature que se debatirá en la siguiente Code Review. Se estimula la propiedad colectiva del código y el ambiente de equipo. Una charla que nos aportó mucho valor.

Vaughn Vernon: Event Storming for Fun and Profit

En este workshop de dos horas, Vernon nos brindó una sesión de Event Storming. Esta práctica de descubrimiento de dominio propuesta por Alberto Brandolini, consiste en unir a Product Owners y desarrolladores para crear algo parecido a un diagrama de eventos que nos permite identificar las acciones más importantes de una parte o todo nuestro negocio.

Los asistentes nos dividimos en tres grupos donde modelamos un dominio a nuestra elección. La sesión fue muy divertida y los asistentes del grupo en el que estábamos salieron muy satisfechos con la actividad. Sin duda una práctica muy valiosa para descubrir negocio y que pondremos más en práctica.

Participación de Codesai

Varios de nosotros tuvimos una o más charlas durante el evento. Carlos rompió el hielo a primera hora del primer día dando su charla Designing in the Small. Principles and Practices.

Durante el mismo día Alfredo dio una charla sobre Connascense (que iba a presentar junto con Fran, que no pudo asistir al evento) hablando de los distintos tipos de acoplamiento que podemos tener en cuenta para buscar heurísticas con las que evaluar nuestro código.

Alfredo también participó en el OpenSpace, proponiendo una sesión sobre Microservicios. Durante una de las Lightning Talk, surgió este tema y se notaba que la gente se quedó con ganas de más. Por ello, la sala estaba a reventar y Alfredo se ofreció a empezar el debate en inglés dado que varios asistentes eran nativos. Una charla muy medida y en la que todos salieron muy contentos.

Entre las Lightning Talks, Luis dió una sobre la toma de decisiones en un proyecto que tiene problemas, cómo ser eficiente en la práctica, dando varios puntos y consejos basados en su propia experiencia. Dani dió otra sobre el tema de Lectura Rápida, desmitificando algunos métodos y clarificando cómo la estaba practicando, recomendando su bibliografía.

Luis también facilitó la Kata Potter en el Open Space junto con Álvaro García. La retrospectiva de la kata se comió casi el siguiente slot de tiempo pues hubo un contraste de estilos muy interesante.

Y muchas gracias a los compañeros de Codesai que se repartieron la asistencia a las charlas para luego poner en común lo aprendido, o que las dejaron pasar para hacer networking. ¡Día a día mejoramos como equipo!

Using coeffects in re-frame

2016-10-24T22:17:14+00:00

Event handlers, collectively, provide the control logic in a re-frame application. Since the mutation of the application state is taken care of by re-frame, these event handlers can be pure functions that given the current value of the application state as first argument and the event (with its payload) as second argument, provide a new value for the application state.

This is important because the fact that event handlers are pure functions brings great advantages:

Local reasoning, which decreases the cognitive load required to understand the code.
Easier testing, because pure functions are much easier to test.
Events replay-ability, you can imagine a re-frame application as a reduce (left fold) that proceeds step by step. Following this mental model, at any point in time, the value of the application state would be the result of performing a reduce over the entire collection of events dispatched in the application up until that time, being the combining function for this reduce the set of registered event handlers.

However, to build a program that does anything useful, it’s inevitable to have some side-effects and/or side-causes. So, there would be cases in which event handlers won’t be pure functions.

In this post, we’ll focus on side-causes.

“Side-causes are data that a function, when called, needs but aren’t in its argument list. They are hidden or implicit inputs.”

Let’s see an example:

The event handler for the :word-ready-to-check event, that we are registering using reg-event-db, is not pure because it’s using the value returned by JavaScript’s Date.now function instead of getting it through its arguments. To make matters worse, in this particular case, this side-cause also makes the event handler untestable because JavaScript’s Date.now function returns a different value each time it’s called.

To be able to test this event handler we’ll have to somehow stub the function that produces the side-cause. In ClojureScript, there are many ways to do this (using with-redefs, with-bindings, a test doubles library like CircleCI’s bond, injecting and stubbing the dependency, etc.).

In this example, we chose to make the dependency that the handler has on a function that returns the current timestamp explicit and inject it into the event handler which becomes a higher order function.

In the previous code example, notice that the event handler now receives as its first parameter a function that returns the current timestamp, time-fn.

And this would be how before registering that event handler with reg-event-db, we perform a partial application to inject JavaScript’s Date.now function into it:

Using the same technique, we can now inject a stub of the time-fn function into the event handler in order to test it:

This is the code of the home-made factory to create stubs for time-fn that we used in the previous test:

We’ve seen how using a test double makes the event handler testable again, but at the price of introducing more complexity.

The bottom line problem is that the event handler is not a pure function. This makes us lose not only the easiness of testing, as we’ve seen, but also the rest of advantages cited before: local reasoning and events replay-ability. It would be great to have a way to keep event handlers pure, in the presence of side-effects and/or side-causes.

Since re-frame’s 0.8.0 (2016.08.19) release, this problem has been solved by introducing the concept of effects and coeffects. Effects represent what your program does to the world (side-effects) while coeffects track what your program requires from the world (side-causes). Now we can write effectful event handlers that keep being pure functions.

Let’s see how to use coeffects in the previous event handler example. As we said, coeffects track side-causes, (see for a more formal definition Coeffects The next big programming challenge).

At the beginning, we had this impure event handler:

then we wrote a testable but still impure version:

Thanks to coeffects, we can eliminate the side-cause, passing the timestamp input through the argument list of the event handler. The resulting event handler is a pure function:

This event handler receives, as its first parameter, a map of coeffects, cofx, which contains two coeffects, represented as key/value pairs. One of them is the current timestamp which is associated to the :timestamp key, and the other one is the application state associated to the :db key. The second argument is, as in previous examples, the event with its payload.

The map of coeffects, cofx, is the complete set of inputs required by the event handler to perform its computation. Notice how the application state is just another coeffect.

This is the same event handler but using destructuring (which is how I usually write them):

How does this work? How does the coeffects map get passed to the event handler?

We need to do two things previously:

First, we register the event handler using re-frame’s reg-event-fx instead of reg-event-db.

When you use reg-event-db to associate an event id with the function that handles it, its event handler, that event handler gets as its first argument, the application state, db.

While event handlers registered via reg-event-fx also get two arguments, the first argument is a map of coeffects, cofx, instead of the application state. The application state is still passed in the cofx map as a coeffect associated to the :db key, it’s just another coeffect.

This is how the previous pure event handler gets registered:

Notice the second parameter passed to reg-event-fx. This is an optional parameter which is a vector of interceptors. Interceptors are functions that wrap event handlers implementing middleware by assembling functions, as data, in a collection. They “can look after cross-cutting concerns helping to “factor out commonality, hide complexity and introduce further steps into the ‘Derived Data, Flowing’ story promoted by re-frame”.

In this example, we are passing an interceptor created using re-frame’s inject-cofx function which returns an interceptor that will load a key/value pair (coeffect id/coeffect value) into the coeffects map just before the event handler is executed.

Second, we factor out the coeffect handler, and then register it using re-frame’s reg-cofx. This function associates a coeffect id with the function that injects the corresponding key/value pair into the coeffects map. This function is known as the coeffect handler. For this example, we have:

Since the event handler is now a pure function, it becomes very easy to test it:

Notice how we don’t need to use tests doubles anymore in order to test it. Thanks to the use of coeffects, the event handler is a pure function, and we can just pass any timestamp to it in its arguments.

More importantly, we’ve also regained the advantages of local reasoning and events replay-ability that comes with having pure event handlers.

In future posts, we’ll see how we can do something similar using effects to keep events handlers pure in the presence of side-effects.

Refactoring tests using builder functions in Clojure/ClojureScript

2016-10-07T22:17:14+00:00

Using literals in your tests can have some advantages, such as, readability and traceability.

While this is true when the data are simple, it's less so when the data are nested, complex structures. In that case, using literals can hinder refactoring and thus become an obstacle to adapting to changes.

The problem with using literals for complex, nested data is that the knowledge about how to build such data is spread all over the tests. There are many tests that know about the representation of the data.

In that scenario, nearly any change in the representation of those data will have a big impact on the tests code because it will force us to change many tests.

This is an example of a test using literals, (from a ClojureScript application using re-frame, I'm developing with my colleague Francesc), to prepare the application state (usually called db in re-frame):

As you can see, this test knows to much about the structure of db.

There were many other tests doing something similar at some nesting level of the db.

To make things worse, at that moment, we were still learning a lot about the domain, so the structure of the db was suffering changes with every new thing we learned.

The situation was starting to be painful, since any refactoring provoke many changes in the tests, so we decided to fix it.

What we wanted was a way to place all the knowledge about the representation of the db in just one place (i.e., remove duplication), so that, in case we needed to change that representation, the impact of the change would be absorbed by changing only one place.

A nice way of achieving this goal in object-oriented code, and at the same time making your tests code more readable, is by using test data builders which use the builder pattern, but how can we do these builders in Clojure?

Option maps or function with keyword arguments are a nice alternative to traditional builders in dynamic languages such as Ruby or Python.

In Clojure we can compose functions with keyword arguments to get very readable builders that also hide the representation of the data.

We did TDD to write these builder functions. These are the tests for one of them, the db builder:

and this is the db builder code:

which is using associative destructuring on the function's optional arguments to have a function with keyword arguments, and creating proper default values using the :or keyword (have a look at the material of a talk about destructuring I did some time ago for Clojure Barcelona Developers community).

After creating builder functions for some other data used in the project, our test started to read better and to be robust against changes in the structure of db.

For instance, this is the code of the test I showed at the beginning of the post, but now using builder functions instead of literals:

which not only hides the representation of db but also eliminates details that are not used in particular tests, while still being as easy to read, if not easier, than the version using literals.

We have seen how, by composing builder functions and using them in our tests, we managed to reduce the impact surface of changes in the representation of data might have on our tests. Builder functions absorb the impact of those changes, and enable faster refactoring, and, by doing so, enable us to adapt to changes faster.

Muchas gracias Modesto

2016-10-07T15:57:39+00:00

Hace unas semanas recibimos una noticia con sabor agridulce. Nuestro gran compañero y mejor profesional, Modesto, se marcha de Codesai. No resulta fácil perder a un compañero del que todos aprendemos muchísimo y que siempre está apoyando al equipo ante cualquier dificultad. Pero la verdad es que nos alegramos de que pueda tomar el rumbo que más le beneficie en este momento. Nuestra relación no se ve afectada en absoluto y seguiremos aprendiendo juntos en los eventos de comunidad y meetups de Codesai. Las puertas siempre están abiertas para Modesto. Han sido dos años estupendos trabajando juntos, ¡hasta compartiendo piso!

Modesto habla de la experiencia en un post en su blog. Queremos aprovechar para escribir un pequeño homenaje como muestra de agradecimiento por su entrega y su aporte a todo el equipo. Esto es lo que cada uno de nosotros dice:

Carlos:

He conocido a pocas personas capaces de aprender y asimilar tan rápido como Modesto. Con capacidad de sacarle infinidad de horas de rendimiento al día. Es rápido y eficaz ofreciendo soluciones. No sé cómo le da tiempo a leer tanto. Contar con él como experto en la plataforma .Net suponía una tranquilidad que no tiene precio. Se nos va uno de nuestros mayores tecnólogos. Solo espero que volvamos a coincidir pronto y que le vaya de maravilla.

Fran:

Pragmatismo y capacidad de aprender a un ritmo increíble son dos de las cosas que me llegan a la cabeza cuando intento definir alguna de las cualidades de Modesto como profesional. Sus conocimientos en tecnologías de Microsoft son un seguro de vida para embarcarte en un proyecto que trate con ellas sin temer por su tamaño. Su humor y las ganas de debatir siempre hacen que cualquier charla deje de convertirse en banal para tornarse en alguna discusión interesante. He aprendido mucho estos años de él dentro de Codesai y espero que, aunque quizás con menos frecuencia, lo siga haciendo. No hace falta que le desee suerte allá dónde vaya, ya lleva una mochila repleta de habilidades y experiencias para hacer lo que le apasione.

Alfredo:

Hace ya dos años, madre mía como pasa el tiempo de rápido!, nos juntamos cuatro locos para colaborar y trabajar juntos en un proyecto con mucha incertidumbre y muchas incógnitas, ni cortos ni perezosos cogimos las maletas y allá aparecimos en las palmas. Uno de esos locos era Modesto, y sin duda gracias a sus aportaciones ese proyecto hoy podemos apuntarlo en la libreta de éxitos profesionales y también en la de los personales. Sus conocimientos de .NET han sido fundamentales para compensar las carencias que otros teníamos, no deja de ser sorprendente ver como al final la tecnología es solo un detalle y lo que nos une como profesionales esta en la pasión por nuestro trabajo y en las prácticas y los principios esos que tan pesados somos repitiendo y no voy a enumerar ahora. Mucha suerte en tus proyectos futuros!, y para terminar tópicazo: esto no es un adios es un hasta luego, porque al final este mundo nuestro es más pequeño de lo que parece y el camino del craftsman esta lleno de cruces e intersecciones.

Luis:

No me cabe la menor duda que Modesto disfrutará y dejará huella allí donde esté. A mí me gustaría destacar su lado humano: la capacidad de ponerse en el lugar del otro y hablar desde ahí. Con una facilidad para hablar claro y mantener un debate profundo a la vez que aportar toques de humor cuando hay que relajar el ambiente. Muchas gracias por tu disposición a echar una mano siempre. Nos vemos en el camino.

Ronny:

Hablar de Modesto para mí es en primer lugar hablar de una persona a la que aprecio muchísimo. Desde el día que lo conocí en un coding dojo hasta hoy que escribo esto, no he parado de aprender de él. Sin duda, es una de las personas más inteligentes que conozco, pero si hay algo que me gustaría resaltar de él, es su pasión por el software. Me ha transmitido grandes valores como la humildad y la transparencia, aprender de Modesto no solo me ha hecho mejor programador sino que también me ha ayudado a ser mejor persona. Para mí es sin duda un ejemplo a seguir. La primera semana que estuvimos en el piso fue impresionante, la recuerdo perfectamente, buscamos un pet project, me enseñó a usar dobles de pruebas, me enseñó que eran los diagramas de secuencia y más. Pero eso no es todo, sino que ha medida que ha ido pasando el año, cada semana que hemos coincidido en el piso ha sido brutal. Aprender de alguien que es técnicamente tan bueno es increíble, hemos tenido mucha suerte de contar con él. Así que Modesto, me gustaría darte las gracias. Gracias por todo lo que me has transmitido este año, gracias por mostrarte siempre dispuesto a enseñarme, gracias por todos tus consejos y gracias por ser en definitiva una gran persona. Espero que te vaya muy bien en este próximo paso en tu camino (sé que así será). Aunque profesionalmente hablando nuestros caminos se separen, para mí seguirás siendo siempre un mentor, un compañero en el camino del aprendizaje y sobre todo un gran amigo. Espero que sean excusas suficientes para seguir teniendo nuestras largas conversaciones sobre nuestra gran pasión. Además tenemos un pet project que mantener. Mucha suerte!

Miguel:

Cuando pienso en Modesto siempre se me viene a la cabeza, la palabra fascinación. Fascinación por su conocimiento técnico, fascinación por las reflexiones personales que me ha brindado, fascinación por la pasión que trasmite con un teclado en las manos y fascinación porque solo necesita dormir 4 horas al día y estar más descansado que yo :P. Creo que como grupo hemos tenido mucha suerte de contar con tu presencia, no solo por la más que conocida capacidad técnica en .NET sino porque he aprendido que no hay que tener miedo a arremangarse y meterse en el fango para solventar problemas a los que preferirías no enfrentar y hacer otras cosas ya que puedes aportar valor en ese área. Me has enseñado a tener mucho más espectro en el significado de aportar valor y quiero agradecer la cantidad de horas que nos has dedicado con nuestros pet projects, de tener una duda a altas horas de la noche y conectarte a echar una mano y dar tu punto de vista y de no tratar de servirnos en bandeja la respuesta y dejarnos experimentar por el "aprendizaje por dolor". Muchas gracias por todo y de verdad espero que como menciona Alfredo, nuestros caminos se vuelvan a cruzar porque un camino es siempre mejor si vas acompañado de personas fascinantes.

Dani:

Ahí donde vaya la conversación, Modesto siempre surge con un: "Pues una vez hice eso" o "En tal momento trabajé en algo similar". Lleno de experiencia y con infinidad de recursos, dedicándole un buen cacho del día a seguir investigando temas, pero siempre con tiempo para responder una pregunta o echarte un cable con lo que sea. Coincidimos en muchas cosas y diferimos en otra tantas, una conversación con Modesto siempre es productiva y acabará con algo nuevo aprendido. Seguiremos charlando y nos seguiremos viendo ;), muchas gracias por todo!

Jose:

Personalmente, cuando pienso en Modesto, una de las primeras cosas que se me vienen a la mente es su experiencia y su capacidad de resolución. Me hubiera encantado haber trabajado en algún proyecto con él, aunque lamentablemente no ha podido ser así. Independientemente a ello, considero que he aprendido mucho de él, ya que en cada conversación con Modesto obtienes nuevos conocimientos.

A todo esto, muchas gracias por todo Modesto, por compartir tus conocimientos y experiencias con nosotros. Es una pena que te vayas del equipo, no obstante, espero que tengas mucha suerte en tu nueva etapa y que todo te vaya muy bien.

Antonio:

Esta debe ser la cuarta vez que empiezo mi parte de este post porque todos me suenan a epitafio.
Supongo que es porque tengo una gran sensación de pérdida y hoy sin ir más lejos, pegándome con .NET creo que vamos a echar de menos su conocimiento en el equipo.

Gracias Modesto por esas conversaciones profundas. Y por enseñarme que después de un buen intercambio dialéctico se puede tener el coraje y la humildad de reconocer cuando se ha cambiado de opinión. Muy pocas veces he visto eso.

¡Ala! ¡Mucha suerte en tu nueva etapa y a dar guerra en la comunidad!

Estuvimos en Habitissimo

2016-10-07T11:39:27+00:00

Gracias a Pablo Bernardo y Jordi Llull de Habitissimo, pudimos disfrutar de tres días de trabajo y conferencias en Palma de Mallorca, en el ParcBit. Fuimos Luis Rovirosa y yo a impartir una formación de TDD y Clean Code para 15 developers entusiasmados con aprender. Nos sorprendió gratamente el ambientazo de trabajo tan bueno que se respira allí y lo chula que es la oficina, con sus salas temáticas para reuniones, ocio y hasta espacio para meditación. La gente tenía muy interiorizado lo de ser productivo con la herramienta, manejaban casi todo con shortcuts, los entornos de desarrollo eran rápidos y pulidos... gente muy joven con una capacidad de aprendizaje muy alta, las pillaban al vuelo.

Durante la formación hicimos pair programming de una manera bastante ergonómica con dos teclados, dos ratones y dos pantallas conectadas a cada máquina. El espacio de trabajo quedaba muy cómodo tanto para los participantes como para nosotros que paseábamos por detrás observándoles trabajar o participando en las discusiones.
Lo pasamos muy bien.

Conocer y trabajar para Habitissimo era especialmente atractivo para mí porque en 2010 nosotros habíamos emprendido con Maven Charts, la misma idea de Habitissimo, pero que no conseguimos rentabilizar. Aprendimos muchísimo pero económicamente fracasamos. Ver que a pesar de toda la competencia y de lo difícil que se presentaba el mercado nacional, alguien había conseguido hacer triunfar la idea, me alegra mucho. Fue un placer conocer a los fundadores y charlar un ratito con ellos. En cierto modo era como ver "mi idea" triunfar.

El último día tuvo lugar un Code Retreat abierto a todo el mundo donde vino mucha gente para ser un día laboral, fue todo un éxito de convocatoria y lo pasamos muy bien. Por la tarde hubieron conferencias pero como teníamos vuelo nos quedamos con la pena de ver solamente una, la de Juan Lladó sobre su experiencia con TDD, charla que me gustó mucho. Yo abrí la jornada de charlas con una sobre diseño.

En una de las salas de ocio había una hamaca y enseguida me acordé del video de Atlassian Spooning así que nos queda una foto para el recuerdo gracioso. No sé si después de mostrarles el vídeo harán spooning en la hamaca :-D

Lo que me aporta TDD

2016-10-07T10:04:16+00:00

Hace tiempo que vengo queriendo reescribir nuestro libro de TDD para mejorarlo con todo lo que hemos aprendido en estos 7 años y todo el feedback que hemos recibiendo por parte de los lectores, a los cuales estamos muy agradecidos. Pero no se cuándo me podré sentar durante un puñado de meses a abordar semejante reto.

Sin embargo, los atículos y críticas destructivas que se leen sobre esta práctica de vez en cuando, tanto en inglés como en castellano, hacen que me apetezca volver a hablar de lo mucho que me aporta esta práctica.

Lo que me aporta TDD

A los programadores nos encanta el feedback rápido, todos los que disponemos de algún REPL en nuestro lenguaje, estamos encantados. En el browser es facilísimo abrir la consola para escribir una línea de JavaScript y averiguar si determinada expresión se evalúa como creemos. Igual pasa con las consolas de Ruby y de Python. Hasta para C# suelo tirar de C# Pad muchas veces, y de "Inmmediate Window" en VS. Hacer pruebas rápidas y pequeñas en un REPL es una forma de TDD a mi modo de ver. Te permite avanzar en pequeños pasos seguros. A veces practicando TDD escribo un test que poco más tarde borro, porque lo único que quería era feedback rápido, no pretendía dejar una prueba escrita.

TDD Cycle¹

El otro gran beneficio que obtengo practicando TDD es la simplicidad. Soy un experto complicándome la vida, pero gracias a la regla de escribir el código mínimo para que el test pase y nada más, consigo implementaciones mucho más simples de las que me quedaban antes. El prestar mucha atención a las generalizaciones progresivas, como dice Transformation Priority Premise, hace que ahora use más veces la recursividad, en soluciones que naturalmente son recursivas. Antes simplemente me volvía loco con bucles. Un efecto secundario de ir al mínimo es que se me ocurren casos de uso que ni se me habían pasado por la cabeza, a veces casos límite. Es decir que el truco de hackear la implementación para que el test pase me hace ser consciente de casos importantes a cubrir, que quizás nunca hubiese tenido en cuenta. Por tanto me ayuda a encontrar problemas más temprano.

TDD me obliga a pensar antes de codificar. Si escojo un enfoque inside-out, tengo que haber descompuesto muy bien el problema antes para estar seguro que esa pieza de bajo nivel me va a encajar en el puzzle. Si escojo outside-in me obligo a pensar en dependencias, paso de mensajes, diseño orientado a objetos. Pienso que TDD no lleva a un buen diseño por sí, pero teniendo conocimientos de diseño, me ayuda a detectar problemas en el mismo. Por ejemplo cuando me cuesta mucho escribir un test, es porque me faltan piezas en el diseño, porque el área que estoy explorando todavía no es la más adecuada, porque estoy introduciendo demasiada complejidad.... lo tomo como una pista para replantearme el camino elegido. Y acompañado además por los micro-commits, puedo volver atrás en cualquier momento y tomar otro camino de la solución.

JB Rainsberger dice por ejemplo que cuando hace TDD prefiere usar mocks en lugar de spies, porque los dolores a la hora de usar dobles son mas evidentes y eso le da más pistas sobre su diseño (ver los comentarios del post).

Con TDD no me atasco, el avance es constante, me permite entrar en flow. No tengo que depurar! practicamente nunca tengo que depurar y cuando esto sucede es otra pista de que he dado un paso demasiado grande a la hora de descomponer el problema o de que necesito descansar porque hay un typo muy chorra que no consigo encontrar.

No vale para todo

Hay muchísimas situaciones en las que no hago TDD, por ejemplo cuando estudio una nueva tecnología o API de un tercero. Todo gira en torno al feedback, la simplicidad y la cadencia. Cuando voy a poderle sacar partido lo uso y cuando no, pues no lo uso. Igual que ocurre con cualquier herramienta de las que tenemos disponibles. A veces al introducir una pequeña funcionalidad en un código existente o al hacer un pequeño cambio, consigo ir más rápido escribiendo el código primero, probando a mano la aplicación y después dejando un test automático de respaldo. Sucede tipicamente en sistemas legacy donde los tests tardan mucho en ejecutarse o es tan dificil de añadir un test que valido la hipótesis primero probando a mano y luego ya agregando el test.

Y tu que también practicas TDD, ayúdame a recordar más beneficios, deja un comentario please ;-)

¹Figure from Growing Object-Oriented Software by Nat Pryce and Steve Freeman.

Estuvimos en la Tarugoconf

2016-09-23T08:05:17+00:00

¿Qué es la Tarugoconf?

El viernes pasado, 16 de septiembre de 2016, asistí como orgulloso representante de Codesai, al mejor evento posible que cupiese en la imaginación de David Bonilla: la Tarugoconf. Un evento que nunca hubiese existido si no le hubiesen dicho las tres palabras mágicas "No hay huevos" y que se construye bajo las siguientes premisas: Utilidad, Practicidad, Diversión y Calité.

Citando la web:

¿Qué carallo es esto?

Sólo 100 entradas a la venta. 1 sólo día, 1 sólo track y 1 sólo objetivo: crear el evento sobre construcción y comercialización de Productos Digitales más awesómico y gallego del mundo. Lleno de ponentes con muchos tiros pegaos en las barricadas del mundillo tecnológico y que, en sus charlas, intentarán responder una simple pregunta:

¿Qué cambiaría si pudiera volver 2 años atrás?

El previo

Cuando presentó el evento por primera vez e informó que las entradas iban a ser por invitación, sabía que no iba a sentar bien y así fue. Escuché muchos comentarios y ninguno bueno; al que no le parecía innecesariamente exclusivo (como sinónimo de excluyente), le parecía que iba a ser carne delicatessen para trolls. Como reflexión David ya comentó, que para siguientes sólo una parte sería bajo invitación y el resto abierto a todo el mundo que quisiera venir.

A mi me parece un sistema tan bueno como cualquiera. Se quedó gente fuera, que hubiese pasado igual y en esta conferencia el tamaño sí importaba.

Ah! ¡Y el evento era dos días! Organizaron para el sábado una día de 'networking family friendly' realmente prometedor. No lo disfruté, será para la próxima.

El evento

Y llegó el gran día. Registro y café con bollos con un ambiente algo festivo. Había gente de todo el ecosistema: desarrollo, coaching, empresa, StartUps, ... caras conocidas y no tanto que invitaban a saludarse. Había conexión.

Inaugura David con una minikeynote de 15 minutos en las que nos presenta la agenda, cosas prácticas como dónde estará la pulpeira, cómo ir a la fiesta por la noche y lo más importante, la motivación de la conferencia y por qué estamos aquí hoy. Fue un momento con un montón de energía que nos ponía en situación de lo que iba a venir.

Para hacer el resumen siguiente me voy a fijar en mis notas hechas con dibujitos. También podéis ver el trabajo de Javier (@oyabun) haciendo el Live recording del evento.

Comienza Javi Santana, CTO de Carto con "Crear software para empresacas que manejan pasta de verdad".
La idea principal que transmite es que si quieres "gallina" hay que ir a por la empresa, a instalar "on premise". El cloud, la solución SAAS tiene un rendimiento muy bajo. Luego tienes que montar un super-equipo: Soluciones (Ninjas), Sales, Soporte (aka psicólogos). Refuerza algo que ya sabemos, que no hay que parar de investigar, si paras te mueres. Y termina con un mensaje, que el dinero mola, pero divertirse más.
Me gustó mucho, divertida, bien estructurada y conceptos claros.

A continuación le toca a Jorge Galindo, Product Manager de 47 Degrees, una empresa que hace software para todo el mundo desde sus oficinas al lado de la Peña Camarón, en Puerto de Santa María, Cádiz, con un par. Su charla se tituló "Emprender en provincias".
Nos contó la historia de cómo llego 47 Degrees (latitud de Seattle) a Cádiz. Como pasó la empresa por lo estados de "mundo de piruleta", "hecatombe mundial" y a quedarse sin pasta. Desde Cádiz se tuvo que reinventar empezando en corto, consiguió llegar a empresas de Madrid tirando de networking y les fue muy bien (por aquí pasó muy rápido, me hubiese gustado saber un poco más de este éxito). Pero entraron en un bucle de mucho curro y poca pasta que les obligó a fijar un punto de no retorno en el tiempo en el que buscarían otra cosa.
Estando Raúl Raja de vacaciones en Cartagena, leyó un artículo sobre Scala, llamó inmediatamente a Jorge para decirle que tenían que cambiar a Scala ya. Y él le respondió: "¡Del tirón!... ¿Cómo dices que se escribe?". Aparte de la broma encontraron un nicho en la programación funcional que a base de investigar, mucho open source y atraer talento, les salvó el c... ¡Hicieron hasta un framework!
¿Qué cambiaría Jorge? Detalles, porque estás donde estás gracias a todas las experiencias. La pregunta que te tienes que hacer es si te gusta lo que eres y lo que estás haciendo.

Alguna idea: Todos los viernes mandan un correo a todo el mundo con información de en qué proyectos están y a menudo organizan actividades para todo el mundo.
Les preocupa crecer por encima de 30, por si se pierde la "magia" (palabras literales), tema que me suena bastante.
Charla muy potente, con buen ritmo. Quizás en la historia hay algún hueco que creo que se podría profundizar porque daría claves de cómo emprender desde fuera de Madrid, algo muy interesante para Codesai, sin duda.

Antes del café una minicharla de IBM, en la que muestra la arquitectura de Cloud e IoT que hay detrás de mover un BB-8. Un toque geek molón rápido y a la yugular.

Después del café empieza Jimena Catalina, con la charla "Sácale provecho a tu diseñador" (aunque en el programa era "La culpa SIEMPRE es del diseñador"). Jimena es Diseñadora visual freelance y tiene proyectos propios como Recetas de Rechupete. Me gustó escuchar a alguien más pegado al proceso de desarrollo que veo día a día.
Nos explica que es fundamental que el diseñador entienda el proceso de negocio. Hay que trabajar muy cerca del equipo, porque no sólo es diseñarlo, es colaborar en lo que luego hacen con él.
Destaca la importancia de un buen feedback, e intentar hablar del concreto, o qué se quiere conseguir, no de emociones.
La mejor frase: "Diseño NO es arte, no expresamos nuestras emociones. Somos artesanos al servicio, resolvemos necesidades"

El toque de inversor potente vino a cargo de Juanjo Mata. Español en los USA desde hace 25 años con un acento para pronunciar el inglés que cuando lo oyes piensas: "A este seguro que le entienden". David dice que es gallego, pero Juanjo mencionaba mucho a Toledo, no se porqué. En su twitter dice que es COO en Teambox.
"Si quieres vender necesitas un VP de Ventas" y nos mostró una tabla de sueldos mareantes, todos con seis cifras. Comentó que en USA dan dinero por un 5% y te dejan trabajar y que en España siempre quieren influenciar en el negocio. Y expresó con impotencia que es muy difícil montar allí un equipo tecnológico estable, hay tanta oferta que se van a los dos días, lo que es un problema para conseguir ritmo.
Fue una charla muy técnica, llena de siglas que no recuerdo y me enteré de muy poco, cosa que me hizo preguntarle: "Como técnico que ayuda a Startups, ¿debería aprender más de inversión, en vez del siguiente framework?". Su respuesta fue que solamente si quieres, aunque alguien tiene que saber de todo esto en la empresa.

Ya oliendo el pulpo vino Molpe (Alberto Molpeceres), que se ha especializado en que tu negocio pueda cobrar online, con su charla que en la agenda venía como "Lo que diga Molpe" y que él renombró "Family Business".
Nos dejó a todos destrozados. Una reflexión muy profunda de lo que significa (¡y lo que cuesta!) conciliar de verdad.
Cinco puntos:

Distingue trabajo de hogar, que no te vean todo el día al ordenador.
Agenda compartida, respeta los huecos comunes, no pongas la empresa como excusa.
Las distancias importan.
Todos o ninguno, intenta que los eventos sean un viaje familiar.
Todo el mundo juega un rol. Involucra a todo el mundo en tu trabajo, en tus éxitos, en tus preocupaciones.

El turno de preguntas convirtió la sala en una terapia de padres y madres expresando sus problemas en el día a día en un nuevo escenario para muchos.
No se si fue la mejor charla, pero sí la que más voy a recordar. Por lo inesperado del tema y lo bien tratado. Me llevo un montón de ideas para implementar en casa.

La comida tremenda. La cantidad de pulpo, empanada, tortilla que me pude comer, sólo se queda pequeña comparada con la que desearía haber comido. Muy buen lugar, en un solar al lado del Campus, y muy buen ambiente para seguir saludando a los que todavía no habíamos podido.

Después de comer Inés Luna, experta en atención al cliente con la charla "Usuarios, clientes y animales ¿Son todos iguales?"
Se centró en lo importante que es tener un buen equipo de soporte, que además esté muy en contacto con producto, tanto para saber cuándo salen las siguientes funcionalidades, cuando se resolverán ciertos errores o para dar ideas.

A continuación Diego Mariño con "Así crearía Ducksboard en 2016". Diego fue fundador de Ducksboard, que fue adquirida por New Relic, de la que ahora es Principal Product Manager.
Diego charló con el público más que una presentación. Habló de sus experiencias en Ducksboard y en USA. Buen ambiente vespertino.

Y para terminar subió al escenario Jesús Monleón para hablar de "Cómo montar un equipo comercial para salir a vender con el cuchillo entre los dientes". Jesús es inversor en SeedRocket y fundador de Offerum entre otras, siempre como responsable del equipo comercial.
Jesús nos llevó a sus inicios en eMagister con unas historias desternillantes sobre cómo se consigue vender algo. Entre mucho humor negro nos contó con detalle las interioridades de un equipo comercial.
Una charla muy personal y a veces dura que puso buen broche a las ponencias del día.

Y después del zumo terminamos con la Mesa Redonda de Medios Digitales: "la vida más allá de la publicidad y el CPM"
Conversación claramente para iniciados en el mundo del contenido y lo que significa ganar dinero con gente que viene a verte sin tener que cobrarles. En general estaban bastante alineados.

Despedida

¡Y va terminando el evento!
Bonilla se sube a la palestra y nos cuenta los datos internos económicos de la Tarugoconf. El resultado sale positivo, pero nos aclara que es porque no ha tenido que pagar por varias cosas: como la sala (gracias a Campus Madrid), la web del evento (gracias a Space Nomads) y algo tan increíble como los vuelos de Juanjo Mata y Diego Mariño desde EEUU, ¡que se los pagaron ellos mismos! Así que si contase con todos esos gastos el evento perdería mucho dinero.

A continuación da las gracias especialmente a Candela, Yerai y Jero.

Nos comparte la certeza de que los eventos "de autor" son el futuro: Línea editorial, Experiencia, Networking y conseguir Leads valiosos, por encima de un CFP genérico y hacer branding personal.

Sobre si habrá Tarugoconf 2017, dice ahora mismo no le apetece, pero que sabe que alguien pronunciará las tres palabras mágicas... así que se despidió "¡Hasta el año que viene!".

Bola extra

Javier Alonso (@oyabun) hizo un trabajo magistral, haciendo el 'Graphic Recording' de todo el evento. Impresionó a todo el mundo. ¡Gracias y Enhorabuena!

Feedback

Me acaba de llegar un correo en el que David nos pide feedback, lo dejo por aquí también:

Para repetir:

Tiempo para preguntas. 30 minutos de charla y 15 de preguntas.
El buen ambiente entre los asistentes, cada charla fantástica.
La tortilla caliente y poco cuajada.

Para mejorar en la siguiente:

Un pequeño break entre charlas. Cinco minutos para despejar la mente.
La promesa de salir del evento con 10 contactos hiper-curated creo que no se cumplió. Seguro que no lo di todo conociendo gente, pero creo que si uno de los objetivos era ese habría que intentar alguna idea más para el año que viene.

En resumen

Muy potente, mucha energía, un ambiente espectacular donde podías encontrar a un montón de compañeros y a los que no conocías sabías que iban a ser igual de interesantes; un conjunto de ponentes muy cuidado, con una presentación robusta y con mensajes e ideas claras.

Una gran oportunidad para poder aprender de gente que se ha pegado muy duro y con ideas para llevar para aplicar desde ya.

Fotos

Live Sketching de Javier (@oyabun)

Mis notas #sketchnoting

Fotos oficiales de la Tarugoconf

Mis fotos

Recorriendo poco a poco el libro "Understanding the 4 rules of simple design"

2016-09-14T09:16:31+00:00

Kata del Juego de la Vida de Conway

En mis primeras semanas en Codesai he hecho la kata del Juego de la Vida de Conway como parte de mi formación para empaparme de la cultura y valores de la empresa.

La hice dos veces: la primera ha sido TDD inside-out en Javascript con Karma, Mocha y Chai, y la segunda TDD outside-in con Groovy y Spock. Dejo aquí mis enlaces al github donde se ve en cada commit qué decisiones he ido tomando siguiendo el ciclo: ROJO -> VERDE -> REFACTOR.

Para ver una buena explicación de las diferencias de hacer TDD inside-out e outside-in, podéis leer este post: TDD: Outside-In vs Inside-Out en el fantástico blog de Adictos al Trabajo.

Después de hacer estas dos katas, he leído el libro “Understanding the 4 rules of simple design” y he comparado mis decisiones.

Lo que viene a continuación no es un resumen, son comentarios de lo que más me ha llamado la atención, así que te recomiendo leer el libro antes de seguir. Es corto, en un día lo tienes hecho.

Resumen y comentarios del libro “Understanding the 4 rules of simple design”

El libro empieza muy fuerte, con los prólogos de Kent Beck y J. B. Rainsberger de los que se sacan auténticas perlas:

Foreword from Kent Beck

Is wrong “Design for the future. Change is expensive. Make it cheap by anticipating it.” This looked like a positive feedback loop to me: more speculation -> worse design -> more speculation.

The good news about disastrous positive feedback loops is that you can generally drive them backwards.

I first experimented by ignoring any changes that seemed like they would happen longer than six month in the future. My designs were simpler, I started making progress sooner, and I stressed less about the unknowable future. I shortened the time horizon to three months. Much better.

One month. More. A week. A day. Oh, hell, what happens if I don’t add any design elements

Es muy gráfico cómo relata una especie de evolución de su pensamiento sobre qué pasaría si no adelantamos nada de supuestos futuros.

Buceando un poco desde el enlace que da en el prólogo, llegué a un artículo de Martin Fowler sobre estas reglas de diseño donde pone la siguiente cita de Kent Beck:

At the time there was a lot of “design is subjective”, “design is a matter of taste” bullshit going around. I disagreed. There are better and worse designs. These criteria aren’t perfect, but they serve to sort out some of the obvious crap and (importantly) you can evaluate them right now.

The real criteria for quality of design, “minimizes cost (including the cost of delay) and maximizes benefit over the lifetime of the software,” can only be evaluated post hoc, and even then any evaluation will be subject to a large bag full of cognitive biases. The four rules are generally predictive.

– Kent Beck

Creo que define muy bien lo que significan las buenas prácticas: Estos criterios no son perfectos, pero sirven para detectar algo de la basura más obvia y (lo más importante) puedes evaluarlo inmediatamente.

En un entorno de trabajo donde cualquier decisión es cuestionable, tener reglas básicas para distinguir el ‘crap-code’ ayuda mucho a las conversaciones dentro del equipo

Foreword from J. B. Reinsberger

El siguiente prólogo está realmente bien. Pues ayuda a profundizar y hacerte una idea de las conversaciones que puede haber detrás de algo aparentemente tan sencillo como las cuatro reglas.

Destaco como antes, no textos del prólogo, sino de los posts relacionados de JB. Son mencionados en numerosas ocasiones por todos los autores vistos hasta ahora y se recomiendan incluso por Corey Haines en el propio libro.

The four elements of simple design

When I find fifteen lines of duplicate code, I start by extracting them to a new method, and since I probably don’t yet know what those lines of code do yet, I name the new method foo(). After around 15 minutes of working in the same area, I begin to understand what this method does, so I give it an accurate name, such as computeCost().

[…]

That leaves me with two key elements of simple design: remove duplication and fix bad names. When I remove duplication, I tend to see an appropriate structure emerge, and when I fix bad names, I tend to see responsibilities slide into appropriate parts of the design.

[…]

I claim that developing strong skills of detecting duplication, removing duplication, identifying naming problems, and fixing naming problems equates to learning everything ever written about object-oriented design.

Este post es oro puro, el primer párrafo me encanta, pues dar nombres a métodos o clases, es la tarea más difícil del desarrollo. Aquí da una pista muy buena.

El siguiente post relacionado de JB, es la continuación del anterior, e intenta cerrar la ‘guerra’ abierta sobre el orden de importancia de las cuatro reglas.

Putting an age old battle to rest I don’t think it matters whether you focus first on removing duplication or on revealing intent/increasing clarity, because these two guidelines very quickly form a rapid, tight feedback cycle. By the time the guidelines guide you to any useful results, you’ll have probably used them both. Therefore, order the rules however you like, because you’ll get to the same place either way.

…

When we remove duplication, we create buckets; when we improve names, we create more cohesive, more easily-abstracted buckets.

…

Now, I think of them as a single guideline: remove duplication and improve names in small cycles. When I do this, I produce a higher proportion of well-factored code compared to all the code I write.

…

Removing duplication and improving names helps me reduce the liability (cost) of the code that I write. Together, they help me reduce both the total cost and the volatility of the cost of the features I deliver.

En estos tres párrafos habla de tres temas muy potentes:

Cerrar la guerra sobre el orden
Cohesión
Coste

Introduction: This book

Me encanta esta introducción. Habla con más claridad de lo que hemos visto hasta ahora: cómo las cuatro reglas se retroalimentan, incidiendo en lo comentado por JB.

Recalca como Kent Beck que no ve que haya diseños buenos y malos, e incluso que puede haber varios buenos diseños. A partir de ahí, comparándolos se podría llegar a un consenso de las ideas fundamentales de por qué un diseño es “mejor” que otro.

If we can look at things from a comparison point of view, perhaps we can find some fundamental ideas about “better”.

Termina formulando las dos constantes en el desarrollo de software, acompañado de un tweet de Sandi Metz: “Habrá cambios pero no sabemos qué es lo que va a cambiar”

Examples

A continuación entramos en materia del libro con diferentes ejemplos divididos en capítulos (respeto los títulos en inglés), como si fuéramos construyendo desde cero el Juego de la Vida.

Test Names Should Influence Object’s API

// Test: Check world is empty
// NO
world.cell_alive_at(1,1)?
// YES
world.empty?

Hay que usar nombres de test de hablen de negocio, y construir un API apropiada. Si usamos nombres de test orientados a datos, corremos el riesgo de construir un código que expone información que no es responsabilidad de la clase.

Duplication of Knowledge about Topology

class LivingCell
    attr_reader :location
end class

Aquí, Corey Hanes propone poner la localización dentro de la celdas, para no duplicar el conocimiento acerca de la topología del sistema, como en el código visto antes.

Pensé en hacer esto, pero tal como estaba resolviendo el problema, no podía mover o quitar el conocimiento de la ubicación de las células fuera de la clase Grid, que está un nivel hacia afuera: lo necesitaba para recorrer la malla y calcular la siguiente iteración y para calcular el número de vecinos.

Como experimento para esta kata, la estructura de datos en la que almacené las células de la malla, una estructura de dos dimensiones, fue en un tipo List, unidimensional. Y para consumirlo, desarrollé una especie de Iterable y el acceso a un elemento concreto con paginación.

Así, el primero de los problemas que comento lo tenía resuelto, no se iba a recorrer la malla.

El segundo problema, el de calcular el número de vecinos es el que no supe cómo resolverlo. ¿Cómo podía acceder a los vecinos de un elemento, si la posición que ocupan la tiene solo los elementos? ¿Cómo accedo a un elemento concreto de la malla?

Después de terminar la kata, se me ocurrió una solución a esto. Podría haber usado métodos como .filter() sobre el List, para buscar elementos. No es muy eficiente, pero consigue lo que se quiere, abstraes la localización del Grid y se lo pasas a las células, lo probaré para la próxima.

Behavior Attractors

Whenever we have a new method — a new behavior — an important question is “where do we put it?” What type does this belong to?

Siempre que tenemos un nuevo comportamiento la pregunta es dónde lo ponemos.

En el libro recomienda no pararse demasiado a analizar dónde ubicarlo. Buscar rápidamente un sitio. Si nos encaja, perfecto; pero si no, tenemos que moverlo. Además cuanto antes para que luego con el uso no sea más difícil.

// Where do we put neighbors?
// Location seems perfect.
class Location
     attr_reader :x, :y
     def neighbors
         # calculate a list of locations
         # that are considered neighbors
      end
 end

Destaca que a través del proceso de eliminar la duplicación de conocimiento de manera agresiva es como conseguimos clases que atraigan comportamientos. Y como corolario, si intentamos eliminar esa duplicidad y no encontramos dónde colocarlo es que nos falta alguna abstracción.

En el ejemplo de código, me llamó mucho la atención poner los neighbors en Location. Porque eso significa que es un dato que se guarda, no un dato calculado al momento del tick. Interesante para explorar.

Testing State vs Testing Behavior

En este apartado habla que hay que testear el comportamiento y no el estado, y pone como ejemplo que lo primero que comprueba en la kata es:

world.empty?

Yo lo que pensé que era el primer comportamiento era algo como:

world.stable?

Es decir: “¿Es el sistema estable? ¿Hay que hacer una siguiente iteración? ¿Cuál es la condición de parada?”. Comentándolo con los compañeros, parece que afronté el problema desde demasiado afuera. Outside-in no quiere decir literalmente: “Desde la capa más exterior, hacia dentro”.

Don’t Have Tests Depend on Previous Tests

def test_an_empty_world_stays_empty_after_a_tick
     world = World.new
     next_world = world.tick
     assert_true next_world.empty?
 end

Rather new world is empty, let’s explicitly ask for an empty world.

def test_an_empty_world_stays_empty_after_a_tick
     world = World.empty
     next_world = world.tick
     assert_true next_world.empty?
 end

Si cambiamos el constructor base y devuelve otra cosa que un mundo vacío, el primer test continuará pasando. Para evitar esto, quien invoque al objeto no debería usar el constructor base con la confianza que vendrá con un estado específico, y menos en la preparación del test, debería usar un ‘constructor’, un ‘builder’, para crear un objeto con un estado concreto y válido.

Esto me parece simplemente genial. Dejar de confiar en los constructores y crear builders que te den el objeto en el estado deseado. Es un problema que me encuentro de manera recurrente, no confío en los datos que tengo al preparar un test.

Breaking Abstraction Level

def test_world_is_not_empty_after_adding_a_cell
     world = World.empty
     world.set_living_at(Location.new(1,1))
     assert_false world.empty?
end

Este tests está acoplado a una capa de abstracción que no es la suya, por lo que si se cambia el sistema de coordenadas a tres dimensiones, por ejemplo, fallarán tests que no tienen nada que ver.

El libro recomienda en este caso hacer un doble de test que abstraiga de ese detalle. Otra opción puede ser usar un helper que de cree ese objeto de coordenadas y así solo está definido en un sitio.

def test_world_is_not_empty_after_adding_a_cell
    world = World.empty
    world.set_living_at(Object.new)
    assert_false world.empty?
end

Este tipo de problemas nos hacen ver todos los puntos de contacto que tienen nuestros objetos con los demás.

Naive Duplication

Muy interesante esta sección en la que veremos las diferencias entre duplicidad de código y duplicidad de lógica de negocio.

Vamos a observar las condiciones para que una célula viva en la siguiente generación:

class Cell
    # ...
    def alive_in_next_generation?
        if alive
            number_of_neighbors == 2 ||
            number_of_neighbors == 3
        else
            number_of_neighbors == 3
        end
    end
end

Podríamos refactorizar este código:

// An optimization of is_alive condition
class Cell
    # ...
    def alive_in_next_generation?
        (alive && number_of_neighbors == 2) ||
            number_of_neighbors == 3
    end
end

Con este refactor de código recordamos una de las cuatro reglas: “El conocimiento se debe representar una y solamente una vez”.

Every piece of knowledge has one and only one representation.

Mirando otra vez al código original podemos ver que esos 3s no significan lo mismo.

Recomienda que una buena técnica para no caer en este error, sería nombrar de forma explícita los conceptos antes de refactorizar.

class Cell
    # ...
    def alive_in_next_generation?
        if alive
            stable_neighborhood?
        else
            genetically_fertile_neighborhood?
        end
    end
end

Así se ve mucho mejor y en caso de cambiar las condiciones de supervivencia, accedemos a reglas de negocio directamente.

En mi código no hice refactor porque me di cuenta que no era el mismo conocimiento, pero no extraje a un método cada comportamiento, interesante apunte para la próxima.

Procedural Polymorphism

El if en el código del apartado anterior diferencia los casos comprobando el valor del estado:

if state == ALIVE
...

En esta sección destaca que el uso de variables de estado es un indicio de que no se ha entendido el negocio. Interesante.

¿Cómo resolvemos esto? Nos presenta el Polimorfismo, como una técnica que nos da la posibilidad de llamar a un único método y tener más de un posible comportamiento. Si usamos ifs para hacer estas diferencias le llama Procedural Polymorphism.

Cuando vi esto me vino a la cabeza que una buena razón para no tener cuerpos ifs muy grandes o complejos es que se podría romper el Principio Open/Close. Deberían ser super-sencillos.

Avanzando con el polimorfismo, la OO nos da su método preferido, el Polimorfismo basado en tipos.

Así en nuestro ejemplo podemos coger el estado y trasladarlo a un par de tipos:

class LivingCell
    def alive_in_next_generation?
        # neighbor_count == 2 || neighbor_count == 3
        stable_neighborhood?
    end
end

class DeadCell
    def alive_in_next_generation?
        # neighbor_count == 3
        genetically_fertile_neighborhood?
    end
end

¡Polimorfismo! ¡Me encanta! Me parece muy mágico y elegante.

Pero Haines no lo deja ahí, no nos deja tranquilos en nuestra satisfacción. A continuación rompe el polimorfismo de este ejemplo cambiando de nombre a los métodos. ¿Por qué?

La explicación que da, es que el polimorfismo hace abstracciones muy atractivas que podrían ocultar detalles del comportamiento real de cada subtipo, siendo incorrecto ese genérico que queremos atribuirle.

Para darnos un ejemplo, se plantea la propia existencia de la clase DeadCell, pues no tendría mucho sentido si el tamaño del Grid fuera infinito.

Es muy fácil, sobre todo al principio, sacar abstracciones rápidamente y hacer una jerarquía de tipos. Pero si nos damos cuenta que es incorrecta deshacerla suele ser complicado.

Making Assumptions About Usage

La idea fundamental bajo la pregunta: “¿Necesitamos esta abstracción?” es: “El uso influencia la estructura”. Propone que hay que construir nuestra lógica de negocio y las abstracciones que usemos motivadas por el uso que hagamos.

Unwrapping an Object

Partiendo de este trozo de código que muestra una solución para contar los vecinos de una célula:

class Location
    attr_reader :x, :y
end

location1 = Location.new(1, 1)
location2 = Location.new(1, 2)

if location1.equals?(location2)
    # Do something interesting
end

Para hacer ese “algo interesante” tenemos que saber si las dos posiciones son iguales. Y generalmente haríamos algo como esto:

class Location
    attr_reader :x, :y
    def equals?(other_location)
        self.x == other_location.x &&
        self.y == other_location.y
    end
end

location1.equals?(location2)

¿Qué sucedería si aplicamos en la kata la restricción (muy potente) de “Nuestras funciones no pueden retornar valores”?

Tendríamos que transformar este código para que cumpla el ‘Tell, don’t ask’ y confiar en los objetos para que hagan un trabajo que generalmente haríamos nosotros.

Para ello propone una solución muy interesante, el uso de lambdas: le decimos al .equals? lo que queremos que ejecute si se cumple la condición.

count_of_locations = 0
location1.equals?(location2, -> { count_of_locations++ })

class Location
    attr_reader :x, :y
    def equals?(other_location, if_equal)
        other_location.equals_coordinate?(self.x, self.y, if_equal)
        nil
    end

    def equals_coordinate?(other_x, other_y, if_equal)
        if self.x == other_x && self.y == other_y
            if_equal.()
        end
            nil
    end
end

Es de destacar que como no podemos retornar nada, hay que invocar a other_location con la lambda, para que lo ejecute.

Me ha encantado encontrarme el uso de funciones anónimas en este ejemplo; creo que combinándolo con el apartado anterior de “Romper el nivel de abstracción” puede quedar un código con menos efectos laterales.

Inverted Composition as a Replacement for Inheritance

Volvemos al ejemplo anterior del polimorfismo:

// Let's create mother class
class Cell
    attr_reader :location
end

class LivingCell < Cell
end

class DeadCell < Cell
end

Esta extracción al crear el padre no introduce un nuevo concepto de dominio. La herencia es a menudo utilizada como una forma de “reusar” más que para eliminar duplicidades.

Es un error común crear clases ‘base’ de este estilo, que pueden llegar a ser un contenedor de comportamientos muy poco relacionados.

Si la herencia no es un solución, ¿qué otras opciones tenemos?

En el ejemplo usa módulos de Ruby, y en otros lenguajes tendríamos Traits (Groovy) y en otros algo como los decoradores.

class LivingCell
    include HasLocation
end

class DeadCell
    include HasLocation
end

Llegados a este punto, con la duplicidad medio resuelta, vemos que tenemos dos clases apuntando al mismo tipo, (Living|Dead)Cell a Location.

Una técnica útil es Invertir la dependencia, que la localización apunte a las células.

class Location
    attr_reader :x, :y
    attr_reader :cell
end 

class LivingCell
    def stays_alive?(number_of_neighbors)
        number_of_neighbors == 2 ||
        number_of_neighbors == 3
    end 
end 

class DeadCell
    def comes_to_life?(number_of_neighbors)
        number_of_neighbors == 3
    end
end

De esta manera, las clases que representan células están únicamente centradas en la información que les atañe, como las reglas sobre cómo evolucionan.

También hemos extraído la topología de las reglas del juego, viendo que el tipo Location tiene un rol de estructura, que une la malla con la célula.

Comparando con mi código, la composición invertida es muy similar a la solución que había propuesto yo inicialmente en la kata: Grid -> Position -> Info.

Como ‘Rule of Thumb’ la dependencia de clases debe ir desde la que más cambia a la que menos cambia, desde la menos estable a la más estable, es decir, la dependencia la tiene que tener aquella que tiene más posibilidades de cambiar sus atributos.

Conclusión

Programar el Juego de la Vida de dos maneras diferentes y luego leerme este libro ha resultado ser un ejercicio muy intenso y productivo. ¡Y escribir este post, claro!

Me llevo un buen montón de herramientas.

A continuación voy a leerme el libro “Practical Object-Oriented Design in Ruby”, de Sandi Metz. Os iré contando!

Kata: object literal to query string

2016-09-07T20:29:20+00:00

No long ago, we had to write a function that takes an object and returns a string to be sent as part of the query string in the request. This was because the communication mechanism was JSONP that works via the GET method. The server was already expecting the specific format shown below and we didn't have access to the server in order to change it and accept just an URL-encoded JSON. The fun started when we realised that an object may be a tree structure with nested objects. We test-drove the solution and found it interesting as a code kata. This is the expected behavior of the function:

This is our implementation:

Note that the object can't contain arrays neither functions.

Play with the code in the Babel Repl.

Antonio de la Torre se une a Codesai

2016-08-23T10:17:27+00:00

Miguel, Antonio, Carlos, Jose - Tenerife, Julio 2016

Estamos de celebración, super Antonio de la Torre forma parte del equipo Codesai desde esta misma semana. Antonio ya había decidido que se volvía a su tierra (Oviedo) con la familia cuando nos encontramos en JSDayEs 2016 y estuvimos charlando. Me contó sus planes y ví que nos podía encajar muy bien en Codesai, donde necesitabamos crecer en vista de la alianza con Kairós. La actitud de Antonio nos gustó a todo el equipo, su madurez, su empatía y como no, su experiencia con métodos ágiles. Cualquiera que haya hablado un rato con Antonio sabe que tiene una mente abierta y predisposición para ayudar a los demás. Desde entonces nos pusimos a trabajar para alinearnos en el plano más técnico. Hicimos una kata de programación en remoto, Antonio se leyó algunos libros que le recomendamos, y encima nos fuimos juntos al evento Software Craftsmanship de Pamplona (donde fuimos compañeros de habitación) y al AOS de Galicia. Tras los eventos, Antonio vino al curso de TDD que impartió Luis en Madrid y a la semana siguiente vino al que impartí yo en Tenerife. Así hicimos entrevista técnica y training, todo en uno, en un proceso que ha durado varios meses. Durante todos estos encuentros, absolutamente todos los miembros del equipo han podido conocer en persona a Antonio, pese a que estamos distribuidos en diferentes provincias. Estamos realmente contentos y nos sentimos afortunados de contar con Antonio en el equipo. Es una nueva etapa que nos hará crecer a todos.

El equipo Codesai ha crecido relativamente rápido pero sin buscarlo. Ahora el reto es mantenerlo y hacer más piña cada día. Hacer del equipo un instrumento que ayude a mejorar la industria del desarrollo de software y por qué no, tambien aportar nuestro granito de arena a la sociedad.

Claves primarias: inmutabilidad y generación

2016-08-01T08:26:10+00:00

Hace unos días Pablo Iglesias tuiteó una pregunta de Stack Exchange en la que hablaban sobre la inmutabilidad de las claves primarias. Se generó un debate bastante interesante en Twitter que se extendió más allá de la cuestión de la inmutabilidad. Este es un intento de recopilar y explicar algunos de los conceptos que se mencionaron durante ese debate.

Claves primarias mutables o inmutables

Para el que ande un poco perdido con el concepto, básicamente se trata de determinar si la clave primaria de una entidad debería poder cambiar o no una vez establecida. Por ejemplo: si me registro en un servicio online y utilizan mi email como PK, si el servicio me da la opción de cambiar mi cuenta de correo, la PK es mutable. Esto significa que en todos los sitios en los que el servicio se esté persistiendo mi email como PK va a tener que actualizar el dato para constatar el cambio. Independientemente de que usemos o no foreign keys, esto es un foco de dolor, especialmente si utilizamos distintos mecanismos de persistencia de datos. Si además nuestro software cuenta con funcionalidades como con auditar los cambios o cualquier tipo de integración con sistemas externos como herramientas de CRM y similar, tener PKs mutables se puede convertir en algo imposible.

Parece que hubo un consenso generalizado respecto a que las PK deberían ser inmutables, así que no me voy a extender más en este punto.

Claves subrogadas o naturales

Cuando usamos una clave natural, el valor de la clave está relacionado con los datos que identifica. Por ejemplo, si estamos identificando libros, el ISBN podría ser un candidato a PK. El número de bastidor para un coche, número de serie de un ordenador, la MAC de una tarjeta de red, el número de una factura, etc. En resumen, utilizamos un dato del negocio para identificar nuestras entidades al persistirlas.

Si, por otro lado, elegimos usar una clave subrogada, lo que estamos haciendo es generar un identificador único que no tiene nada que ver con los datos que identifica, pero se garantiza a nivel infraestructura que el dato es único.

Aunque siempre pongo un gran "depende" y no soy muy amigo de las afirmaciones absolutas, la realidad es que llevo años utilizando claves subrogadas porque la experiencia me ha demostrado que suele ser una mala idea utilizar datos del negocio. La razón es muy sencilla: el negocio cambia.

Ejemplos hay miles. Por tomar uno, Sergio León mencionaba los ISBN de los libros. Desarrollando un software para gestionar liberías podríamos pensar que el ISBN debería valernos, pero los libros muy viejos no tienen ISBN. Así que si de repente al librero le diese por dedicarse a vender libros antiguos de colección, tendríamos un problema importante. Ese tipo de situaciones se dan con mucha frecuencia y siempre cuando el desarrollo ya está bastante avanzado, que es cuando más daño hacen.

Como el ejemplo del ISBN hay muchos y debemos tener en cuenta el coste del cambio. Hay quién podría utilizar el argumento de que es un error pensar en el futuro y que usar una clave subrogada es una decisión prematura basada en anticiparse a un posible cambio de negocio que no sabemos si alguna vez va a suceder. En esas circunstancias suele ser un buen ejercicio pensar en cuál sería el coste del cambio en el futuro frente al coste de usar una clave subrogada en el presente. Si lo pensamos en términos económicos, utilizar una clave natural podría implicar estar firmando una hipoteca muy cara.

Además, como indicaba Pedro J. Molina, "Si vas por clave natural acaba uno fácilmente con claves compuestas. Las de 4 campos ya no hacen gracia". Pero es que encima eso termina tocando mucho las narices cuando llega el momento de "enchufarte" a otras cosas. Es típico que el servicio que te permite asociar comentarios, likes, etc. te pida que le des un identificador único de tu entidad y nos podríamos volver locos buscando ejemplos que nos llevan a desear trabajar siempre con una clave subrogada.

Generación de las claves subrogadas

Venga, vamos a suponer que a estas alturas ya estamos convencidos de que vamos a identificar a nuestras entidades con claves inmutables y subrogadas al menos algunas veces. ¿Cómo las generamos? Este punto también generó debate y en este caso no había unanimidad ni de lejos.

Para generar una clave subrogada podemos optar por dejar que la base de datos la genere por nosotros automáticamente cuando insertamos el registro o podemos ser nosotros desde el código los que proporcionemos la clave a la base de datos.

La opción clásica es que la base de datos genere el identificador por ti y listo. Podemos usar un identity, secuencia o lo que nos proporcione la base de datos que utilicemos y no nos complicamos mucho la vida. Pero hay escenarios en los que nos podría interesar recurrir a otro tipo de mecanismos.

Mecanismos para la generación de claves subrogadas

Aunque podríamos ponernos muy creativos de cara a la generación de nuestras claves, hay ciertos mecanismos predominantes. No voy a posicionarme respecto a ninguno porque creo que su utilización depende mucho de los requisitos del negocio y de la infraestructura de la aplicación.

Guids

Generar Guids es algo sencillo, se puede hacer desde cualquier sitio y las posibilidades de colisión son absolutamente despreciables. En principio es un mecanismo interesante ya que nos permite tener el control desde el negocio y no depender de la base de datos para su generación. Además, entre sus virtudes podemos considerar que al usar un Guid estamos utilizando un identificador no sólo a la tabla, también entre todas las tablas e incluso entre varias bases de datos. Esto habilita con mucha más facilidad escenarios de "merge" en los que queremos juntar datos que provienen de varias fuentes.

Por supuesto, también tiene sus contras, entre ellos que un Guid ocupa muchísimo más que una clave numérica y además afecta negativamente al rendimiento de los índices clustered.

Hay mucha literatura sobre este tema en internet, incluyendo algunos intentos de análisis sobre la diferencia desde el punto de vista de rendimiento. Además debemos tener en cuenta que la implementación de base de datos que utilicemos influye muchísimo. Como ejemplo, no es lo mismo usar MySQL que SQL Server.

Numérico autoincrementado

Este mecanismo es uno de los más frecuentes y creo que no necesita mucha explicación. El standard SQL:2003 define los tipos IDENTITY y SEQUENCE pero dependemos de la base de datos que estemos utilizando. Por ejemplo, en MySQL está el AUTO_INCREMENT y en PostgreSQL también está el SERIAL (creo que es "azucar sintáctico" para definir un SEQUENCE).

HiLo

A grandes rasos, con HiLo la aplicación reserva con antelación en la base de datos un rango de identificadores que serán utilizados necesite insertar nuevos registros en la base de datos. Cuando la aplicación ha usado todos los identificadores, va a la base de datos y reserva más. NHibernate usa esta técnica y también es posible usarla en Entity Framework. Entre sus ventajas está que nos permite utilizar identificadores de tipo numérico (para los que demandan rendimiento) y entre las desventajas que genera "lagunas" entre los identificadores generados. Si una aplicación reserva los identificadores del 1 al 10 y luego usa únicamente 5, los identificadores de 6 al 10 quedarán sin usar.

Dependiendo de un tercero

Consiste en delegar en un tercero la estrategia de generación de nuestra clave. Desde nuestra aplicación, cuando queramos identificar una entidad, llamaremos a este servicio externo y nos proporcionará una identidad que será la que luego persistiremos.

Cuando estamos haciendo HiLo, en parte estamos utilizando este mecanismo. Aunque sea nuestra base de datos la que genera los identificadores, en realidad es un tercero (la clase que gestiona el algoritmo) el que nos los está proporcionando.

Un ejemplo (raro pero real) es utilizarlo cuando la persistencia se realiza sobre mecanismos que no tienen soporte de autonuméricos, delegando la generación del autonumérico sobre un tercero para luego persistir el dato. Otro escenario de uso sería si necesitamos asegurarnos de que nuestros identificadores son únicos entre varios sistemas y además queremos aplicar reglas especiales para su generación.

Siendo realistas, es un mecanismo que añade complejidad y no es necesario la mayoría de las veces, pero no deja de ser interesante mencionarlo.

¿Cuál uso?

Según las respuestas a la conversación que originó el debate, una gran mayoría respondería "secuencias numéricas autoincrementadas y no me complico". No les falta razón, pero hay veces que complicarnos es la opción menos complicada. Complicado, eh?

Existen muchas razones que podrían llevarnos a querer complicarnos la vida y no pretendo hacer un estudio detallado, pero al menos quiero poner algunos ejempos comunes.

CQS

Si queremos usar CQS (Command-Query Separation) partimos del principio de que nuestros comandos no devuelven nada. Si tenemos un comando que inserta una entidad, deberíamos saber el id de la entidad que estamos insertando antes de llamar al propio comando, ya que el comando no va a devolvernos nada.

Podríamos pensar que tampoco pasa nada porque un comando de inserción devuelva un valor y ya está. No voy a entrar a valorar esto, pero en cuanto queramos que el modelo de ejecución de nuestros comandos sea asíncrono (a través de una cola o similar), volvemos al problema inicial.

Modo offline

Si nuestra aplicación tiene como requisito de negocio proporcionar la posibilidad trabajar offline, recurrir al servidor de base de datos para obtener el id de una entidad no es una opción.

Imaginemos una aplicación como Evernote. Cuando creemos una nueva nota y no tengamos conexión, ¿qué identificador tendrá esa nota entonces? Si generamos ese identificador desde el código (mediante, por ejemplo, un Guid) podremos realizar la sincronización fácilmente una vez tengamos conexión.

Aunque en el caso de CQS, HiLo podría ser una opción perfectamente válida, en este caso sería la opción menos recomendada ya que tendríamos la necesidad de conectarnos al servidor de base de datos si creamos tantas entidades que agotamos nuestro "cupo" de identificadores.

Si no usamos SQL

Este caso es ignorado por muchos desarrolladores cuyo contexto profesional se limita a bases de datos SQL para persistir información. Cuando salimos del mundo SQL, muchísimos mecanismos de persistencia piden que seamos nosotros desde el código los que proporcionemos nuestros identificadores. Como ejemplo "primitivo" a la par que útil, si persistimos en disco tendremos que proporcionar nosotros el identificador de nuestra entidad (nombre del archivo).

Conclusiones

Tenemos multitud de mecanismos para identificar nuestras entidades. Debemos conocerlos bien y hacer un uso inteligente de ellos en función de nuestros requisitos de negocio, pero nunca complicarnos la vida innecesariamente.Y muy importante, que el rendimiento únicamente sea un argumento cuando tenemos requisitos no funcionales que nos hablan de rendimiento. Hablar de rendimiento cuando no tienes requisitos relacionados con el rendimiento suele ser foco de optimizaciones prematuras.

Y con esto creo que termino el "resumen" de las cosas que se comentaron en el hilo de Twitter y algunas de las que pasaron por mi cabeza. Seguro que me dejo en el tintero muchas observaciones y muchos matices, me conformo si a alguien le vale para entender que hay vida más allá de los identificadores mutables naturales.

Este post es un cross-posting de mi blog.

Estuvimos en AOS2k16

2016-07-08T17:04:15+00:00

Los días 1 y 2 de Julio de 2016, la mitad del equipo Codesai estuvimos en el Open Space de la comunidad Agile Spain, el AOS. Un evento brillantemente organizado por el capítulo gallego de la comunidad y celebrado en Santiago de Compostela. Enhorabuena a todos los organizadores por una organización perfecta. Muchísimas gracias por hacernos pasar dos días inolvidables. El lugar del evento era espectacular, en plena naturaleza. Las salas de conferencias eran acojonantes, una de ellas era una cueva, ¡literalmente... y chulísima! Hizo un tiempo buenísimo con mucho sol, cosa rara según los lugareños. Tuvimos suerte que todas las sesiones que propusimos fueron votadas y además nos lo pasamos muy bien facilitándolas.

Primero me tocó a mí con una sesión sobre Principios y técnicas de diseño de software. Puse en la pizarra muchos de los que yo conozco y fuimos complentando con más que los participantes fueron añadiendo. La participación y el buen ambiente hizo que el rato se pasara volando.

Gracias a Jon. E. Eguiluz que ha escrito sobre la sesión en su blog, tenemos enlaces a muchos de los temas tratados. Gracias a Manuel Castro por la foto.

Muy relacionada con mi sesión, Fran y Alfredo habían preparado otra sobre Connascence.

Fran, al igual que yo, tenía frío dentro de la cueva y necesitaba el jersey :-). Esta charla seguramente será presentada en más eventos futuros.

Gracias a Raul Herranz por la foto. Al final del día Ronny facilitó una sesión sobre las dificultades a la hora de aprender TDD y sus propios errores durante el proceso de aprendizaje. La sala estaba repleta. En esa sesión estábamos los cuatro y sin haberlo preparado pudimos puntualizar detalles que nos parecían relevantes a unos y otros de forma muy amena al menos para mí.

Antes de la sesión de Ronny, el bueno de David Fernández, compañero de Kairós DS tuvo la iniciativa de invitarme a co-facilitar una sesión sobre experiencias en la adopción de XP en equipos. Pese a ser la hora de la siesta, la participación fue alta. David propuso un modelo "lean coffee" y lo facilitó muy bien. ¡Gracias por la invitación David!

A veces en eventos de la comunidad ágil existe la crítica de que hay pocas sesiones técnicas, tanto en AOS como en CAS. Creo que a veces es cierto pero tambien creo que es cuestión de que los que somos más técnicos tengamos la iniciativa de cambiarlo. En un Open Space uno tiene que buscar la manera de sacarle partido mediante la participación. No vale querer un evento más técnico sin proponerlo ni participar activamente en ello. Es un evento que se hace entre todos. Creo que nuestra responsabilidad como developers es ayudar a reducir esa barrera entre tecnología y negocio. Era la idea original de los métodos ágiles, limar esa diferencia y ser todos un equipo. A los técnicos nos toca comprender a los no-técnicos, siendo conscientes de nuestra ignorancia en otras áreas. Sin infravalorar su labor en ningún caso. Y también de ayudarles a que ellos sean conscientes de su ignorancia y puedan empatizar más con nosotros explicando las cosas en un lenguaje que les pueda llegar. Nuestras sesiones en AOS eran todas técnicas y sin embargo pude ver a gerentes, facilitadores, agentes del cambio... Tenían interes por llevarse algo de esas sesiones, por aprender. Desde luego que no infravaloraban lo que se estaba contando sino al contrario, le veían mucho valor. En la hora de la comida incluso me dijeron que daba "envidia sana" oirnos hablar con tanta pasión. Creo que tiene que ver con explicarse desde un punto que busca el sentido común. Cuando el objetivo es la mejora contínua y no un rollo friki, todo el mundo pone la oreja.

Una de los grandes despertares de este AOS para mí ha sido darme cuenta lo importante que es participar e AOS. Llevaba desde 2013 sin hacerlo y antes de eso tambíen creo que desde 2009. Personalmente con todo lo que viajo por trabajo, cualquier evento que requiera desplazarse supone un gran esfuerzo. Tengo que justificarme a mi mismo que puedo aumentar la cuenta de días fuera de casa, dejar que la bandeja de entrada se pete, que mis clientes no puedan contar conmigo, el efecto medioambiental de los viajes...

Hay muchísimos eventos y muy buenos. Creo que por el hecho de conocer a mucha gente de la comunidad, fuí olvidando lo importante que es tener esas conversaciones con los amigos que ya conoces, con los habituales del AOS. Tenía sensación de que era más ocio que aprendizaje. Durante un tiempo prioricé salir a otros eventos a conocer a otras personas, incluso en otros países. Ver si de esa forma aumentaba el retorno de la inversión. Estuvo bien porque he conocido a mucha gente, pero eso no es mejor que lo otro, es diferente. Volver a conversar con tantos sabios, habituales del AOS, cenando y de copas por Santiago, me aportó muchísimo valor. Me hizo darme cuenta que participar en AOS me garantiza el retorno de inversión.

Debo agradecer especialmente a los amigos gallegos de la organización que me animasen a asistir a "su AOS" porque eso fué lo que me enganchó para comprar el billete. Reconectar con la comunidad ha sido magnifico. Desde el minuto 1 hasta la vuelta a Madrid con Yeray y Jero en coche. La gente es muy grande, muy buena gente y grandes profesionales.

Nos asociamos con Kairós DS

2016-06-22T07:53:11+00:00

Notición! Nos asociamos con Kairós!

Estamos de enhorabuena, el equipazo de Kairós DS se convierte en partner de Codesai adquiriendo una parte de la empresa.

En los últimos meses nos habíamos cruzado por múltiples caminos. A nosotros nos hablaban muy bien de Kairós y teníamos buenos amigos allí como Helder de Oliveira que de paso nos daba a conocer en Kairós. Aprovechamos la ocasión para agradecerle a Helder su confianza y su apoyo, tanto a Codesai como a toda la comunidad Software Craftsmanship. Sin quererlo incluso acabamos llegando al mismo cliente desde diferentes perspectivas.

Esta unión es una alianza estratégica: Codesai aporta su experiencia en desarrollo con XP, en testing, en el cuidado de la calidad y la mantenibilidad del software. La experiencia con formación técnica y mentoring.

Kairós aporta su experiencia en transformación digital en grandes organizaciones, su gran equipo de Agile Coaching, el know-how en grandes proyectos para banca y la capacidad de llegar a clientes de un tamaño que hasta ahora era inaccesible para Codesai. Es un win-win evidente.

Compartimos la oficina en Madrid en la calle Claudio Coello, 78.

Esta alianza no cambia nuestros valores ni principios, ni la forma en que trabajamos. Lo que nos permite es crecer a un tamaño suficiente para que cualquier tipo de empresa pueda contar con nosotros. Nuestro catalogo de servicios crece, ampliamos la oferta para nuestros clientes manteniendo el nivel de calidad.

Los vamos a celebrar con varios eventos en la oficina: un curso técnico en abierto a finales de Julio, un evento de comunidad y otro de networking con nuestros clientes y amigos.

Ya sabes, ahora Codesai y Kairós, son buenos amigos :-)

Estuvimos en Pamplona Software Craftsmanship 2016

2016-06-21T14:15:01+00:00

Gorka, Pablo e Iker en la apertura

El pasado fin de semana, 17 y 18 de Junio, buena parte del equipo Codesai estuvo en Pamplona Software Craftsmanship 2016. Eventazo de categoría. Este evento fue organizado por Iker, Gorka y Pablo, los artesanos de 540deg. Ellos se inspiraron en Socrates Canaries 2016, evento que tuvo lugar en Las Palmas en Marzo. Vinieron al evento y en las conversaciones de pasillo y bar se animaron a montar un evento similar en su tierra. Poco después nos llegó invitación para ser ponentes en el evento. Y lógicamente con lo majos que son no pudimos negarnos. Y menos mal porque ha sido un evento muy bueno. A diferencia de Socrates que es 100% open space, el de Pamplona sí tenía algunos speakers invitados además de haber lugar para open space. Con la agenda de eventos tan apretada que tenemos, invitarnos directamente fue una buena forma de asegurarse nuestra participación por lo que estamos doblemente agradecidos. El hashtag fue #scpna, a través del cual pueden encontrarse fotos y comentarios realizados en vivo.

En el tren coincidimos unos cuantos amigos en la cafetería y pudimos comprobar que los de Renfe no están bien preparados para la ocasión porque se les acabó la cerveza antes de llegar a Pamplona :-D

Muy buen ambiente desde el viaje, aprovechando además para conocer a los demás ponentes y participantes. Al llegar nos encontramos con un montón de amigos para cenar y nos dieron las tantas.

Tanto Alfredo como Modesto como yo, contamos con una hora entera como ponentes. En mi caso quise convertir la sesión en un coloquio donde la gente pudiera dar feedback y el nivel de participación fue muy bueno. El tiempo se me hizo cortísimo. La mitad de las cosas que quería contar se quedaron fuera y es que nunca antes había contado todas estas cosas y no había tenido oportunidad de medir los tiempos. Mi buen amigo Antonio de la Torre me comentó que me faltó una conclusión al estilo "call to action", comentario que agradezco mucho. Cualquier otro feedback es bienvenido. La mayoría de las sesiones las grabaron entre el Planetario y Codely.tv, y estoy deseando verlas porque me perdí 4 charlas que me interesaban un montón, un poquito a sabiendas de que eran en la mejor sala para ser grabadas y confiando en que la grabación será buena. Así que estoy deseando que las publiquen.

El open space tuvo un alto nivel de participación con sesiones muy interesantes, era dificil escoger a qué sesión entrar. Fue estupendo reencontrarse con amigos que llevaba años sin ver y desvirtualizar a grandes profesionales compañeros del gremio que ya seguía por las redes. Fue estupendo conocer a más cracks de Karumi (que por cierto a la charla de Pedro Gómez sí que pude ir y me encantó) y a parte de 47deg. Algunos slots me los perdí mientras hablaba con gente por los pasillos, cosa que sucede mucho en los open space, que las conversaciones son una parte muy muy enriquecedora del evento. Lo más difícil del open space es vencer la sensación de impotencia de no poder estar en todos sitios a la vez. En el segundo día lo conseguí y me eché una siesta despues de comer que me permitió luego casi empatar la cena de cierre con mi vuelo de amanecida. Y es que la organización del evento lo hizo todo a la perfección, hasta el último momento. Son grandísimos anfitriones. Y lo más llamativo es que nunca les vi nerviosos, estan tranquilotes y disfrutando del evento. Me llamó muchísimo la atención que en la zona de encuentro, además de haber cafés, zumos y fruta, había un grifo de cerveza y tambien cervezas patrocinadas por 47deg. Cerveza disponible casi las 24 horas :-D

Retrospectiva final

Fue curioso que en la retrospectiva del primer día a penas hubieron puntos a mejorar y los pocos que salieron estaban corregidos al día siguiente. Por lo tanto en la retrospectiva de cierre no hubo ni un solo punto común de mejora a destacar. Una organización brillantísima, excepcional.

Como parte del open space tuve ocasión de facilitar un taller de refactoring de 2 horas donde practicamos Parallel Change y Narrow Change, el mismo que habíamos hecho Pawel Duda y yo en Socrates con alguna mejora. Fue muy divertido, gracias a todos por participar en el taller.

Estoy muy contento de ver que tanto Ronny como Miguel y Dani, nuestros aprendices, propusieron varias sesiones en el open space y que además salieron votadas y se desarrollaron muy bien. Da gusto ver a la gente joven progresar.

Al final del evento la gente del Planetario de Pamplona que fueron majísimos todo el evento, nos dieron un estupendo paseo por el cielo y nos proyectaron un vídeo que me transportó 20 años atrás a la demo scene del Amiga, de cuando la Euskal Party y antes incluso. Para los más jóvenes dejo aquí la famosa demo de Space Balls que es del 91 o 92. La mayoría de esta gente programaba en ensamblador con máquinas de medio mega de ram y secuenciadores de 4 pistas para la música. Gran cierre.

¡Muchas gracias a todos por hacer el evento posible!

Estuvimos en Fon

2016-05-31T22:57:41+00:00

Hace unos meses tuvimos la suerte de ser contratados por Fon para impartir un curso de TDD a uno de sus equipos de desarrollo en Madrid. Una oficina chulísima y un equipo entregado que prestó atención máxima desdel el minuto 1.

Fon es una empresa de la que he oído hablar practicamente desde sus orígenes porque sonaba mucho en el mundillo geek desde siempre. Tenían fama de hacer las cosas bien. Así que tenía ganas de visitarles y ver qué se contaban hoy en día donde el Wifi ya no parece tan importante. Sin embargo me contaron que lo están petando con el roaming wifi en varios países.

Lo único que me faltó para que hubiese salido todo del 10 es conocer a Daniel Brandi que justamente esa semana estaba en un evento en Londres y no nos pudimos ver. Me sorprendió gratamente que muchos de los participantes en el curso ya me conocían y se habían preparado preguntas para sacarle el máximo partido a esos dos intensos días de formación.

Agradezco especialmente a Joan Fisbein la atención, el apoyo prestado y las agradables conversaciones durante la comida.

Parece que el curso cambió la forma en que el equipo ve los tests, tanto en calidad como en cantidad. La gente se dió cuenta que la cobertura no es un objetivo en sí mismo sino que lo importante es crear unos tests mantenibles que mantengan un buen compromiso entre seguridad y mantenibilidad.

Las conversaciones fueron muy interesantes y la gente muy maja.

Además, en este curso; pudo venir conmigo nuestro aprendiz Miguel A. Viera y facilitar alguno de los ejercicios en el segundo día. Miguel se quedó alucinado con la oficina.

Ahora mismo Fon está buscando desarrolladores Java senior. Es un buen momento para enviarles un CV si estás buscando nuevos retos.

The Ohce kata, a short and simple exercise to practice outside-in TDD using test doubles

2016-05-25T07:00:00+00:00

I created this short and simple kata to practice outside-in TDD using test doubles for a mentoring Álvaro and I are doing in Magento Barcelona:

ohce is a console application that echoes the reverse of what you input through the console.

Even though it seems a silly application, ohce knows a thing or two.

When you start oche, it greets you differently depending on the current time, but only in Spanish:
- Between 20 and 6 hours, ohce will greet you saying: ¡Buenas noches < your name >!
- Between 6 and 12 hours, ohce will greet you saying: ¡Buenos días < your name >!
- Between 12 and 20 hours, ohce will greet you saying: ¡Buenas tardes < your name >!
When you introduce a palindrome, ohce likes it and after reverse-echoing it, it adds ¡Bonita palabra!
ohce knows when to stop, you just have to write Stop! and it’ll answer Adios < your name > and end.

This is an example of using ohce during the morning:

$ ohce Pedro
> ¡Buenos días Pedro!
$ hola
> aloh
$ oto
> oto
> ¡Bonita palabra!
$ stop
> pots
$ Stop!
> Adios Pedro

I hope you enjoy doing it.

Lanzamos Codesai con mucha ilusión

2016-05-20T15:48:12+00:00

Después de dos años trabajando bajo la marca de CB&A (Carlos Blé y Asociados) ha llegado el momento de crear algo más grande, una marca que proporcione a nuestros clientes la confianza de que puede funcionar sin Carlos, cuando haga falta. Una marca donde el interés del grupo y de la comunidad está por encima de los individuos. Un grupo que hace de su trabajo su pasión. Donde trabajo y afición son la misma cosa.

Aunque sea con el mismo núcleo, queremos dar a conocer a todo el mundo que este grupo de profesionales se ha consolidado y es un equipo bien alineado, maduro y más ilusionado que nunca por ayudar a los demás. Por crear grandes productos. Por impactar en la sociedad. Queremos subir el nivel del sector de desarrollo de software en nuestro país y llegar a innovar y exportar conocimiento fuera de él.

Nuevas alianzas, de las cuales publicaremos detalles pronto, nos permiten tener una estratégica oficina en pleno centro de negocios de Madrid. Nos permiten llegar a clientes que antes eran imposibles.

La consolidación de Codesai como empresa, junto con su red de partners, van a multiplicar nuestra impacto, nuestra capacidad de cambiar el mundo en que vivimos.

Arrancamos nueva etapa, Codesai se va a hacer notar. Estad atentos que pronto habrá fiesta de inauguración!

Ya sabes que puedes contar con nosotros, no sólo en Madrid sino en cualquier lugar... sólo dinos ¿en qué podemos ayudarte?

Event bubbling in C#

2016-04-08T16:12:57+00:00

How to propagate an event from a low level class to a top level one:

Events can only be raised from within the declaring type. Unfortunately they can’t be be passed in as arguments to methods. Only += and -= operators are allowed out of the declaring type. One way to stub out the event could be through inheritance:

But declaring the event as virtual and then overriding it, is very tricky: replacing the call to RaiseEvent to DoSomething, makes the test fail! Looks like events where not designed to be overridden.

A better approach would be:

Windows apps development best practices

2016-02-24T14:39:27+00:00

I don’t really know whether they are the best practices to be honest, and certainly there is a lot for me to learn but these are principles and practices that work well for us in the development of a complex native Windows App (Windows 8.1+) using C# and the MVVM pattern.

Files in my example (namespace + classname) :

Example.Views.App.xaml.cs (Main app class)
Example.Views.Vehicle.xaml (View)
Example.Views.Vehicle.xaml.cs (View’s Codebehind)
Example.ViewModels.Vehicle.cs (View model)
Example.Domain.Vehicle.cs (Domain model)
Example.ViewModels.AppState.cs (In-memory app state)
Example.Views.NavigationService.cs (Our custom navigator)
Example.Views.NavigationParameters.cs (Bag of parameters to be sent to the target view)
Example.Domain.EventBus.cs (Our custom pub-sub implementation, a singleton)

Page navigation is performed by the framework:

The first parameter is the type of the target Page and the second is an “object” intended to send any custom parameter. Such parameter is received as an argument of OnNavigatedTo method in the target page.

The code above is used to navigate from App.xaml.cs (Main page) to Vehicle (Page).

The NavigationService is an indirection level that sends the ViewModel to the View as the context object. It’s used pretty much like Frame.Navigate:

Implementation (NavigationService.cs):

This is how the view model is received in Vehicle’s codebehind (Vehicle.xaml.cs):

Principles applied in the code snippet above:

DataContext is set in the last step of the method, not before. DataContext is set either in the codebehind or in xaml, but not in both places at the same time. If the DataContext is set in the xaml (DataContext=”SomeProperty”) and also in the codebehind, you can’t guarantee which data will be finally set, race conditions could happen.
Pages and UI controls in general must not contain state. Avoid any field in the codebehind holding a reference to the view model. This is to prevent race conditions. We rather create a getter instead:
Avoid subscribing the codebehind to the EventBus, use the view model as the listener. Life cycle of the pages is controlled by the framework - this is specially important when caching pages via NavigationCacheMode=”Required”. Sending a reference to the EventBus will prevent the garbage collector from cleaning up the Page instance.

Avoid global statics: Although there is a single instance of AppState class - is a global singleton, we inject it into every view model that requires read or write access rather than having direct static references. The Factory knows the AppState singleton and injects it to the viewmodels. Although two different views may require the same data, we try not to store everything in the AppState but rather cache the service methods retrieving the required data and then injecting the same instance service to both viewmodels. The amount of data kept in the AppState should be minimal, basically it should contain identifiers that view models understand in order to pull data from the services. Sometimes it contains more data to avoid time consuming transformations or calculations, that’s fine, it’s a trade off.

Custom controls: We ended up having our own custom pages, inheriting the Page control to remove duplication from initialization process. One of such inheritors is generic: _CachedPage_, where T is the type of ViewModel. However in xaml you can't define a page inheriting from a generic class. To work around this minor issue we create an intermediate empty class:

Then in xaml we can set the type of our page to be CachedVehiclePage.

Nested user controls: When a Page contains a user control, the DataContext of that user control is the same than the Page’s one. Neither the codebehind or the xaml of user control should overwrite the DataContext. The DataContext should not be set programmatically it’s just inherited from the parent container. Otherwise there could be race conditions and memory leaks.

Data binding: We don’t bind domain models directly to the GUI. The main reason is that double way binding requires public setters. Sometimes we create a bindable object that wraps the domain model exposing only ome properties. But we often create custom bindable objects from the domain model for the specific purposes of the view.

I’ll update this post with more stuff that is working well for us.

A code review is not like watching a football match

2016-02-24T10:52:29+00:00

In my experience a code review must have a goal. Some common goals are:

Telling others how you solved a common problem.
Warning others about certain perils (i.e race conditions, coupling…)
Asking concrete questions. Implementation or design questions.

When you expose some code to your colleagues in a meeting room, you should know exactly what you want to get from that activity. You want to learn, to tech or to warn others basically. Otherwise, if you just open up some code and ask your colleagues what’s their opinion about the code, then everyone will say something. Exactly like watching a football match with friends, everyone has his/her opinion on how the coach should manage the team, how players should play… no matter how good the team play, there will be always someone opinionated bullshit. The code review will be frustrating and not very productive.

Remember to prepare a list of questions or tips to tell others, together with the code you want to share, before going to the code review.

We visited Scytl

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

In October 2015, just two months before the Spanish elections I was lucky to visit Scytl and work there as a consultant for a week. Thanks to my good friends Manu Martin and Alvaro Garcia who are currently working in there as agile coach and developer respectively. I met a different team each day of the week, it was quite challenging and interesting.

More often than not, when I visit companies, I get to see a significant amount of coding horrors and technical debt. So I was curious about Scytl because I knew they were going to collect and count my vote together with other 30 million more two months later. They were the IT company designated to collect and count the votes in the Spanish elections - among many other things like the website with the reports…

I must say that I really liked what I saw, they are brilliant security experts, very professional. Citizens’ vote was absolutely private and secure. I was confident that my decision as voter was secure, that I could trust their software. It’s a very good feeling… software one can trust finally!

And yes, two months later they did a fantastic job, and they even broke the voting count speed record. Congratulations!

One of the teams I worked with was exactly the one in charge of collecting the votes. They had really good architecture and design questions for me. It was a challenge. Their chosen solution was very smart, I liked its simplicity. There was a lot of pressure on this team and I explained how important it is to have some slack time in order to step back for a little while and rethink decisions. Too much pressure is harmful in my experience, the best ideas come up when the brain is relaxed.

I also worked with the team in charge of counting votes and I got to see the D’hondt algorithm, something totally new for a democracy illiterate like me. We had a very nice mob programming session with the whole team in the meeting room. People were skeptical about mob programming at first but they quickly grasped its benefits, it was a way to find out team conventions for example.

On the third or forth day I also spent the day with the mob, this time with another team. The focus was on refactoring and unit testing strategies apart from a code review. We had the chance to explore together some of the new features of Java 8 too. I emphasized the importance of learning the IDE’s shortcuts and the automatic refactorings it provides - it was IntelliJ in this case. Nice to code with young people willing to learn and improve.

I emphasized the fact that communication among co-located teams is more effective face to face. Pairing for a while to integrate a new feature from the other team or some API change, feels nicer than sending emails back and forth. Dog fooding among teams could help improve collaboration given that some teams act as a kind of “customer” to others.

There was also a session with a group to discuss about values, principles, professionalism and motivation. An exchange of opinions and points of view. Unexpected and very enriching.

I didn’t know that teams are multicultural with people from distinct nationalities. English is the official spoken language. Although my English is not too bad for a quick chat, I had some trouble understanding and communicating with some people from other cultures. It reminded me of how tough it could be to work with people from other cultures, specially when English is not the native spoken language of none of us.

Scytl’s people were excellent hosts, very welcoming and friendly. Thank you for a remarkable week!

Polymorphic test setup with template method

2015-12-21T16:30:19+00:00

We had a kind of duplication in our tests that we didn’t know how to deal with. The refactoring Introduce Polymorphic Creation with Factory Method explained by Joshua Kerievsky in his brilliant book “Refactoring to Patterns” gave us the solution to avoid duplicated tests.

These tests are very similar, the differences are in lines 8 and 25, and also in lines 13 and 30. The first test tries to change the color of a configuration, whereas the second one tries to change the interior. Part of the handling business logic is the same. This is just one scenario but we had many others with the same expected behavior for color, interior, equipment, and more. Eventually there would be a lot of duplication.

After refactoring, we have a base abstract class with the tests, exposing template methods that derived classes have to implement in order to populate the catalog and also to execute the corresponding action:

The base class ConfigurationTests contains just helper methods such as ExecuteChangeColor, or ExecuteChangeInterior, but no tests at all. Otherwise tests would run twice.

Refactorizando Try - Catch usando Javaslang

2015-12-15T16:10:03+00:00

Hace unos días, empecé un proyecto personal para mejorar algunas tecnologías, como por ejemplo, conexión con bases de datos o trabajar con Spark para hacer un servicio Rest.

Empecé con una idea muy sencilla, ya que lo que quería era empezar cuanto antes y, más adelante, ir incorporando nuevas features y encontrarme con problemas como ¿por qué hice esto de esta forma y no de esta otra?, ó también, “por tomar una determinada decisión me ha surgido un problema grande a la larga”.

La idea principal, es tener una tienda online donde tendré usuarios y productos, donde los almacenaré en una base de datos y proporcionar un servicio Rest.

Primero, empecé por hacer un CRUD usando JDBC donde tengo una tabla de usuarios:

Y mi clase User:

Una vez implementado el CRUD y refactorizado el código, me encontré con que no me podía quitar los bloques de try/catch, lo cuál me frustró mucho porque me parecían bastante verbosos. Pero, por casualidad o por cosas del destino, Rubén compartió unos vídeos sobre patrones de diseño con Java 8, de los que quiero destacar la charla de Mario Fusco.

Entre otras cosas, recomendó javaslang, una biblioteca funcional que añade, pequeñas, pero importantes mejoras a Java 8. Propone un ejemplo con la clase Try<T>, dicha clase es una mónada que puede devolver dos tipos de objetos: Success (objeto que contiene el valor) o Failure (objeto que contiene la excepción). Además, se le pueden aplicar funciones como map o andThen.

Así era como se insertaba un usuario en la base de datos:

Y este es el método que establecía la conexión con la base de datos:

¡Cuántos try/catch! Vamos a refactorizar para dejar un código más limpio y legible donde cualquier persona pueda leerlo y tener una idea de cómo funciona con solo echarle un vistazo. Empecemos con el método que establecía la conexión:

Y finalmente, con el método que inserta, extrayendo más métodos para dejar el código más limpio y legible.

En caso de que querramos controlar las excepciones, basta con llamar a la función onFailure(Consumer<Throwable>). Por ejemplo:

Personalmente, me ha gustado mucho haber descubierto esta manera de hacerlo, ya que me centro más en qué quiero hacer en vez de cómo lo quiero hacer. Y además, mejora muchísimo la legibilidad del código.

Por último, me gustaría recordar que el proyecto es para aprender y cualquier feedback será muy bien recibido :D

Link proyecto: GitHub
Link: Otro ejemplo usando la clase Try

Pairing: don’t have to always agree on a plan

2015-12-02T09:25:44+00:00

So your pair is proposing a route or plan that you don’t agree on. Am talking about a refactoring, a redesign or just the way to test drive the next feature. You have told him your reasons no to agree with him and there is no way to get to an agreement. It’s perhaps frustrating because you believe his strategy will fail but he definitely wants to proceed that way. What do you do? Argue forever?

I don’t think you have to always agree on the path you are going to walk. The important thing is that both understand the plan so that driver and navigator can help each other get there. In those situations I end up saying… I believe this approach is not the best and I would try out something else - something I explained already… but anyway, I’ll help you with your idea, let’s do it.

Several times my pairs have proven that they were right and the plan was effective. Some other times it wasn’t a good idea, but we built a trustworthy relationship, a supportive one.

Object references, state and side effects

2015-10-16T09:34:38+00:00

C#, Java and other languages have the same behaviour when it comes to reference types.

The dot symbol after the variable name (instance1 or instance2) accesses the actual

object referenced by that variable. So before the dot, we have a variable referencing an object, and

after the dot we have the actual object.

Means: get reference instace1, then access the object, then access someField

Passing objects to functions has exactly the same behaviour, function parameters behave like variables assigned to the original arguments.

Instances of SomeClass are mutable because the value of someField may be changed.

This mutation may happen by mistake as a result of an uncontrolled access to the object via some copy of its reference ( a case of aliasing), causing unexpected side effects like defects and memory leaks.

While the application code can reach an object - has some reference to it - the garbage collector can’t free the memory allocated to that object.

Short version of our desktop app architecture as an example:

The life cycle of the View instance is controlled by the framework, not by us. It may create a new instance every time the view is shown on screen and destroy the instance as it disappears. However we are adding a reference to the static list of subscribers in the EventBus. Until the subscribers list is flushed, the garbage collector won’t be able to set memory free for ViewModel and View instances, even though the view may not be even being displayed. Opening that view many times will increase the memory consumption every time, i.e., causing a memory leak. In this particular case we unsubscribe the instance from the bus before hiding the view:

In the case of the bus there isn’t much we can do to avoid having two references to the same object in two different places, we have to be aware of this behavior. In C# there is the concept of Weak Reference but as far as I know we can’t use it on WinRT (tablets).

In some other cases though we may avoid side effects by:

Avoiding more than one reference per object, avoid state.
Keeping variables local, avoid instance variables (fields).
When the object is a value object, designing it to be immutable.
In the case of collections, using ReadOnlyCollection when they must keep their size.
If the object can’t be immutable by design but you need to avoid state changes at all cost, cloning the object by returning a deep copy of it.

We may be tempted to clone objects every time someone asks for a reference to them. However this may not be possible (like with the EventBus) or it may be too expensive and complex. I’d say that cloning is the last alternative and perhaps the need for it is a design smell. Who is responsible for ensuring that object references are not causing memory leaks? It boils down to the principle of Least Astonishment. We should design interfaces (methods) in such a way that it’s obvious how references and state are going to be managed. If it looks like the consumer (the one asking for the reference) will not be aware of it and the consumer will likely make undesired changes to the object, then cloning the object could be a good defensive approach. But I would rather try to think how to make the API more expressive considering context and level of abstraction. I assume that the caller understands how references work.

If you, dear reader, provide some code examples I will be able to clarify my point with code. I’ll update this post if I come up with some snippets.

Refactorizando con Streams

2015-10-08T18:50:52+00:00

Hoy traigo una serie de ejemplos de refactorización a modo de introducción a las nuevas características funcionales de Java 8. Así que, si tenías curiosidad y no te habías atrevido a experimentar con ellas, ¡te animo a que pruebes!

Empezamos definiendo una clase Person básica con un nombre y una edad:

Una vez definida nuestra clase base, vamos a hacer un ejemplo sencillo: tenemos una lista de personas y queremos tener otra lista pero sólo con las personas que sean mayores de 22 años.

Y ahora usando Java 8:

Vamos a explicarlo un poco. Primero tenemos el método stream(), propio de las colecciones, que devuelve un Stream (conjunto inmutable de elementos y una serie de funciones con las que operar sobre el mismo). Seguimos con la función filter que, como su nombre indica, filtra los elementos a partir de un predicado (función que evalúa un argumento siendo el resultado verdadero o falso). Y por último_,_ tenemos que volver a transformar el stream en una lista, por lo que llamamos a la función collect y nos ayudamos de los Collectors para ello.

Podemos extraer el predicado en una variable para tener una mejor legibilidad:

Ahora pongamos otro ejemplo. Seguimos teniendo la misma lista de personas pero ahora queremos un String que contenga los nombres de las personas que sean menores de 22 años separados por ”, “.

Java 7:

Java 8:

En este ejemplo, vemos varias cosas nuevas como la función map, que devuelve un nuevo Stream del mismo tamaño, pero con la diferencia que cada elemento es el resultado de aplicar la función pasada por parámetro sobre cada uno de ellos (en este caso, me devuelve un Stream<String>. Además, vemos como podemos sustituir nuestra función lambda por una referencia al método, es decir, hemos sustituído:

person -> person.name() por Person::name

Ya que queda más compacto y fácil de leer. Y por último, unimos todos los nombres separados por ”, “ sin tener que estar preocupándonos en si se nos añade o no una ”, “ de más.

A modo de conclusión, me gusta más ésta forma de programar declarativamente, ya que mejora mucho la legibilidad del código e incluso es más fácil de mantener. Ya vimos por ejemplo que, para reducir la lista de personas a una lista de nombres, bastó con añadir una línea llamando a la función map y listo.

XP Team Building

2015-09-24T16:15:51+00:00

Let the team walk its path

Every team walks at its own pace and I haven’t found a way to speed it up myself, I don’t think there is one regardless of whether you are an external coach or a regular member of the team. Trying to push the team will screw up the work environment, the pressure may introduce interpersonal conflicts and severe damages in the quality of the product. I mean, people will do stuff they do know it’s wrong because of the sense of emergency. On the other hand trying to pull the team away will give its members the impression that they are not trusted professionals, again causing problems among people and discouraging them from being proactive and willing to learn.

The only way we can help the team progress is to help them walk their own path, removing impediments along the way, answering questions when asked to do so.

I’ve learned that it’s not possible to develop a software product at the speed that I’d like whilst mentoring people. I have to choose either to be a trainer or to be a developer but not both things at the same time because the goals are different. When working as a trainer the goal is that people learn effectively and the best way, for us humans, to learn is by making mistakes that let us learn from ourselves. As a mentor I must combine small theoretical explanations, recommendations and practical examples with time for people to practice and to make their own decisions. They must have the chance to fail and discover. If they don’t recognize the failure my mission is to provide feedback and explain why is this or that a mistake and what are the consequences. Deep lessons are learned with pain - success is fantastic but it doesn’t teach. However this style of mentoring takes a lot of time, it’s probably the top most time consuming way. It’s a company wide commitment, an effort for everyone.

Often companies ask us to join them for a new project that must deliver value within a tight schedule and at the same time they want to build up a team of XP developers with people that have never been exposed to XP. I must say this is completely impossible in my experience. If the quality of the product needs to be excellent and deadlines are tight, the best thing the company can do is to hire a seasoned high-performing XP team whose members have been working together for years. On the other hand, if the actual goal is to build up a team, this is an investment that lasts several years. According to my experience, a group of 6 to 8 developers become an XP team after 2 years of training, guidance, reviews and practice. It requires several training courses during the various stages of the transition, practical examples, guidance and moreover it requires small failures (hopefully reversible ones). People have to have the margin to fail and learn from their mistakes. During this period some people will very likely leave the company and some new people will join.

I know the word quality is too abstract, we don’t have a definition for what quality is but I am actually talking about well-known maintenance issues. A common mistake beginners make is to write brittle and hard to maintain tests that with time impede developers changing or adding features. Those tests are eventually deleted. It’s waste unless you consider this to be another stage in the team’s learning curve.

Nobody writes perfect code anyway, every team makes mistakes so the point is not to aim for perfection. The point is to avoid or minimize the amount of things we do know are waste, basically because we have failed in the past.

Hiring seasoned external consultants means they won’t make the same mistakes they did in the past although they’ll make new mistakes. Every team is different as well as every project.

As a consultant I won’t prevent the team from making mistakes when the goal is to train them, instead I’ll try to keep the cycles small enough so that mistakes can be fixed soon and cheap. But it’s up to the team to ask for feedback and review, my job is not to control the source code - it’s to support the team!

In some situations it could be beneficial that a small group of experts write the “walking skeleton” with the first group of product features in order to define architecture, style and conventions that others can follow. It serves to explore risks and exposes an example that others can follow. There are several perils of this approach though. I’d be careful with it - sorry don’t feel like writing about these drawbacks now.

ES6 + browserify + babel + gulp + jasmine

2015-09-14T09:09:58+00:00

During Socrates Conference 2015 we decided that it’s the right time to jump in ES6 to develop a green field project that our customer is starting. Given that ES6 is already the stable and latest version of JavaScript, it does not make any sense to start a new project with ES5, an already old version of the language. With the kind of functional style that we use when coding in JavaScript, the changes are not too big anyway as we are not going to use classes anyway. But we can gain a lot of value from using block scope with let and const, and avoiding the use of var from now on. Configuring the tools has taken more time than I thought as the tooling and the ecosystem is changing really fast. You read a recipe from a blog post which is 6 months old and it turns out that most of the stuff described is no longer working. Some npm packages don’t work anymore or the behavior at some point is very different from a previous version… apparently things are even more obscure on Windows which is the platform we have to use for this project.

As an example, I installed karma via npm the latest version. But when running gulp from the command line it stopped working with no error message at all, just a line break and back to the prompt. I commented all the lines in the gulpfile.js and then uncommented lines one by one executing gulp each time to discover that require('karma') was the reason. So I got into the *node repl and type this myself:

var k = require(‘karma’)

The result was the same, the node repl exited silently getting me back to the command line prompt. I couldn’t find a single way to catch the error although I tried try-catch, signal capturing, domains… and none of that worked. Then I started downgrading the version of the karma package until it worked for me. Version 0.13.3 works but 0.13.4 doesn’t. It must be a very specific problem on my machine but I couldn’t find any other solution. Eventually we are not using karma for now, we are using jasmine stand alone version and mocha.

This is the simplest gulpfile I was able to get working:

The generated package is all.js which I include in the html page. The application’s entry point is on main.js with exposes a function called startApp.

App starts up at the bottom of the html page:

main.js:

In order to run the tests the most simple choice was Jasmine stand alone, including the generated specs.js file in the SpecRunner.html page. As the tests include the production code, the generated file specs.js already include all the production code.

tests:

The next step was to include watchify in order to rebundle everytime a file is saved.

gulpfile.js:

This post was written on September 14th 2015, if you try to use any of the snippets posted a few months later they probably won’t work for you. These are the versions used:

package.json:

Las ventajas de usar parámetros y variables tipados en PowerShell

2015-08-18T09:52:05+00:00

Cuanto más uso PowerShell más convencido estoy de lo importante que es tipar las variables y los parámetros de las funciones. Debido a la forma en que trabaja PowerShell, especificar los tipos me ayuda a evitar comportamientos indeseados.

Por ejemplo, dado este script:

Set-StrictMode -Version 2

$items = Get-ChildItem
if ($items) {
   $items.Count
}

Si lo ejecuto estando en un directorio con varios archivos o carpetas, mostrará en pantalla el número de items. Pero si lo ejecuto en un directorio que tenga únicamente un ítem, el resultado será un error estrepitoso porque dice que no tiene ni idea de qué es eso de la propiedad Count. Simplemente con tipar la variable $items este ejemplo funcionaría perfectamente:

Set-StrictMode -Version 2

[array]$items = Get-ChildItem
if ($items) {
   $items.Count
}

Otro ejemplo habitual me lo encuentro cuando tengo una función en la que recibo la ruta de un directorio. Es muy habitual recibir un string con la ruta. El problema es que si trabajamos con rutas de red, esto no funciona muy bien y hay que añadirle por delante de la ruta la cadena “filesystem::”. A no ser que estemos interactuando con código .Net, en cuyo caso la ruta con el “filesystem::” por delante no le gusta ni un pelo. Al final es mucho más sencillo si hago el parámetro tipado con el tipo System.IO.DirectoryInfo, FileInfo o el que sea pertinente.

Switch parameters en PowerShell

2015-08-17T22:37:14+00:00

En PowerShell es muy común usar parámetros de tipo switch. La peculiaridad de estos parámetros es que al usarlos, se especifica el nombre del parámetro pero no se proporciona ningún valor, ya que se asume que al usarlo su valor será $true y $false si no se especifica. Ejemplos típicos son el uso de –_Recurse o -Force. _

Este sería un ejemplo de con este tipo de parámetros:

Function Do-Something([Switch]$Recurse) {
    Write-Host $Recurse
}

Do-Something -Recurse
Do-Something

Si ejecuto este script, veré por pantalla $True y $False, como podría esperar. Si le añado algunas modificaciones al código, el resultado sigue siendo el esperado:

Function Do-Something([Switch]$Recurse) {
    if ($Recurse.IsPresent) { 
        Write-Host "Lo haré recursivo"
    } Else {
        Write-Host "No lo haré recursivo"
    }
}

Do-Something -Recurse
Do-Something

Hasta aquí todo bien, pero en realidad no lo he estado haciendo como está recomendado. Si me diese por hacer una prueba en Pester en la que me viese obligado a verificar el $Recurse de este modo:

$Recurse | Should Be $True

Obtendría un resultado inesperado, ya que en realidad $Recurse no es de tipo Boolean. Al hacer un GetType() es posible ver que en realidad es de tipo System.Management.Automation.SwitchParameter. En realidad la forma correcta de verificar si me han pasado el parámetro es así:

$Recurse.IsPresent | Should Be $True

Y si alguna vez es necesario tratarlo como un boolean, siempre es posible recurrir al método ToBool().

Using C# Collections

2015-08-12T17:41:16+00:00

There are many ways to work with collections. We are following Microsoft Guidelines for Collections plus some ideas that Kent Beck explains in Implementation Patterns. I’ve created a repository with code examples so that anyone can play with them. All the unit tests in the project are green except for two, which are red on purpose to express my surprise when I wrote them, because it’s a behavior I didn’t expect.

IEnumerable<T> is not dangerous itself, the surprise may come up when the variable is created via a LINQ expression (.Select, .Where …). Then it may be the case that the query execution is deferred and the behavior of the code is totally unexpected. For this reason we try to avoid IEnumerable<T> and IQueryable<T> as the return type of functions.

Try not to expose collections as much as you can by wrapping them within objects you own which expose only the minimum domain required features. But if you have to expose the collection anyway, in our team the convention is:

ReadOnlyCollection<T> is the type returned to avoid modifications to the number of elements in the collection. (Internally it’s just a wrapper around IList).
IList<T> is returned when the collection may be modified and the order of the items in the collection is relevant.
ICollection<T> is returned when the collection may be modified and we don’t care about the order.

Good code expresses the programmer’s intent, this is why we choose from the three types above to return collections when we have to.

When it comes to parameters, it’s OK to use IEnumerable<T> as a parameter because it’s the most generic collection type. Although the caller could send an unresolved Linq query as an argument hidden in the form of a IEnumerable<T>, the method does not have to be defensive about it (in most cases).

Other built-in collections like List<T> are intended to be used internally, only for implementation. So it’s OK for a private method to return List<T>. The type Collection<T> actually implements IList<T> so I can’t find a good reason right now to use Collection<T> instead of just List<T>.

Cuidado que ($a -eq $a) no siempre es $true

2015-08-07T00:22:46+00:00

Este es uno de esos ejemplos en los que es importante intentar documentarse todo lo posible al desarrollar en un lenguaje/plataforma que no conocemos. Es frecuente asumir conceptos basados en nuestros conocimientos previos de otros lenguajes, pero en ocasiones nos puede jugar malas pasadas. En este caso voy a mostrar un ejemplo muy sencillo en el que yo asumí erróneamente el funcionamiento de algo tan sencillo como un operador de comparación.

Este problema lo encontré desarrollando una prueba mientras practicaba TDD. Por hacerlo fácil, este es el ejemplo más simple que se me ocurre para describir lo equivocado que estaba:

$a = @("item1", "item2")
if ($a -eq $a) { Write-Host "$a es igual que $a" }
else { Write-Host "$a no es igual que $a" }

Asumiendo que -eq es el operador de igualdad, alguien que no conozca PowerShell pero si conozca otros lenguajes de programación podría asumir que este script de ejemplo entraría por el if en lugar de por el else. Mi error fue precisamente ese. Si ejecuto este script en powershell, pintará en pantalla “item1 item2 no es igual que item1 item2”.

Si me hubiera molestado en leer la documentación de PowerShell hubiera visto que el operador -eq es bastante peculiar y en realidad hace algo más complicado. Aunque recomiendo leer la fuente original, estes es un pequeño resumen:

Si ambas variables son de tipo string, aplicará una comparación “case-insensitive” retornando $true o $false
Si la de la izquierda es un array de strings @(“item1”, “item2”) y la de la derecha es un string “item1”, buscará si el array contiene “item1” y retornará @(“item1”)
Si a la izquierda tenemos un array de strings @(“item1”, “item2”) y a la derecha un array de strings con un único item @(“item1”), retornará @(“item1”)
Como ya hemos visto al principio, si tenemos un dos arrays de strings, aunque sean iguales, retornará @()
Algunos ejemplos anteriores darán resultados distintos si invertimos las variables y cambiamos izquierda por derecha, si quieres saberlos, prueba! 😉

Conclusión, hay que leer más. Para mi es de mucha ayuda leer código de otros. Estudiar cómo están desarrollados Pester o Psake me ha permitido entender mucho mejor las bondades de PowerShell.

La importancia del Set-StrictMode

2015-08-03T23:50:39+00:00

Cuando empecé a programar scripts en PowerShell, cometía muchísimos fallos fruto de mi intoxicación con otros lenguajes, especialmente C#, con el que trabajo habitualmente. Después de un tiempo, me di cuenta que PowerShell tiene muchas más similitudes con JavaScript que con C# ya que es un lenguaje interpretado y de tipado débil. Y un tiempo después, aprendí que podía programar en PowerShell de una manera más próxima a TypeScript.

Lo explico de esta forma porque a mi cerebro le resulta más sencillo recurrir a este paralelismo. Cuando estoy programando en PowerShell, a mi cerebro le cuesta mucho menos si llevo puesto el sombrero de programador en TypeScript/Javascript) que si estoy pensando en C#. Cometo menos errores y el código me sale de forma más fluida.

Aún así hay un cmdlet que me ayuda muchísimo y que creo que permite generar un código mucho más robusto. Se trata del cmdlet Set-StrictMode. Este cmdlet permite establecer una serie de restricciones de cara al código que escribimos en PowerShell. Generalmente siempre añado esta línea al principio de mis scripts:

Set-StrictMode -Version 2

La versión 2 determina exactamente qué restricciones se van a aplicar. Las opciones son 1, 2 o Latest. Resumiendo lo que explican en la documentación de Microsoft:

1.0 – Prohíbe referencias a variables no inicializadas.

2.0 – Prohíbe:

Referencias a variables no inicializadas
Referencias a propiedades de un objeto que no existen.
Llamadas a fuciones utilizando la sintaxis de llamadas a métodos (usando los parñentesis)
El uso de variables sin nombre (${})

Latest – Aplica la versión más estricta de las disponibles. Dependerá de la versión de PowerShell que se esté utilizando, pero a día de hoy (PowerShell 5.0) el valor más alto sigue siendo 2.

Aunque la tentación puede ser recurrir al parámetro Latest, no lo recomiendo ya que podría implicar que se rompan scripts que funcionan bien si se incrementa el nivel de restricciones en una futura versión de PowerShell.

Dicho todo esto, qué mejor que un ejemplo:

function Suma($valor1, $valor2) {
    return $valr1 + $valor2
}

$resultado = Suma(1, 2)
Write-Host $resultado

Si ejecuto este script con Set-StrictMode -Off el resutado será que no se pinta nada en pantalla. La razón es que me se hace referencia a la variable $valr1 en lugar de a $valor1. Si corrijo este fallo, aún así obtendré un resultado indeseado, ya que en pantalla se pintará “1 2” sin las comillas. En este caso es un error típico cuando tengo puesto el sombrero de C#, el error es que estoy llamando a la función Suma como si fuese un método. Para que el script funcionase como deseo, debería ser así:

Set-StrictMode -Version 2

function Suma($valor1, $valor2) {
    return $valor1 + $valor2
}

$resultado = Suma 1 2
Write-Host $resultado

Sus similitudes con TypeScript

Al principio del post he mencionado que con el tiempo me he acostumbrado a la proximidad con TypeScript. Salvando las distancias, este podría ser una muestra basada en el ejemplo anterior:

Set-StrictMode -Version 2

function Suma([int]$valor1, [int]$valor2) { 
   return $valor1 + $valor2 
}

$resultado = Suma 1 2
Write-Host $resultado

Incluso podría retorcerlo un poco más y ponerme más estricto:

Set-StrictMode -Version 2

function Suma {
     Param(
       [Parameter(Mandatory=$true)][int]$valor1,
       [Parameter(Mandatory=$true)][int]$valor2
    )
    return $valor1 + $valor2
}

$resultado = Suma (1, 2)
Write-Host $resultado

Normalmente no llego tan lejos ya que creo que dificulta demasiado la lectura del código y, en la mayoría de los casos, no necesito recurrir a tantas restricciones en el código.

Además de recurrir al Set-StrictMode, aplico TDD para desarrollar mis scripts, algo que también resulta de muchísima ayuda, especialmente cuando empiezas a manejar mucho código. Pero lo explicaré en otro post.

Remove data structures noise from your tests with builders

2015-07-23T08:22:15+00:00

Among other qualities good tests should be easy to read, quick to understand. When the test requires complex data structures to be sent to the SUT or to be part of a stubbed answer, it takes longer to read. Moreover those structures use to evolve as the production code does causing too many changes in the tests in order to adapt them. An indirection level in between the test and the production code helps improve readability and ease of maintenance. Builders come to the rescue. I often overload builder methods to support several data structures and then apply the conversions internally.

As an example, this is the setup of one of our tests before the final refactor:

Imagine how ugly those tests were before writing the ACatalog builder. And this is the test after the builder was overloaded to supply a more comfortable API:

Productive Pair Programming

2015-06-30T23:20:46+00:00

The title of this post is redundant, pair programming is already a productivity technique. That’s my understanding or pair programming not just two people sitting together. Two people may code together for learning or mentoring purposes, however we pair for productivity reasons - productivity in the long term.

Like any other XP practice, this one aims to promote the values:

When I pair I get immediate feedback about my design and ideas. The communication is direct and the conversation provides us with simplicity. Good pairs respect each other and have the courage to split when necessary.

In my experience, it takes quite a lot of time to become a productive pair because one needs to learn how the other think. You need to know when the other person is focused not to break her flow. The navigator should never perform the role of the IDE, we obviously don’t interrupt to say… “you missed a bracket in there” as the IDE is already highlighting the mistake. We wait until the driver is not typing to ask questions, propose changes or take turns. Nevertheless waiting for the silence in order to start up a discussion is not enough. When I am the driver, I need my pair to realise that sometimes I need silence to think, specially when my flow is appropriate. The fact that I am not typing does not mean I am ready to talk about other levels of abstraction. As the driver, when this happens I ask the navigator for a few seconds of patience and trust. Flow is one of the most important principles when it comes to TDD and Pair Programming to me. If the flow is interrupted continuously, pairing is frustrating. As a navigator part of my mission is to discover when the driver is ready to listen to me. Although a healthy pair is talkative, silence is necessary. The amount of silence depends on the context. If the navigator is a junior (means that he lacks some knowledge - domain or technical) then as a driver I need more time to demonstrate my points. I need to conquer little milestones with code to later explain the underlying rationale with words. In this case, talking about written code that works, feels easier to me.

I’ve learned recently that sometimes I just need to ask the navigator to be quite and write down notes that we can discuss some minutes later. Although I used to be open to discussion at anytime, I’ve learned to prioritize flow. If the navigator is a senior then his comments will be practical and direct and so continuous discussion feels more natural.

The silent moments I am talking about last between 30 seconds and 3 minutes. Being quite for more than 5 minutes might be a sign that the pair is not working well. So yes, there is a conversation which is not the same as thinking out loud. My recommendation is that the navigator always has some paper notes to avoid thinking out loud half baked ideas. Discussing half baked ideas is OK as long as the driver is not typing. If I am typing I can’t listen to my pair.

Pairing is also about adding the right amount of pressure to the other. The driver should engage the navigator to avoid the “back-seat” driver syndrome. Taking turns help. Alternate often when the pair is well-balanced. Consider taking longer turns when there is a junior. Be careful, if the pressure trespass a certain threshold part of the intellectual capacity is cancelled. We can’t think properly under high pressure.

There are different kinds of interruptions from the point of view of the abstraction level. Low level abstraction comments are easier to handle than high level ones. For instance, say the driver has stopped typing and she is observing the code she’s just written, the navigator could say…. “that method should be private, rather public”. The level of abstraction of that comment is very likely compatible with the current thoughts of the driver, she can easily accept the change and still focus on the TO-DO list. However, something like “how would you implement that in Clojure” might kill the flow. That comment is OK once the driver is open to discuss. Having a TO-DO list or some kind of little roadmap that is created at the beginning of the pairing session is important to focus on the right level of abstraction.

There is a lot to write on pair programming, this post contains just a few ideas related to my recent experiences. I like this funny list of ways to hate pair programming - the challenge lies in getting to know your pair enough to notice when you are pairing badly.

Interrumpir la ejecución cuando Import-Module no encuentra el módulo

2015-06-30T18:03:02+00:00

Esto es un truco sencillo y muy básico de PowerShell, pero puede desconcertar bastante a quien está empezando o utiliza PowerShell de forma esporádica.

En PowerShell existen los llamados “terminating errors” y los “non-terminating errors”. Como su nombre permite intuir, unos finalizan la ejecución del script en curso cuando se producen y los otros no, limitándose a informar del error. Hasta aquí he descrito el comportamiento por defecto. Que un error sea del tipo “terminating” o del tipo “non-terminating”, no es algo que nosotros podamos controlar, y eso puede dar algún que otro quebradero de cabeza en algunas ocasiones.

Hoy estaba trabajando con un script en el que hacía un Import-Module y luego ejecutaba otra serie de scripts, algunos relacionados con el módulo que trataba de importar y otros no. Por simplificar, imaginemos que tenía un código como este:

Import-Module NombreDeModuloQueNoExiste
Write-Host "Aquí ejecutaría código NO relacionado con el módulo"
Write-Host "Aquí ejecutaría código relacionado con el módulo"

En este caso el módulo que estaba intentando importar resulta que no existía en mi máquina, por lo que al intentar hacer un Import-Module, obtenía un error que me indicaba que el módulo no se encontraba. El problema es que el comportamiento de PowerShell no era exáctamente como yo quería:

Como se puede ver, el resultado era que me salía el error, pero además se estaba ejecutando las dos líneas de código posteriores, y ese no era el comportamiento que yo quería. Como no estoy todo el día con PowerShell, a veces me pasan este tipo de cosas y me desorientan un poco, pero en este caso me acordaba de este tipo de problemas y lo pude atajar rápido.

Resulta que PowerShell tiene una variable llamada $ErrorActionPreference que determina el comportamiento a seguir en caso de errores “non-terminating”. El valor por defecto es Continue así que es algo así como el On Error Resume Next de Visual Basic.

Los valores posibles para esta variable son Stop, Inquire, Continue, Suspend y SilentlyContinue, pero yo normalmente únicamente utilizo los valores Stop y Continue.

De este modo, estableciendo la variable antes de ejecutar el Import-Module, es posible obtener el comportamiento deseado.

$ErrorActionPreference = "Stop"
Import-Module NombreDeModuloQueNoExiste
Write-Host "Este código nunca llega a llamarse"

Personalmente soy partidario de poner el valor a Stop al principio de los scripts, junto con el Set-StrictMode y luego cambiar este valor puntualmente si así lo necesito en algún caso.

Polymorphic Equality

2015-06-23T22:06:33+00:00

The default generation of Equality members provided by Resharper let you choose three different implementations when overriding the “Equals” method in a class (Alt+Insert -> Equality Members):

The default choice is “Exactly the same type as ‘this’” which IS NOT polymorphic. I mean, subtypes of that class will be considered not equal regardless of the values:

On line 8 it compares the types which in the case of subtypes will be different thus returning false.

I didn’t pay attention to this detail today and for some reason assumed that the comparison was going to work for subtypes. Lesson learned: always pay attention to generated code!

This is the generated code to consider subtypes equal:

And this is yet another implementation that works:

The other lesson learned is that overriding the Equals method in the child class when the base class already overrides it, increases the complexity too much. The code is hard to follow and surprising. It increases the coupling between the child class and the parent.

Avoid overriding the equality members in class hierarchies if you can.

¿Necesitas programar un servicio para Windows? Prueba Topshelf

2015-06-15T23:44:42+00:00

Programar un servicio para Windows suele ser una tarea engorrosa y Topshelf proporciona una alternativa bastante interesante y muchísimo menos engorrosa que la plantilla por defecto que incorpora Visual Studio.

Aunque podría enumerar bastantes aspectos interesantes de Topshelf, me quedo con uno que para mi es fundamental, permite que una aplicación de consola sea un servicio de Windows. Esto significa que es posible recurrir a la aplicación de consola durante la fase de desarrollo o para su ejecución de forma independiente, pero que además es posible instalar esa aplicación de consola como un servicio Windows simplemente pasando un parámetro en su ejecución.

Utilizar Topshelf para crear un servicio de Windows es muy sencillo. Voy a describir los pasos básicos necesarios para dar un servicio, aunque luego podemos complicarlo bastante:

Creamos una aplicación de consola e instalamos el paquete Topshelf
Añadimos una clase que contenga la lógica del servicio que queremos crear. El esqueleto podría ser como este:
Modificamos la clase Main para configurar el servicio:

En la documentación es posible encontrar muchos más detalles. Por ejemplo, además de poder configurar el código a ejecutar en el inicio (WhenStarted) o en la parada (WhenStopped), podemos configurar el comportamiento para la pausa (WhenPaused), continuación (WhenContinued) y el apagado (WhenShutdown).

Una vez hecho esto tenemos una aplicación de consola que podemos ejecutar de forma individual, depurar desde Visual Studio o instalarla como servicio y Topshelf se encargará de ejecutar el código correspondiente al inicio del servicio. Para instalar el servicio sólo es necesario ejecutar la aplicación de consola con el parámetro “install” y para desinstalarla con el parámetro “uninstall”.

Muy importante a tener en cuenta es el usuario con el que se va a ejecutar el servicio. Por ejemplo, si en el servicio vamos a utilizar Owin para levantar una Web o un API, este código de ejemplo no funcionará porque si el servicio arranca como LocalSystem no tendrá los permisos adecuados.

Es posible pasar otros parámetros para configurar el comportamiento deseado para el servicio en lo que a modo de inicio, usuario de ejecución, ejecución de comandos después de su instalación, etc. Lo mejor es ver la documentación para estar al tanto de todas las opciones.

Utilizando Exceptionless para monitorizar logs y excepciones

2015-06-05T18:11:52+00:00

Cada vez que abordo un nuevo desarrollo, considero que la generación de trazas es una parte vital ya que es uno de los mecanismos que nos va a permitir diagnosticar e identificar cualquier tipo de problema cuando estemos en producción, en ocasiones incluso antes de que los propios usuarios lleguen a reportarlo.

Hacer que nuestra aplicación genere las trazas adecuadas es una gran herramienta, no sólo para diagnosticar bugs, también permite identificar problemas relacionados con el rendimiento y otro tipo de funcionamientos anómalos de nuestras aplicaciones.

Durante los últimos años he utilizado NLog, la librería de The Object Guy, desarrollos propios y estos últimos meses he utilizado Serilog en proyectos WPF, Web y WinRT. Pero siempre hay algo que no termina de convencerme, los interfaces para explorar los logs. He probado aplicaciones para Windows como LogExpert, BareTail, Harvester, Tail for Win32, o soluciones más trabajadas como Splunk o LogEntries, pero al final ninguna me ha convencido por funcionalidad o por coste.

Hace unos meses me encontré con ExceptionLess y me pareció un proyecto bastante interesante. A modo de resumen, estos son algunos de los puntos que me parecieron interesantes:

Puedo utilizarlos como servicio o montarlo sobre mi propia infraestructura.
Dispone de librerías PCL con soporte offline. Lo que significa que puedo utilizarlo en la tablet y, cuando no tenga conexión, guarda los logs en local para enviarlos cuando la conexión vuelva.
Tiene soporte de notificaciones.
Puedo adjuntar objetos complejos a las trazas, para poder consultarlos cuando vea la traza desde la UI. Básicamente, si se puede serializar en Json, se puede adjuntar.
Me intenta facilitar la identificación de problemas/patrones agrupando las trazas o mostrando las que más se producen.
Es Open Source. Y esto me parece especialmente importante porque me permite solucionar algunas de las carencias menores que estoy encontrando (ya sólo me falta aprender Angular ;P).

Y como no todo son cosas buenas, me parece importante remarcar algunas cosas que no me han gustado durante su uso:

El interfaz de usuario aún está un poco verde. Tiene algunos detalles de interfaz que desorientan un poco. Cosas tontas como que al darle a buscar no te mande al listado con los resultados de la búsqueda si estás en el detalle de un log. Simplemente establece el filtro como el filtro activo, pero tienes tú que irte al listado de logs para poder verlos.
Está muy orientado a que lo uses con su plataforma. Esto se nota muchísimo al configurarlo en un servidor propio en detalles como que las configuraciones por defecto apunten a su dominio (exceptionless.io) o que aspectos de la configuración de servidor y de los clientes son distintos.

Ojo si quieres configurar ExceptionLess en tu propio servidor

No tiene sentido hacer un tutorial sobre cómo configurarlo en local porque en github están las instrucciones y no son complicadas. Únicamente es necesario tener MongoDB y ElasticSearch. En caso de montar varios servidores de API, es necesario Redis, pero para un único nodo no es necesario y utiliza una implementación en memoria.

Ten en cuenta que necesitas instalar dos proyectos, el API y la UI. Para este ejemplo, supongamos una configuración local de pruebas con el API instalado en: http://localhost/ExceptionLess.API

Al instalar la UI, es necesario editar el fichero app.config para especificar en la clave BASE_URL la url del API. Pues bien, aunque la primera opción parece que sería poner la url ‘http://localhost/ExceptionLess.API’, al hacer esto no va a funcionar. La url correcta que hay que configurar es: ‘http://localhost/ExceptionLess.API/api/v2’

Sin embargo, para enviar logs a ese servidor desde una aplicación .Net, la url que debo configurar si que es ‘http://localhost/ExceptionLess.API’. Esto me volvió un poco loco al principio.

C# Async/Await and Task Parallel Library

2015-05-29T14:04:27+00:00

In order for a native desktop application to be responsive, I mean, not to freeze while sending a request over the network or processing a heavy CPU operation, these operations have to run in a separate thread.

.Net 4.0 introduced promises (a well-known concept for JavaScript developers), the Task object is a promise in C#. Later on, C# 5.0 introduced a nice syntactic helper to work with theses promises: async and await keywords.

Powerful features, comfortable to develop with but it’s important to know how they work behind scenes. Otherwise you could get in trouble with deadlocks and invalid operation exceptions.

Our teammate Modesto San Juan recommended the book “Async in C# 5.0” by Alex Davies, and I found it great. I’ve created a tiny sample app to summarize the things I’ve learned from the book:

Sample app: https://bitbucket.org/carlosble/asyncawait - Look at MainWindow.xaml.cs file.

The app is just a window with a bunch of buttons and a text field. Every button has an event handler in the MainWindow.xaml.cs that exercises each use case.

The method names in that file along with some comments, explain the most remarkable features for our team right now.

Most of the stuff in Alex’s book is very well summarized in this presentation by Alex Casquete & Lluis Franco:

Async Best Practices from Fimarge

Cómo crear Appx para Sideloading desde Integración Continua

2015-05-13T06:45:57+00:00

Cuando trabajamos con aplicaciones para la tienda de Windows, hay escenarios en los que necesitamos hacer Sideloading. Básicamente el Sideloading nos permite instalar una aplicación de la tienda de Windows, sin utilizar la tienda de Windows. Las razones para querer hacer Sideloading pueden ser muchas: probar la aplicación en local antes de subirla a la tienda, instalar la aplicación en algunos dispositivos para hacer testing en friends&family o simplemente utilizar la aplicación a nivel corporativo fuera de la tienda de Windows.

En uno de los proyectos en los que estoy trabajando ahora mismo nos encontramos dentro de esos escenarios. Tenemos una aplicación que se distribuye mediante Sideloading y además tenemos un equipo de Q&A que prueba tanto las versiones de desarrollo como las release candidate.

Como resultaba bastante pesado tener que estar dependiendo de generar los paquetes para Sideloading de forma manual, decidimos crear estos paquetes de forma manual desde nuestro entorno de integración continua. En este caso utilizamos Jenkins, pero lo aquí descrito funciona para cualquier otro sistema.

Microsoftnos dice en este enlace cómo crear un paquete utilizando msbuild. Básicamente se limita a pedir a msbuild que compile el proyecto de la app para la tienda de Windows:

MSBuild MyProject.csproj /p:OutDir=C:\builds\droplocation\

El problema de esta aproximación es que en proyectos grandes, es normal tener una solución con varios proyectos (pero sin pasarse eh!). Al tener varios proyectos solemos tener una estructura de carpetas que implica que, al compilar un proyecto de forma independiente, msbuild nos de problemas para encontrar los paquetes de nuget porque los busca de forma relativa a la ruta de la solución y no a la ruta del proyecto.

En fin, tengamos este problema o no, que podría solucionarse de muchas otras formas, una manera muy sencilla de tener un paquete de aplicación es modificar el .csproj para que cree el paquete de aplicación cada vez que compilamos el proyecto (sea dentro de una solución o de forma independiente). Para ello tenemos que añadir estas líneas al .csproj de nuestra aplicación de la tienda:

<PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != 'true'">
  <GenerateAppxPackageOnBuild>True</GenerateAppxPackageOnBuild>
  <AppxPackageDir>$(OutputPath)AppPackages</AppxPackageDir>
  <AppxPackageName>$(AssemblyName)_$(Platform)</AppxPackageName>
</PropertyGroup>

Es muy importante tener en cuenta el atributo Condition del PropertyGroup, ya que así evitamos que se genere el paquete de la aplicación cada vez que la compilamos desde Visual Studio (no queremos penalizar el tiempo de compilación del equipo de desarrollo). Por supuesto, podemos cambiar esta condición por una que tenga en cuenta el perfil de compilación o cualquier otro factor, pero a nosotros nos ha parecido bastante adecuada esta.

Por otro lado, al especificar el AppxPackageName conseguimos tener siempre un el mismo nombre de archivo .appx, para evitar que el criterio por defecto de que el número de versión se incluya en el nombre del archivo. Así facilitamos la vida de cara a los procesos de automatización que describiré en próximas entradas.

Otro detalle importante a tener en cuenta es especificar en el nombre del paquete la plataforma, porque en alguna ocasión me ha pasado que msbuild genera los .appx de 32 y 64 bits dentro de la misma carpeta, machacando el primero al generar el último, lo que dará grandes quebraderos de cabeza.

Mocking (stubbing) async calls (async/await)

2015-02-10T11:57:16+00:00

.Net 4.5 came out with a really handy built-in asynchronous mechanism, async and await. However the method signature of a void method is a bit strange:

It is possible to use async void but it’s not recommended unless we are talking about event handlers. It’s also a bit strange the fact that the type specified in the signature is not the one returned:

But everything else is great and very handy.

Stubbing method calls can be hard though. You can get weird exceptions like System.AggregateException when running tests with NUnit. The problem comes up when awaiting for a

stubbed async method:

The problem is that Moq will make the stubbed method return null when invoked, because we are not specifying any return value. The default value for Task is null. We should tell Moq to return a proper Task:

The key is to return a new task: Task.Factory.StartNew(lambda)

Practising Mob Programming

2014-12-02T01:50:48+00:00

In the past edition of Socrates UK, I met Gianfranco Alongi who told us about his team’s experience with Mob Programming. It was the first time I heard about it. As the site says, Mob programming is people working at the same time, in the same space, at the same computer, on the same thing. Gianfranco said it was very useful for them.

At the beginning of November three of my fellow craftsmen and I joined a team of other 12 developers to work on a new project. We are building a DMS (Dealer management system) and an IMS (Importer management system). The project is very exciting but we don’t have a clue on the domain. We are also a lot of people with different programming styles. So we decided to give Mob Programming a try and after a few weeks the results are very positive.

Some lessons we have learned along the way:

Like with pair programming, navigators should take notes whilst the driver is at the keyboard, rather than disturbing him constantly.
Only when the driver raises his hands off the keyboard we are allowed to discuss.
Rotate frequently: it’s faster to jump in the keyboard and do it yourself than trying to explain the code you envision.
Limit the group size to 5 or 6 people. We find that 4 is a good number, more than that is not being productive for us. Sometimes it’s useful though, when we want to define conventions for the whole team.
The group should be stable: if new people join the discussion in the middle then we have to explain again and again the code and the decisions we have already made. It’s like the never ending story.
At some point I had to leave a session right in the middle of something. When I came back a colleague told me that the people who were shy or less proactive during my driving period, started proposing interesting ideas during my absence. The people considered “seasoned” or “experienced” should go away from time to time for the others to feel empowered.

So far the project is just fantastic. People are awesome, learning incredibly fast, very enthusiastic. Everyone wants to learn and contribute. We are all learning a lot and doing our best. I can’t think of a better project. We are very lucky.

Codesai

Our Architectural Guardrails for AI-Generated Code

Introduction.

What we’d like to avoid.

1. Domain should not depend on infrastructure.

2. Production code should not have circular dependencies.

3. Production code should not depend on tests.

How to enforce these design rules.

Why not skills, docs or agentic reviews: guidelines vs guardrails, determinism and costs.

1. Architecture Tests (a reliable guardrail).

a. Likelihood of adherence.

b. Token Cost and Efficiency.

2. Docs/Skills (guidelines).

a. Likelihood of adherence.

b. Token Cost and Efficiency.

3. Reviews with Agents (an unreliable guardrail).

a. Likelihood of adherence.

b. Token Cost and Efficiency.

Conclusion.

Linters vs. architecture tests for design rules.

Our minimal architecture tests.

For the deliberate practice sessions.

For a client’s project.

Conclusions.

Acknowledgements.

References.

Notes.

Roots of the mock trauma in a Flash

Roots of the mock trauma.

An Expensive Errand: Chasing 100% Mutation Coverage with an Agent Can Make Your Test Suite Worse

Introduction.

The code and tests generated by the coding agent.

Evaluating the AI generated tests with mutation testing.

M1.

M2.

M3.

M4.

M5.

Blindly chasing 100% mutation score with a coding agent.

The new version of the integration tests of MariaDBDiscountsRepository.

New test case 1: 'should throw an error when the discount type is unknown'

New test case 2: 'should handle non-string condition data correctly (e.g., when driver already parses JSON)'

New test case 3: 'should not find a discount if the query filter is broken (killing WHERE d.code = ? survivor)'

The unit tests of MariaDBDiscountsRepository… 😞.

Non redundant test case: 'should throw an error with specific message when discount type is unknown'

Non redundant test case: 'should handle string condition_data correctly'

Conclusion: the generated unit tests were useless.

Going back and analyzing which mutants are relevant first.

Relevant Mutants.

Analyzing the surviving mutants in MariaDBDiscountsRepository using the idea of Relevant Mutants.

Learnings from Relevant Mutants.

Summary.

Acknowledgements.

References.

Notes.

Refactoring with AI: Introducing a State Pattern using a coding agent

Introduction.

Refactoring to the state design pattern with an AI agent.

Using our metadocumentation to learn.

Improving the design a bit more.

Refactoring with an agent or using IntelliJ?

Using our metadocumentation to learn.

Conclusions.

Acknowledgements.

References.

Notes.

Detallando historias de usuario para acotarlas y reducir su ambigüedad.

Introducción.

Añadir más detalle.

Paso 1.

Paso 2.

Explorar ejemplos ¿Posibles particiones?.

Conclusión.

Agradecimientos.

Serie Historias de Usuario.

Referencias.

Notas.

Metadocumenting to Improve Our Interactions with Coding Agents: Capturing Reasoning, Summaries, and Prompt Feedback

1. The reasoning file.

2. The prompt feedback file.

The new version of the integration tests of `MariaDBDiscountsRepository`.

New test case 1: `'should throw an error when the discount type is unknown'`

New test case 2: `'should handle non-string condition data correctly (e.g., when driver already parses JSON)'`

New test case 3: `'should not find a discount if the query filter is broken (killing WHERE d.code = ? survivor)'`

The unit tests of `MariaDBDiscountsRepository`… 😞.

Non redundant test case: `'should throw an error with specific message when discount type is unknown'`

Non redundant test case: `'should handle string condition_data correctly'`

Analyzing the surviving mutants in `MariaDBDiscountsRepository` using the idea of Relevant Mutants.