A Partial Mock is a testing technique where only certain methods of an object are mocked, while the rest of the object retains its real implementation. This is useful when you want to stub or mock specific methods but keep others functioning normally.
When you want to test a class but isolate certain methods.
When some methods are difficult to test (e.g., they have external dependencies), but others should retain their real logic.
When you only need to stub specific methods to control test behavior.
Suppose you have a Calculator
class but want to mock only the multiply()
method while keeping add()
as is.
class Calculator {
public function add($a, $b) {
return $a + $b;
}
public function multiply($a, $b) {
return $a * $b;
}
}
// PHPUnit Test with Partial Mock
class CalculatorTest extends \PHPUnit\Framework\TestCase {
public function testPartialMock() {
// Create a Partial Mock for Calculator
$calculator = $this->getMockBuilder(Calculator::class)
->onlyMethods(['multiply']) // Only mock this method
->getMock();
// Define behavior for multiply()
$calculator->method('multiply')->willReturn(10);
// Test real add() method
$this->assertEquals(5, $calculator->add(2, 3));
// Test mocked multiply() method
$this->assertEquals(10, $calculator->multiply(2, 3));
}
}
Here, add()
remains unchanged and executes the real implementation, while multiply()
always returns 10
.
Partial Mocks are useful when you need to isolate specific parts of a class without fully replacing it. They help make tests more stable and efficient by mocking only selected methods.
The Fetch API is a modern JavaScript interface for retrieving resources over the network, such as making HTTP requests to an API or loading data from a server. It largely replaces the older XMLHttpRequest
method and provides a simpler, more flexible, and more powerful way to handle network requests.
fetch('https://jsonplaceholder.typicode.com/posts/1')
.then(response => response.json()) // Convert response to JSON
.then(data => console.log(data)) // Log the data
.catch(error => console.error('Error:', error)); // Handle errors
Making a POST Request
fetch('https://jsonplaceholder.typicode.com/posts', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({ title: 'New Post', body: 'Post content', userId: 1 })
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));
✅ Simpler syntax compared to XMLHttpRequest
✅ Supports async/await
for better readability
✅ Flexible request and response handling
✅ Better error management using Promises
The Fetch API is now supported in all modern browsers and is an essential technique for web development.
Object Query Language (OQL) is a query language similar to SQL (Structured Query Language) but specifically designed for object-oriented databases. It is used to query data from object-oriented database systems (OODBs), which store data as objects. OQL was defined as part of the Object Data Management Group (ODMG) standard.
Object-Oriented Focus:
SQL-Like Syntax:
Querying Complex Objects:
Support for Methods:
Integration with Object-Oriented Languages:
Suppose there is a database with a class Person
that has the attributes Name
and Age
. An OQL query might look like this:
SELECT p.Name
FROM Person p
WHERE p.Age > 30
This query retrieves the names of all people whose age is greater than 30.
In practice, OQL is less popular than SQL since relational databases are still dominant. However, OQL is very powerful in specialized applications that utilize object-oriented data models.
A Remote Function Call (RFC) is a method that allows a computer program to execute a function on a remote system as if it were called locally. RFC is commonly used in distributed systems to facilitate communication and data exchange between different systems.
Duplicate Code refers to instances where identical or very similar code appears multiple times in a program. It is considered a bad practice because it can lead to issues with maintainability, readability, and error-proneness.
1. Exact Duplicates: Code that is completely identical. This often happens when developers copy and paste the same code in different locations.
Example:
def calculate_area_circle(radius):
return 3.14 * radius * radius
def calculate_area_sphere(radius):
return 3.14 * radius * radius # Identical code
2. Structural Duplicates: Code that is not exactly the same but has similar structure and functionality, with minor differences such as variable names.
Example:
def calculate_area_circle(radius):
return 3.14 * radius * radius
def calculate_area_square(side):
return side * side # Similar structure
3. Logical Duplicates: Code that performs the same task but is written differently.
Example:
def calculate_area_circle(radius):
return 3.14 * radius ** 2
def calculate_area_circle_alt(radius):
return 3.14 * radius * radius # Same logic, different style
1. Refactoring: Extract similar or identical code into a shared function or method.
Example:
def calculate_area(shape, dimension):
if shape == 'circle':
return 3.14 * dimension * dimension
elif shape == 'square':
return dimension * dimension
2. Modularization: Use functions and classes to reduce repetition.
3. Apply the DRY Principle: "Don't Repeat Yourself" – avoid duplicating information or logic in your code.
4. Use Tools: Tools like SonarQube or CodeClimate can automatically detect duplicate code.
Reducing duplicate code improves code quality, simplifies maintenance, and minimizes the risk of bugs in the software.
A/B testing is a method used in marketing, web design, and software development to compare two or more versions of an element to determine which one performs better.
Splitting the audience: The audience is divided into two (or more) groups. One group (Group A) sees the original version (control), while the other group (Group B) sees an alternative version (variation).
Testing changes: Only one specific variable is changed, such as a button color, headline, price, or layout.
Measuring results: User behavior is analyzed, such as click rates, conversion rates, or time spent. The goal is to identify which version yields better results.
Data analysis: Results are statistically evaluated to ensure that the differences are significant and not due to chance.
PSR-12 is a coding style guideline defined by the PHP-FIG (PHP Framework Interoperability Group). It builds on PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide), extending them to include modern practices and requirements.
PSR-12 aims to establish a consistent and readable code style for PHP projects, facilitating collaboration between developers and maintaining a uniform codebase.
namespace
declaration.use
statements should follow the namespace
declaration.namespace App\Controller;
use App\Service\MyService;
use Psr\Log\LoggerInterface;
{
for a class or method must be placed on the next line.public
, protected
, private
) is mandatory for all methods and properties.class MyClass
{
private string $property;
public function myMethod(): void
{
// code
}
}
public function myFunction(
int $param1,
string $param2
): string {
return 'example';
}
{
must be on the same line as the control structure.if ($condition) {
// code
} elseif ($otherCondition) {
// code
} else {
// code
}
[]
) for arrays.$array = [
'first' => 'value1',
'second' => 'value2',
];
?
.public function getValue(?int $id): ?string
{
return $id !== null ? (string) $id : null;
}
<?php
tag and must not include a closing ?>
tag.PSR-12 extends PSR-2 by:
PSR-12 is the standard for modern and consistent PHP code. It improves code quality and simplifies collaboration, especially in team environments. Tools like PHP_CodeSniffer
or PHP-CS-Fixer
can help ensure adherence to PSR-12 effortlessly.
PSR-3 is a PHP-FIG (PHP Framework Interoperability Group) recommendation that establishes a standardized interface for logging libraries in PHP applications. This interface defines methods and rules that allow developers to work with logs consistently across different frameworks and libraries, making it easier to replace or change logging libraries within a project without changing the codebase that calls the logger.
Standardized Logger Interface: PSR-3 defines a Psr\Log\LoggerInterface
with a set of methods corresponding to different log levels, such as emergency()
, alert()
, critical()
, error()
, warning()
, notice()
, info()
, and debug()
.
Log Levels: The standard specifies eight log levels (emergency, alert, critical, error, warning, notice, info, and debug), which follow an escalating level of severity. These are based on the widely used RFC 5424 Syslog protocol, ensuring compatibility with many logging systems.
Message Interpolation: PSR-3 includes a basic formatting mechanism known as message interpolation, where placeholders (like {placeholder}
) within log messages are replaced with actual values. For instance:$logger->error("User {username} not found", ['username' => 'johndoe']);
This allows for consistent, readable logs without requiring complex string manipulation.
Flexible Implementation: Any logging library that implements LoggerInterface
can be used in PSR-3 compatible code, such as Monolog, which is widely used in the PHP ecosystem.
Error Handling: PSR-3 also allows the log()
method to be used to log at any severity level dynamically, by passing the severity level as a parameter.
Here’s a basic example of how a PSR-3 compliant logger might be used:
use Psr\Log\LoggerInterface;
class UserService
{
private $logger;
public function __construct(LoggerInterface $logger)
{
$this->logger = $logger;
}
public function findUser($username)
{
$this->logger->info("Searching for user {username}", ['username' => $username]);
// ...
}
}
For more details, you can check the official PHP-FIG documentation for PSR-3.
PSR-1 is a PHP Standards Recommendation created by the PHP-FIG (Framework Interop Group) that defines basic coding standards for PHP code style and structure to ensure interoperability between different PHP projects and frameworks. Its main purpose is to establish a consistent baseline for PHP code, making it easier to understand and collaborate on projects across the PHP ecosystem. PSR-1, also known as the Basic Coding Standard, includes several key guidelines:
File Formatting:
<?php
or <?=
tags.Namespace and Class Names:
StudlyCaps
(PascalCase).Constants, Properties, and Method Naming:
CONST_VALUE
).camelCase
.Autoloading:
include
or require
statements.PSR-1 is considered a foundational standard, and it works in tandem with PSR-2 and PSR-12, which define more detailed code formatting guidelines. Together, these standards help improve code readability and consistency across PHP projects.
PHP Mess Detector (PHPMD) is a static analysis tool for PHP that helps detect potential problems in your code. It identifies a wide range of code issues, including:
PHPMD is configurable, allowing you to define custom rules or use predefined rule sets like "unused code" or "naming conventions." It works similarly to PHP_CodeSniffer, but while CodeSniffer focuses more on style and formatting issues, PHPMD is more focused on the logic and structure of the code.
In summary, PHPMD helps ensure code quality and maintainability by pointing out potential "messes" that might otherwise go unnoticed.