DEV Community: Nicolas Villavicencio

The Reliable Power of the FIRST Principle: A Comprehensive Guide

Nicolas Villavicencio — Mon, 31 Jul 2023 13:02:15 +0000

Writing unit tests correctly is as important as coding features. To achieve this, certain principles help ensure that unit tests are easy to use and modify when adding new test cases. The FIRST principle, which stands for Fast, Independent, Repeatable, Self-validating, and Timely, is a guide for us in this endeavor

(F)ast

Unit tests should execute quickly to verify that the system behaves as expected during fixes, refactoring, or when new features are added. If running tests for a project takes a substantial amount of time, developers will tend to use them less frequently. Waiting 30 minutes to check if adding a few lines of code breaks something is not ideal.

Therefore, it’s crucial to focus on creating fast-running tests. This can be achieved by configuring tests to run in parallel or ensuring that the context setup process is not overly time-consuming.

(I)ndependent

Independence among tests is crucial because modifying one test should not break others. If a test’s modification causes failures, it becomes less reliable and harder to maintain. To ensure independence, it is essential to verify that tests are executed randomly, which is generally the case. Additionally, leveraging mock tools to isolate the code under test provides the determinism needed for thorough testing.

(R)epeatable

A unit test is repeatable if executing it multiple times produces the same result consistently. Using mock tools should make the untested code behave consistently, regardless of when or in what order it is executed. A typical example of failure to achieve repeatability is observing a project that relies on system objects to represent dates, causing test failures on January 1st each year.

(S)elf-validating

A self-validating test is one that doesn’t rely on manual checks to determine success or failure, reducing the risk of human errors. Additionally, a self-validating test prepares its own context before execution, avoiding the need for manual tasks that could impact the test results.

(T)imely or Thorough

“Timely” means writing tests for code in the same timeframe as the code itself. Tests help quickly identify issues and ensure that everything functions correctly, allowing dynamic changes and improvements throughout the feature development process.

On the other hand, “Thorough” reminds us not only to test the happy path but also to cover potential error scenarios when executing the code. For example, if a function takes a parameter, we should test not only valid values but also null values (if the language allows) and other boundary cases.

Both “Timely” and “Thorough” principles are not mutually exclusive; they should be applied together.

Summary

Apart from the first principles there are other aspects to remember include.

Simplicity: Simple code is easier to read and modify.
The “Single Responsibility” principle of S.O.L.I.D also applies to tests. When designing tests, consider that each test should focus on verifying one specific thing, making it easier to identify what is functioning correctly or not in the source code.

Lastly, regarding unit test coverage, while it is often necessary for development processes to reach a certain percentage of test coverage before deploying a feature, developers must understand that coverage does not guarantee the correct functioning of the entire system. It merely indicates that tests have executed in specific parts of the code. Tests may not necessarily aim to validate those specific functionalities. Consequently, test coverage should be accompanied by a comprehensive understanding and complemented by other quality metrics for tests.

For more information, see Mutation Testing.

The post The Reliable Power of the FIRST Principle: A Comprehensive Guide first appeared on Samurai Developer.

Testing Pyramid a Simple Way to Ensure Code Quality

Nicolas Villavicencio — Sun, 16 Jul 2023 22:43:51 +0000

Mike Cohn introduced the concept of Testing Pyramid in his book “Succeeding with Agile.” It is a visual metaphor used to categorize tests into different layers, each with specific characteristics.

Level 1 : Unit Tests

Located at the base of the Testing Pyramid. The fundamental characteristic of unit tests is that they focus on verifying that each unit of code functions correctly in isolation.

What is a unit : A unit is considered the smallest unit of functionality. For example, in the case of a shopping cart, it can calculate taxes, apply discounts, and calculate the total amount to be paid.

Vladimir Khorikov summarizes it well in his book.

“A test should tell a story about the problem your code helps to solve, and this story should be cohesive and meaningful to a non-programmer.”

The main objective of unit tests is to verify that each unit of code functions correctly in isolation.

To achieve this, we need to test all possible inputs of the unit, considering boundary cases and potential errors.

These tests are called open-box tests because we are familiar with the tested algorithm, allowing us to choose inputs that push the unit to boundary conditions and error cases.

Unit tests focus on identifying and correcting component-level errors before they are integrated into the complete system.

As a characteristic within the Testing Pyramid, unit tests are the tests that we develop the most in a project. They should be fast to execute as they accompany us throughout the development of new features and refactors to ensure that the system continues to function as expected at the unit level.

If we have a set of unit tests that take too long to complete, programmers will tend to run them less frequently, making it more challenging to catch bugs. Moreover, it can lead to their decreasing usage as it adds more time to the development cycle.

Level 2 : Integration Tests

Integration tests aim to verify the correct functioning between our systems and third-party systems.

To identify when we need integration tests, we can use the rule that whenever we need to serialize and deserialize data, we will need to perform some integration tests.

This happens in some of the following cases:

Calls made to our REST API services.
Readings and writings to databases.
Calls to APIs of other applications.
Reading or writing to message queues.
Reading or writing to a file system.

We can divide integration tests into two categories:

Broad: It aims to bring up all external services interacted with, requiring significant configuration and maintenance of the testing environment.
Narrow: It focuses on interacting with a particular external service, while the other dependencies are mocked.

When we refer to Broad Integration Tests, we are talking about a type of closed-box testing where we don’t know how the algorithm is implemented, and we focus more on testing to verify that we get the expected response for certain inputs.

Narrow integration tests focus on testing different interactions between our service and a single third-party service, using mocks based on a predefined and well-documented definition.

These tests assume that the communication contract between modules is correct and aim to find faults in our system with one of the predefined responses.

Level 3 : End-to-End Testing

End-to-End (E2E) tests are aimed at verifying the functioning and performance of a flow in the application from start to finish, simulating real-use scenarios.

In other words, they check scenarios that users will encounter when using the application as if it were in production.

The objective of End-to-End tests is to ensure that the performance is within an acceptable range. They serve to verify that the application continues to function as expected, and our changes have not broken any critical flows in the application.

On the other hand, this type of test is one of the most challenging to develop, as it requires a significant amount of effort and development time due to involving multiple applications at once.

That is why these types of tests are reserved for essential flows in our application that must not fail or degrade.

Conclusions

Although the concept of the Testing Pyramid has been around for many years, it remains relevant today as it helps us define the types of tests we perform, their objectives, and their characteristics, regardless of the language or programming paradigm used.

It is essential to have a good understanding of these concepts and ensure that everyone in the development team shares the same understanding when discussing each type of test will we need.

The post Testing Pyramid a Simple Way to Ensure Code Quality first appeared on Samurai Developer.

From Chaos to Order: Refactoring Fundamentals for Better Results

Nicolas Villavicencio — Sun, 11 Jun 2023 03:07:49 +0000

One of the skills a samurai developer must develop is knowing how to apply refactoring in their day-to-day work. When starting the software development journey, one tends to follow the axiom “If it works, don’t touch it, or it might break.” This fear naturally arises from inexperience and the context in which one works. However, I believe that as professionals, we must pursue the ideal of continuous improvement, and to achieve that, we must overcome that fear. It’s good to have a protocol on how and when to act to produce better code.

This is what Richard Fowler talks about in his refactoring talks. I will now summarize the compilation of ideas he promotes, hoping it serves as a guide for you as well.

The Red and Green Circle

The common practice in TDD is to write the test first and then the functionality, which abstracts us from the implementation. Then one proceeds to develop the functionality and make the test go from failure (red) to success (green).

It is common that as we progress in the development process, we encounter code that is ugly. This may be because it is old or because it was not coded clearly.

The Two Hats Come into Play

So, you found code that is ugly, hard to read, or too complex. The question is, do you ignore it or do something to change it? The answer would be to strive for improvement and change it (as long as it meets certain characteristics that I will describe later).

Richard Fowler talks about two work styles when sitting down to develop: the construction hat, which one wears when adding new functionality to the system, and the improvement hat, which is used when performing a refactoring task. During development, we will be forced to switch hats depending on what we want to do. The important thing is not to do both things at the same time because it can lead us to make changes without being sure that we can run a battery of tests to ensure that the system is functioning correctly.

Workflows of Refactoring

Changes that do not alter functionality or have a small impact should be made immediately. Such as renaming methods, variables, and functions to make them clearer, and extracting methods to better encapsulate their behavior. Fowler refers to this practice as “The Boy Scout Rule,” based on the principle of “Always leave the campsite cleaner than you found it.” This refactoring method is called Litter-Pickup Refactoring.

The Preparing Refactor

This type of refactor often occurs when we want to add a new feature, but we realize that the current code does not easily allow for adding this feature. However, by making some changes, it may be easier to implement the new feature. This type of refactor is essential to keep the code clean and promote easier addition of future features, reducing development time.

The Planned Refactor and Long-Term Refactor

So far, we have talked about refactors that are done during our day-to-day work and do not require meticulous planning and organization. However, there is a type of refactor that does require these measures: planned refactors. These are refactors that are planned, estimated, and have a medium to large size or a significant impact on the system’s architecture and functionality, requiring careful attention during their execution. Fowler warns that these types of refactors are “bad” in the sense that a well-designed system should not need this type of refactor, and medium to large refactors can be carried out by breaking them into smaller tasks and iterating to accomplish them. This type of refactor is called long-term refactor. However, it is not wrong for an occasional refactor of this kind to arise.

When should I apply refactoring?

Up to this point, one might think that my idea of refactoring is to be a kind of bulldozer that cleans up everything in its path. Well, yes and no. To decide when to apply a non-simple and quick refactor, one must consider a series of things:

How much time will it take?
How often will I encounter this “bad smell” code in my day-to-day work?
Am I in a moment where I can carry it out?

For example, if we are dealing with a problem in production, with alarms going off and messages coming through all communication channels, clearly we are not going to start doing refactors that take more time to generate a solution. Here we don’t change hats; the goal is to create the fix.

As for how often I will come across the code, that is the metric I pay the most attention to because the modules that change the most should be the clearest and cleanest ones, as they facilitate my task of understanding what they do and being able to modify or add more features to them. Code that doesn’t have much impact and is unlikely to be encountered again doesn’t require the effort; after all, time is a resource and must be managed in the best possible way.

Justifying the Refactoring

Fowler also talks about how to explain to our bosses or leaders the need for refactoring to be part of development, just like testing. It is true that we can cite reasons such as readability or speed, but these justifications are purely technical and tend to dilute as they go up the ladder of management. However, there is one justification that always prevails: money.

Instead of presenting a technical diatribe of justifications, it is easier to reach people with things they are more familiar with, for example:

“I need to refactor X because it will make it faster to add functionality Y, and if we want to add Z tomorrow, it will be easier too.”

“This refactor reduces our expenses on the database, CPU, hosts, etc., by minimizing resource usage.”

The moment we keep going back and forth about performing refactorings is the moment we lose the battle.

The post From Chaos to Order: Refactoring Fundamentals for Better Results first appeared on Samurai Developer.