What is actually happening when we create a mock? Which types of mocks are there? Is mocking good or bad? Well, as always, everything depends on the context. And here we will consider some of the main situations about when to mock and when not to mock, but especially why.
First of all, we should define what a mock is:
In a unit test, mock objects can simulate the behavior of complex, real objects and are therefore useful when it is impractical or impossible to incorporate a real object into a unit test.
Mocking makes sense in a unit testing context. An integration test should go through the real implementation checking the integration between multiple units, which are even allowed to talk to the DB or File IO: infrastructure code. Therefore we should agree that a unit test is a fast and deterministic test that doesn’t rely on external dependencies and doesn’t require any special context to run. …
You are reviewing a Pull Request (PR) and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.
But imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.
Well, there are multiple options. …
I have seen people using the array_merge
function in a loop like:
$lists = [
[1, 2],
[3, 4],
[5, 6],
];$merged = [];foreach($lists as $list) {
$merged = array_merge($merged, $list);
}// $merged === [1, 2, 3, 4, 5, 6];
This is a very bad practice because it’s a (memory) performance killer!
Instead, you should use the spread operator (in PHP since 5.6!):
$lists = [
[1, 2],
[3, 4],
[5, 6],
];$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];
What if you had an assoc-array instead like this one?
$lists = [
'key-1' => [1, 2],
'key-2' => [3, 4],
'key-3' => [5, 6]…
Having a class, `Customer`:
/**
* @psalm-immutable
*/
final class Customer
{
// Using PHP 8 constructor property promotion
public function __construct(
public string $name,
) {}
}// We create a list of 6 customers
$customers = array_map(
fn(int $i): Customer => new Customer("name-{$i}"),
range(1, 6)
);
Whenever we want to manipulate a list of Customers, we can pass as an argument: `…$customers`. …
No goal should be an achievement on their own, but the process itself that helps us to go in the direction of these goals.
Goals, in business and in life in general, should be conceived as directions, where their real intention is to help us accomplish more in the way we planned or want.
If we get rewarded only for results and not for processes, we will become pretty miserable.
Society doesn’t reward the journey, but the results. And that’s exactly part of the problem when you are too focused on how society acts on you. Of course, it’s important to listen to society, but it’s more important to listen to ourselves in order to improve constantly. …
These tests are also known as Characterization tests.
A characterization test describes the actual behavior of an existing piece of software, and therefore protects existing behavior of legacy code against unintended changes via automated testing. This term was coined by Michael Feathers.
They enable and provide a safety net for extending and refactoring code that does not have adequate unit tests. A test can be written that asserts that the output of the legacy code matches the observed result for the given inputs.
These are my learnings one year after reading Working Effectively with Legacy Code and applying it to the different projects I’ve been working on since then. …
In December 2015, PHP 7 introduced scalar type declarations and with it the strict types flag.
To enable the strict mode, a single declare directive must be placed at the top of the file. This means that the strictness of typing for scalars is configured on a per-file basis. This directive not only affects the type declarations of parameters, but also a function’s return type.
The good thing about declaring a PHP file as strict is that it actually applies to ONLY the current file. It ensures that this file has strict types, but it doesn’t apply to any other file in the whole project. …
TL;DR: If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask.
Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example.
Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. …
TL;DR: Benefits of final classes: clear contracts, isolated side effects, testability, low complexity and cognitive load, code fluidity, and confidence in yourself.
When you see a class prefix with final
you will prevent a particular class to be extended by any other, which not only makes it more readable but also makes you be sure that the scope of the logic where you are is limited to that particular class.
The Open-Close Principle states: open for extension but close for modification.
If for any reason, a good one you should be completely aware of, you decide to create an inheritance there, well, then just drop the final
keyword and you are good to go. …
The intention of this post is not to explain the different testing techniques out there that we can use. I’m not going to tell you what the differences are between unit, integration, feature, or end-to-end testing.
I’m going to tell you why we should consider testing as part of our daily development and how it’s directly linked to the software quality.
I’m still amazed by the lack of experience about testing in software in general. Common ignorance in this world about best testing practices for us as developers. …
About