In this article, I will share with you how we can create machine learning models using a programming language that you may not think can be used outside Web Development ... PHP. Crazy, right? This won't be a deep dive into machine learning or artificial intelligence—there are plenty of those resources available from more experienced authors. I will just share my own experiences using it, testing it, and playing around with it and seeing how well can perform in a Data Science context. So let's dive in!

⁉️ What is Machine Learning

Let’s start with a short explanation of what Machine Learning (ML) is. Machine learning is a field of computer science that gives computers the ability to learn without being explicitly programmed. In other words, machine learning algorithms can learn from data and improve their performance over time without being explicitly told what to do.

Machine learning is used in a wide variety of applications, including fraud detection, product recommendation, and medical diagnosis. It is also used in many popular web applications, such as Google Search and Netflix.

📃 Types of Machine Learning

Classical machine learning is a type of artificial intelligence that allows computers to learn without being explicitly programmed. It is a data-driven approach to problem-solving, where algorithms are trained on data to improve their performance over time.

There are four main types of machine learning:

• Supervised learning: In supervised learning, the algorithm is trained on labelled data, where each input data point has a known output. The algorithm learns to predict the output for new input data points based on the patterns it has learned from the training data.

• Unsupervised learning: In unsupervised learning, the algorithm is trained on unlabelled data, where the output is unknown. The algorithm learns to find patterns in the data without being explicitly told what to look for.

• Semi-supervised learning: Semi-supervised learning is a hybrid approach that combines supervised and unsupervised learning. The algorithm is trained on a mixture of labelled and unlabelled data.

• Reinforcement learning: In reinforcement learning, the algorithm learns to behave in an environment by trial and error. It is rewarded for taking actions that lead to desired outcomes and penalized for taking actions that lead to undesired outcomes.

The type of machine learning algorithm that is used depends on the type of data that is available and the task that needs to be solved. For example, if you have a dataset of labelled customer reviews, you could use a supervised learning algorithm to predict the sentiment of new customer reviews. If you have a dataset of unlabelled images, you could use an unsupervised learning algorithm to cluster the images into different categories.

However, after doing some research, I came to understand that PHP can also be used for machine learning with the right library. PHP becomes faster and faster with every version that comes out and there are libraries such as Rubix ML or PHP-ml which can be used for machine learning and artificial intelligence.

🔍 Rubix ML Overview

Rubix ML is a free, open-source machine learning library that allows you to build programs that learn from your data using PHP. It provides tools for the entire machine learning life cycle from ETL to training, cross-validation, and production with over 40 supervised and unsupervised learning algorithms.

⁉️ Why to choose Rubix ML?

1. Comprehensive

   Rubix ML provides a wide range of machine learning algorithms, including supervised and unsupervised learning algorithms. It also provides tools for feature selection, model selection, and hyperparameter tuning.

2. Easy to use

   Rubix ML has a developer-friendly API that is easy to learn and use.

3. Powerful

   Rubix ML is a powerful library that can be used to solve complex Machine Learning problems.

4. Open source

   Rubix ML is an open-source library that is free to use and distribute.

🚀 Installation

Install Rubix ML into your project using Composer:

$ composer require rubix/ml

🌸 Iris example dataset

A lightweight introduction to machine learning in Rubix ML using the famous Iris dataset and the K Nearest Neighbors algorithm.

The Iris dataset consists of 50 samples for each of three species of Iris flower – Iris setosa, Iris virginica, and Iris versicolor (pictured below).

Each sample comprises 4 measurements or features - sepal length, sepal width, petal length, and petal width. Our objective is to train a K Nearest Neighbors (KNN) classifier to determine the species of Iris flower from a set of unknown test samples using the Iris dataset. Let's get started!

use Rubix\ML\Datasets\Labeled;
use Rubix\ML\Extractors\NDJSON;

$training = Labeled::fromIterator(new NDJSON('dataset.ndjson'));

Next, we will select 10 random samples from the training dataset to use later for making example predictions and evaluating the model. To ensure that the samples are truly random, we will use the randomize() method on the dataset object to shuffle the data. Then, we will use the take() method to extract the first 10 rows from the shuffled training dataset and place them in a separate dataset object. We do this because we want to test the model on data that it has not been trained on. This will give us a more accurate assessment of the model's performance.

$testing = $dataset->randomize()->take(10);

Next, we'll instantiate the K Nearest Neighbors classifier and choose the value of the k hyper-parameter. KNN is a distance-based algorithm that finds the k closest samples from the training set and predicts the most common label. For example, if we decide k equal to 5, then we may get 4 labels that are Iris setosa and 1 that is Iris virginica.

use Rubix\ML\Classifiers\KNearestNeighbors;

$estimator = new KNearestNeighbors(5);

Now, we're ready to train the learner by calling the train() method with the training set we prepared earlier.

$estimator->train($training);

With the model trained, we can make predictions using the testing data by calling the predict() method on the testing set.

$predictions = $estimator->predict($testing);

We can also verify the accuracy of the predicted data by using metrics scores provided by the library.

use Rubix\ML\CrossValidation\Metrics\Accuracy;

$metric = new Accuracy();

$score = $metric->score($predictions, $testing->labels());

We obtained the following result:

[2023-10-08 17:15:35] INFO: Loading data into memory
[2023-10-08 17:15:35] INFO: Training
[2023-10-08 17:15:35] INFO: Making predictions
[2023-10-08 17:15:35] INFO: Accuracy is 0.9

We computed 90% of correct predictions to the total number of predictions.

We also have regressors. A nice use case is predicting the Housing price.

🏠 Housing Price example dataset

An example project that predicts house prices using a Gradient Boosted Machine (GBM) and a popular dataset from a Kaggle competition.

The data is in two separate CSV files - house-price-labeled.csv which has labels for training and house-price-unlabeled.csv without labels for predicting. Each feature column is denoted by a title in the CSV header which we'll use to identify the column with our Column Picker. Column Picker allows us to select and rearrange the columns of a data table while the data is in flight. It wraps another iterator object such as the built-in CSV extractor. In this case, we don't need the Id column of the dataset in the first extractor because it is uncorrelated with the outcome so we'll only specify the columns we need. But we will get into another extractor to use it latter. When instantiating a new Labeled dataset object via the fromIterator() method, the last column of the data table is taken to be the labels.

use Rubix\ML\Datasets\Labeled;
use Rubix\ML\Extractors\CSV;
use Rubix\ML\Extractors\ColumnPicker;

$extractor = new ColumnPicker(new CSV('house-price-labeled.csv', true), [
    'MSSubClass', 'MSZoning', 'LotFrontage', 'LotArea', 'Street', 'Alley',
    'LotShape', 'LandContour', 'Utilities', 'LotConfig', 'LandSlope',
    'Neighborhood', 'Condition1', 'Condition2', 'BldgType', 'HouseStyle',
    'OverallQual', 'OverallCond', 'YearBuilt', 'YearRemodAdd', 'RoofStyle',
    'RoofMatl', 'Exterior1st', 'Exterior2nd', 'MasVnrType', 'MasVnrArea',
    'ExterQual', 'ExterCond', 'Foundation', 'BsmtQual', 'BsmtCond',
    'BsmtExposure', 'BsmtFinType1', 'BsmtFinSF1', 'BsmtFinType2', 'BsmtFinSF2',
    'BsmtUnfSF', 'TotalBsmtSF', 'Heating', 'HeatingQC', 'CentralAir',
    'Electrical', '1stFlrSF', '2ndFlrSF', 'LowQualFinSF', 'GrLivArea',
    'BsmtFullBath', 'BsmtHalfBath', 'FullBath', 'HalfBath', 'BedroomAbvGr',
    'KitchenAbvGr', 'KitchenQual', 'TotRmsAbvGrd', 'Functional', 'Fireplaces',
    'FireplaceQu', 'GarageType', 'GarageYrBlt', 'GarageFinish', 'GarageCars',
    'GarageArea', 'GarageQual', 'GarageCond', 'PavedDrive', 'WoodDeckSF',
    'OpenPorchSF', 'EnclosedPorch', '3SsnPorch', 'ScreenPorch', 'PoolArea',
    'PoolQC', 'Fence', 'MiscFeature', 'MiscVal', 'MoSold', 'YrSold',
    'SaleType', 'SaleCondition', 'SalePrice',
]);

$idExtractor = new ColumnPicker(new CSV('house-price-labeled.csv', true), ['Id']);

$dataset = Labeled::fromIterator($extractor);

Next, we'll apply a series of transformations to the training set to prepare it for the learner. By default, the CSV Reader imports everything as a string - therefore, we must convert the numerical values to integers and floating point numbers beforehand so they can be recognized by the learner as continuous features. For this case, we can use Numeric String Converter. Since some feature columns contain missing data, we'll also apply the Missing Data Imputer which replaces missing values with a pretty good guess.

Another step will be...transformations!

use Rubix\ML\Transformers\NumericStringConverter;
use Rubix\ML\Transformers\MissingDataImputer;

$dataset->apply(new NumericStringConverter())
    ->apply(new MissingDataImputer())
    ->transformLabels('intval');

Since the labels should also be continuous, we'll apply a separate transformation to the labels using a standard PHP function intval() callback which converts values to integers.
A Gradient Boosted Machine (GBM) is a machine learning algorithm that combines multiple weak learners to form a strong learner. A weak learner is a simple model that can only make slightly better than random predictions. A strong learner is a complex model that can make accurate predictions.

GBMs work by iteratively adding weak learners to the ensemble. At each iteration, the new weak learner is trained to minimize the gradient of the loss function concerning the predictions of the current ensemble. This means that the new weak learner is focused on learning from the errors of the current ensemble.

We can create a GBM learner instance by instantiating Gradient Boost.

use Rubix\ML\Regressors\GradientBoost;
use Rubix\ML\Regressors\RegressionTree;

$estimator = new GradientBoost(new RegressionTree(4), 0.1);

The first two hyper-parameters of Gradient Boost are the booster's settings and the learning rate. For this example, we'll use a standard Regression Tree, but can be used any Learner available, with a maximum depth of 4 as the booster and a learning rate of 0.1.

Now, we're ready to train the learner by calling the train() method with the training dataset as an argument. As we did before...

$estimator->train($dataset);

We will output the progress for each epoch:

2023-10-19 17:56:30] INFO: Training Gradient Boost (booster: Regression Tree (max height: 4, max leaf size: 3, max features: null, min purity increase: 1.0E-7, max bins: null), rate: 0.1, ratio: 0.5, epochs: 1000, min change: 0.0001, window: 5, hold out: 0.1, metric: RMSE)
[2023-10-19 17:56:30] INFO: Epoch: 1, L2 Loss: 6436384156.2221, Loss Change: ↓INF, RMSE: -71708.764286891
[2023-10-19 17:56:30] INFO: Epoch: 2, L2 Loss: 5630242565.7001, Loss Change: ↓806141590.52197, RMSE: -66407.137811077
[2023-10-19 17:56:31] INFO: Epoch: 3, L2 Loss: 4770622503.1757, Loss Change: ↓859620062.52446, RMSE: -61971.853448989
[2023-10-19 17:56:31] INFO: Epoch: 4, L2 Loss: 4043008935.4127, Loss Change: ↓727613567.76301, RMSE: -57810.401653993
[2023-10-19 17:56:31] INFO: Epoch: 5, L2 Loss: 3386871864.078, Loss Change: ↓656137071.3347, RMSE: -52869.658027195
[2023-10-19 17:56:31] INFO: Epoch: 6, L2 Loss: 2881408466.9165, Loss Change: ↓505463397.16143, RMSE: -49126.644816384
[2023-10-19 17:56:31] INFO: Epoch: 7, L2 Loss: 2463658494.2966, Loss Change: ↓417749972.61996, RMSE: -46003.262222827
[2023-10-19 17:56:31] INFO: Epoch: 8, L2 Loss: 2108573957.896, Loss Change: ↓355084536.40055, RMSE: -43538.115210196
[2023-10-19 17:56:32] INFO: Epoch: 9, L2 Loss: 1838640861.0124, Loss Change: ↓269933096.8836, RMSE: -41170.475905339
[2023-10-19 17:56:32] INFO: Epoch: 10, L2 Loss: 1597249748.4343, Loss Change: ↓241391112.57807, RMSE: -39078.526587176
[2023-10-19 17:56:32] INFO: Epoch: 11, L2 Loss: 1377364288.7838, Loss Change: ↓219885459.65057, RMSE: -36556.015988622
[2023-10-19 17:56:32] INFO: Epoch: 12, L2 Loss: 1220782616.4792, Loss Change: ↓156581672.30458, RMSE: -35054.973980198
[2023-10-19 17:56:32] INFO: Epoch: 13, L2 Loss: 1083909422.4105, Loss Change: ↓136873194.06866, RMSE: -33642.037883807
[2023-10-19 17:56:32] INFO: Epoch: 14, L2 Loss: 976162100.86812, Loss Change: ↓107747321.54242, RMSE: -32753.024359858
[2023-10-19 17:56:33] INFO: Epoch: 15, L2 Loss: 877908777.47182, Loss Change: ↓98253323.396307, RMSE: -31491.748610261
[2023-10-19 17:56:33] INFO: Epoch: 16, L2 Loss: 812525758.20675, Loss Change: ↓65383019.26507, RMSE: -30794.105388278
[2023-10-19 17:56:33] INFO: Epoch: 17, L2 Loss: 742968087.22223, Loss Change: ↓69557670.984522, RMSE: -29889.285010238
[2023-10-19 17:56:33] INFO: Epoch: 18, L2 Loss: 684773684.74305, Loss Change: ↓58194402.479171, RMSE: -29883.999471749
[2023-10-19 17:56:33] INFO: Epoch: 19, L2 Loss: 644918395.24951, Loss Change: ↓39855289.49354, RMSE: -29269.832098457
[2023-10-19 17:56:34] INFO: Epoch: 20, L2 Loss: 607709730.21106, Loss Change: ↓37208665.038457, RMSE: -29067.257462084
[2023-10-19 17:56:34] INFO: Epoch: 21, L2 Loss: 581257898.46296, Loss Change: ↓26451831.748101, RMSE: -28814.753357758
[2023-10-19 17:56:34] INFO: Epoch: 22, L2 Loss: 552260769.5807, Loss Change: ↓28997128.882253, RMSE: -28616.458759402
[2023-10-19 17:56:34] INFO: Epoch: 23, L2 Loss: 528735705.56274, Loss Change: ↓23525064.017968, RMSE: -28542.151094341
[2023-10-19 17:56:34] INFO: Epoch: 24, L2 Loss: 500014462.23253, Loss Change: ↓28721243.330209, RMSE: -28085.448905534
[2023-10-19 17:56:35] INFO: Epoch: 25, L2 Loss: 486252300.75998, Loss Change: ↓13762161.472549, RMSE: -27955.365091657
[2023-10-19 17:56:35] INFO: Epoch: 26, L2 Loss: 471179557.08196, Loss Change: ↓15072743.678016, RMSE: -27541.67537264
[2023-10-19 17:56:35] INFO: Epoch: 27, L2 Loss: 456869450.78453, Loss Change: ↓14310106.297434, RMSE: -27610.582905963
[2023-10-19 17:56:35] INFO: Epoch: 28, L2 Loss: 444041161.13959, Loss Change: ↓12828289.644939, RMSE: -27485.426923627
[2023-10-19 17:56:35] INFO: Epoch: 29, L2 Loss: 427145836.58761, Loss Change: ↓16895324.551974, RMSE: -27344.733854838
[2023-10-19 17:56:36] INFO: Epoch: 30, L2 Loss: 416259219.30291, Loss Change: ↓10886617.284702, RMSE: -27218.292857536
[2023-10-19 17:56:36] INFO: Epoch: 31, L2 Loss: 404938178.83119, Loss Change: ↓11321040.471723, RMSE: -27411.143265803
[2023-10-19 17:56:36] INFO: Epoch: 32, L2 Loss: 395135112.16554, Loss Change: ↓9803066.6656482, RMSE: -27324.247250815
[2023-10-19 17:56:36] INFO: Epoch: 33, L2 Loss: 384453056.68525, Loss Change: ↓10682055.480296, RMSE: -27152.817531035
[2023-10-19 17:56:36] INFO: Epoch: 34, L2 Loss: 379789135.84006, Loss Change: ↓4663920.8451867, RMSE: -27269.680926672
[2023-10-19 17:56:37] INFO: Epoch: 35, L2 Loss: 370961571.07631, Loss Change: ↓8827564.7637495, RMSE: -27157.25989971
[2023-10-19 17:56:37] INFO: Epoch: 36, L2 Loss: 365542631.05462, Loss Change: ↓5418940.0216874, RMSE: -27165.776720778
[2023-10-19 17:56:37] INFO: Epoch: 37, L2 Loss: 360459872.10913, Loss Change: ↓5082758.9454899, RMSE: -27131.32879548
[2023-10-19 17:56:37] INFO: Epoch: 38, L2 Loss: 350958599.22501, Loss Change: ↓9501272.8841182, RMSE: -26961.769954788
[2023-10-19 17:56:37] INFO: Epoch: 39, L2 Loss: 348819400.64492, Loss Change: ↓2139198.5800916, RMSE: -26906.291474111
[2023-10-19 17:56:37] INFO: Epoch: 40, L2 Loss: 343310542.18563, Loss Change: ↓5508858.4592963, RMSE: -26861.164591495
[2023-10-19 17:56:38] INFO: Epoch: 41, L2 Loss: 339369923.15262, Loss Change: ↓3940619.0330026, RMSE: -26796.865049005
[2023-10-19 17:56:38] INFO: Epoch: 42, L2 Loss: 334218230.52533, Loss Change: ↓5151692.6272951, RMSE: -26683.211520229
[2023-10-19 17:56:38] INFO: Epoch: 43, L2 Loss: 329859710.99604, Loss Change: ↓4358519.5292879, RMSE: -26473.740677573
[2023-10-19 17:56:38] INFO: Epoch: 44, L2 Loss: 324846295.37684, Loss Change: ↓5013415.619204, RMSE: -26255.345766531
[2023-10-19 17:56:38] INFO: Epoch: 45, L2 Loss: 317414799.99782, Loss Change: ↓7431495.379018, RMSE: -26234.191216171
[2023-10-19 17:56:39] INFO: Epoch: 46, L2 Loss: 311649575.38238, Loss Change: ↓5765224.6154344, RMSE: -26182.272643805
[2023-10-19 17:56:39] INFO: Epoch: 47, L2 Loss: 307952526.91157, Loss Change: ↓3697048.470809, RMSE: -26129.674044143
[2023-10-19 17:56:39] INFO: Epoch: 48, L2 Loss: 300672369.44642, Loss Change: ↓7280157.4651565, RMSE: -25988.23966495
[2023-10-19 17:56:39] INFO: Epoch: 49, L2 Loss: 297869431.07494, Loss Change: ↓2802938.3714737, RMSE: -26023.519200172
[2023-10-19 17:56:39] INFO: Epoch: 50, L2 Loss: 293476541.42341, Loss Change: ↓4392889.6515364, RMSE: -26046.382216165
[2023-10-19 17:56:40] INFO: Epoch: 51, L2 Loss: 290400510.78881, Loss Change: ↓3076030.6345947, RMSE: -25984.784412911
[2023-10-19 17:56:40] INFO: Epoch: 52, L2 Loss: 285575907.04241, Loss Change: ↓4824603.7464082, RMSE: -26005.007942422
[2023-10-19 17:56:40] INFO: Epoch: 53, L2 Loss: 280953745.41581, Loss Change: ↓4622161.626599, RMSE: -26143.27895326
[2023-10-19 17:56:40] INFO: Epoch: 54, L2 Loss: 277628568.90542, Loss Change: ↓3325176.510388, RMSE: -26206.483797568
[2023-10-19 17:56:40] INFO: Epoch: 55, L2 Loss: 273730914.82035, Loss Change: ↓3897654.0850713, RMSE: -26140.948991003
[2023-10-19 17:56:41] INFO: Epoch: 56, L2 Loss: 268587011.86472, Loss Change: ↓5143902.9556223, RMSE: -26051.624836158
[2023-10-19 17:56:41] INFO: Model state restored to epoch 51
[2023-10-19 17:56:41] INFO: Training complete

During training, the learner records the validation score and the training loss at each iteration or epoch. The validation score is calculated using the default RMSE metric on a hold-out portion of the training set. Contrariwise, the training loss is the value of the cost function (in this case the L2 or quadratic loss) computed over the training data.

Rubix ML also provides us with some features to visualize the training progress by plotting these metrics. To output the scores and losses you can call the additional steps() method on the learner instance. Then we can export the data to a CSV file by exporting the iterator returned by steps() to a CSV file.

use Rubix\ML\Extractors\CSV;

$extractor = new CSV('progress.csv', true);

$extractor->export($estimator->steps());

We can also save the trained model to use later! To do this, we need to wrap the learner into a PersistentModel class.

use Rubix\ML\PersistentModel;
use Rubix\ML\Regressors\GradientBoost;
use Rubix\ML\Regressors\RegressionTree;
use Rubix\ML\Persisters\Filesystem;

$estimator = new PersistentModel(
    new GradientBoost(new RegressionTree(4), 0.1),
    new Filesystem('housing.rbx', true)
);

After that, you can call save() method.

$estimator->save();

Now we're ready to execute the training script by calling it from the command line.

php .\rubix-ml-cli train:house-price-predictor

Our goal is to predict the correct sale prices of each house given a list of unknown samples. We'll start by importing the unlabeled samples from the house-price-unlabeled.csv file.

use Rubix\ML\Datasets\Unlabeled;
use Rubix\ML\Extractors\CSV;
use Rubix\ML\Transformers\NumericStringConverter;

$dataset = Unlabeled::fromIterator(new CSV('house-price-unlabeled.csv', true))
    ->apply(new NumericStringConverter());

Now, let's load the persisted Gradient Boost estimator built in the last step, into our script using the static load() method on the Persistent Model class by passing it a Persister instance pointing to the model in storage.

use Rubix\ML\PersistentModel;
use Rubix\ML\Persisters\Filesystem;

$estimator = PersistentModel::load(new Filesystem('housing.rbx'));

To obtain the predictions from the model, call the predict() method with the dataset containing the unknown samples.

$predictions = $estimator->predict($dataset);

Then we'll use the CSV extractor to export the IDs and predictions to a file that we'll submit to the competition.

use Rubix\ML\Extractors\ColumnPicker;
use Rubix\ML\Extractors\CSV;


$ids = array_column(iterator_to_array($extractor), 'Id');

array_unshift($ids, 'Id');
array_unshift($predictions, 'SalePrice');

$extractor = new CSV('predictions.csv');

$extractor->export(array_transpose([$ids, $predictions]));

$ php .\rubix-ml-cli load:house-price-predictor housing.rbx

Now you can also submit the predictions with their IDs to the contest page to see how well you did. 😊

Have a look at the Gradient Boost documentation page to get a better sense of what the learner can do. Try tuning the hyper-parameters for better results. Consider filtering out noise samples from the dataset by using methods on the dataset object. For example, you may want to remove extremely large and expensive houses from the training set.

📏 Tokenizers

The job of a tokenizer is to break up a stream of text into tokens, where each token is (usually) a sub-sequence of the characters in the text. We have plenty of them!

Word Stemmer

Word Stemmer reduces inflected and derived words to their root form using the Snowball method. For example, the sentence "Majority voting is likely foolish" stems from "Major vote is like foolish."

use Rubix\ML\Tokenizers\WordStemmer;

$tokenizer = new WordStemmer('english');

Word Tokenizer

The Word tokenizer uses a regular expression to tokenize the words in a blob of text.

use Rubix\ML\Tokenizers\Word;

$tokenizer = new Word();

Whitespace Tokenizer

Tokens are delimited by a user-specified whitespace character.

use Rubix\ML\Tokenizers\Whitespace;

$tokenizer = new Whitespace(',');

Sentence Tokenizer

This tokenizer matches sentences starting with a letter and ending with a punctuation mark.

use Rubix\ML\Tokenizers\Sentence;

$tokenizer = new Sentence();

N-gram Tokenizer

N-grams are sequences of n-words of a given string. The N-gram tokenizer outputs tokens of contiguous words ranging from min to max number of words per token.

use Rubix\ML\Tokenizers\NGram;

$tokenizer = new NGram(1, 3);

K-Skip-N-Gram Tokenizer

K-skip-n-grams are a technique similar to n-grams, whereby n-grams are formed but in addition to allowing adjacent sequences of words, the next k words will be skipped forming n-grams of the new forward-looking sequences. The tokenizer outputs tokens ranging from min to max number of words per token.

use Rubix\ML\Tokenizers\KSkipNGram;

$tokenizer = new KSkipNGram(2, 3, 2);

🤗 Thank you for reading!

Thank you for sticking with me until the end. I hope you will benefit from this article and incorporate PHP into your Machine Learning experiments.

📕References

Rubix ML

Kaggle Competition

Repository

Ensuring optimal database performance is crucial for enterprise applications, but achieving it can be a challenging task. When it comes to relational databases, specifically those using SQL, improving performance might be more straightforward than you might think. While numerous factors can influence SQL database performance, this article will focus on one of the most common and impactful optimization techniques used right now to enhance database query operations…table indexes.

Indexes are special lookup tables that need to be used by the database search engine to speed up data retrieval. An index is simply a reference to data in a table. A database index is similar to the index in the back of a journal. It cannot be viewed by the users and just used to speed up the database access.

But most of the time, when we are considering creating indexes, we tend to only look at the column index part. This is not bad, because it is always good to add an index to your columns, but there is also another approach to adding indexes, another type of index.

Let's talk about Functional Indexes!

⁉️ What are functional key parts?

A functional index is an index in a database that is based on the result of a function applied to one or more columns of a table. Functional key parts can index expression values. Hence, functional key parts enable indexing values that are not stored directly in the table itself.

The theory behind SQL functional indexes is the same. When the database is executing a query, it uses the relevant index like a pointer, enabling it to read only the relevant rows of data to find the information you’re searching for, instead of having to read the entire table.

⁉️ When are functional indexes helpful?​​

Functional indexes are helpful when the query retrieves data based on the result of a function. It can be useful when the function requires high computational power to execute.

In our examples, we will use functional indexes to increase performance in an SQLite database.

Common use cases for functional indexes in SQLite include case-insensitive searching, date calculations, and full-text search. However, functional indexes in SQLite have some limitations, such as the function used in the index must be deterministic and must always return the same result for the same input.

Syntax

Let's run a simple query to find all film titles in lowercase from movies database.

SELECT lower(title) FROM film;

If we run an explain operation on this query, we will get the following result:

EXPLAIN QUERY PLAN SELECT lower(title) FROM film;

As we can see from the details, the query is executing a scan of all films from film table.

Here is how you can define functional indexes in a film table to search for lowercase film titles:

CREATE INDEX lower_movie_title ON movie (lower(title));

Now, if we run the same explain query:

EXPLAIN QUERY PLAN SELECT lower(title) FROM film;

We will get…

Awesome! Our query has made use of the index to retrieve the results.

Once you create an index, queries should run much faster because the database will use the index to find the data it needs instead of scanning the entire table. This means that the database has to read less data from the disk and process fewer rows, which speeds up the query.

Functional indexes can improve the performance of some queries, but they can also make it slower to insert or update data in the table because the index needs to be updated every time the table is changed. This can slow down applications that write a lot of data, so use functional indexes carefully.

📕 References

Great video from Planetscale: Increase SQL performance with this technique (10 examples)

Laravel Prompts is a PHP package for adding beautiful and user-friendly forms to your command-line applications, with browser-like features including placeholder text and validation. It is perfect for accepting user input in your Artisan console commands, but it may also be used in any command-line PHP project.

Laravel Prompts was introduced by Jess Archer at Laracon US on July 19, 2023, and is now a built-in part of the framework. It is easy to use and can be added to your existing Artisan commands with just a few lines of code.

🚀 Installation

Laravel Prompts only requires the package to be installed. There’s no configuration file or service provider to publish.

composer require laravel/prompts

By installing using Composer, we can start building prompts for your Artisan commands.

🔨 Basic usages

If you've ever created your own Artisan commands, you'll see how easy it is to use Laravel Prompts.

Let's create a new command for this tutorial:

php artisan make:command MakeCoffeeCommand

In the old way of writing Artisan commands, we would write like this example:

namespace App\Console\Commands;

use App\Models\Coffee;
use Illuminate\Console\Command;

class MakeCoffeeCommand extends Command
{
    protected $signature = 'make:coffee';

    protected $description = 'Make some delicious coffee ☕';

    public function handle()
    {
        $name = $this->ask('What type of coffee would you like? (espresso, drip, etc.)');

        …
    }
}

You can use the functions Laravel Prompts provides and enjoy an improved output:

namespace App\Console\Commands;

use App\Models\Coffee;
use Illuminate\Console\Command;
use function Laravel\Prompts\text;

class MakeCoffeeCommand extends Command
{
    protected $signature = 'make:coffee';

    protected $description = 'Make some delicious coffee ☕';

    public function handle()
    {
        $coffeeType = text('What type of coffee would you like? (espresso, drip, etc.)');

        Coffee::create(compact('coffeeType'));

        $this->info("We made for you some $name coffee!");
    }
}

Here’s a screenshot of the command in action.

📍 Multi-select support

Let’s go even further and add type selection:

$types = multiselect(
    label: 'What type of coffee would you like',
    options: [
        'Light roast', 
        'Medium roast', 
        'Dark roast', 
        'French roast', 
        'Italian roast',
        'Espresso roast'
    ],
    scroll: 6,
    required: true,
    validate: function (array $values) {
        return ! in_array(count($values), [1, 2])
            ? 'A maximum of two roast levels can be assigned to make coffee.'
            : null;
    }
);

• Have the 6 possible roast types as options.

• The prompt is required to have an answer.

• We display 6 choices at once.

• We ensure that 1 or 2 types can be assigned.

• We leverage PHP’s named arguments to keep our code informative and omit some arguments.

Here’s how the refreshed Artisan command using Laravel Prompts looks:

📍 Searching for elements

Laravel Prompts allows you to have a lot of options for the entity to select from, the search function allows the user to type a search query to filter the results before using the arrow keys to select an option:

use function Laravel\Prompts\search;

$name = search(
    'Search for coffee type...',
    fn (string $coffeeType) => strlen($coffeeType) > 0
        ? Coffee::where('name', 'like', "%{$coffeeType}%")->pluck('name')->all()
        : []
);

Cool, right?!

📍 Adding a loading animation (spinner)

Laravel Prompts lets you use a beautiful loading animation, effortlessly. Just as with the rest of the API, it’s as simple as calling the spin() function. It serves to indicate ongoing processes and returns the callback's results upon completion:

use function Laravel\Prompts\spin;

$response = spin(
    fn () => Http::get('http://coffees.com'),
    'Fetching coffees...'
);

The spin function needs the pcntl PHP extension to work. If you don't have it, you'll see a static spinner instead.

Now that you know the basics of Laravel Prompts, you can read the easy-to-understand documentation to learn more.

🤔 Contribute to Laravel Prompts

If you find a bug or think Laravel Prompts needs a new feature, you can send a pull request to the official repository: https://github.com/laravel/prompts

Air Quality CLI is a small CLI tool that is powered by air-quality PHP package. I launched a new open source project called Air Quality CLI, which allows you to get real-time air quality data directly from your terminal. With this tool, you can easily monitor the air quality values like grass pollen, birch pollen, dust, etc., in your area and make informed decisions about your health and well-being.

The project is built on top of my Air Quality library, which provides a simple and reliable API for accessing air quality data from OpenMeteo API. With just a few lines of code, you can retrieve pollution levels, AQI values, and other important air quality metrics.

🚀 Installation

Requirements:

• Composer installed

To install, do:

composer global require mihaichris/air-quality-cli

This command will install the command globally for the Composer and can be called anywhere from the terminal.

💡 Features

Air Quality CLI encapsulates many awesome features, like:

• Getting current air quality information for a specific location, based on coordinates;

• Getting air quality between specific dates;

• Getting air quality from the past days;

• Getting forecast air quality, and also filtering based on the pollutants that you are interested in;

  And more are coming on the road!

🔨 Basic Usage

A simple command for getting all current pollutants from Bucharest.

air-quality.bat current latitude=44.38 longitude=26.14

This command will print something like this:

Running the above command will return a list of the number of pollutants and pollen listed on OpenMeteo website alongside their index values.

📍 Get air quality between two dates

This command will list the pollutants from Bucharest between two dates given as parameters.

air-quality.bat between latitude=44.38 longitude=26.14 start_date=2023-05-26 end_date=2023-05-27

Adding no filter to the command will output the values for all the pollutants.

Let's see another example for getting the pollutants between dates, but now we will give another parameter, variables which filter the pollutants by the variables you want to output.

air-quality.bat between latitude=44.38 longitude=26.14 start_date=2023-08-22 end_date=2023-08-23 variables=ozone,grass_pollen

If you don't know what variables are available, you can run the following command to get all the variables that can be passed as a filter:

air-quality.bat variables

Easy, right?

📍 Get air quality forecast

One of the most significant features that makes this application useful is the ability to get the future air quality from a certain location. Right now, the forecast is provided for a maximum of 5 days in the feature.

air-quality.bat next days=2 variables=grass_pollen latitude=44.38 longitude=26.14

The CLI is still in development, with more new features on the road. The initial idea of the project was for personal use, but I thought it will also be useful for others. 😀

🤔 Contribute to Air Quality CLI

If you ever encounter a bug or feel like Air Quality CLI needs one more feature, you can send your pull requests directly to the official repository: https://github.com/mihaichris/air-quality-cli

🎉 Prepare to embark on a thought-provoking exploration of this cutting-edge technique and discover how it can revolutionize your approach to software quality assurance. So without further ado, let us dive into the depths of mutation testing and unlock its hidden potential.

🔍Overview

Mutation testing is a technique that involves introducing deliberate bugs or “mutations” into the software code to identify weak tests or code. It offers a high level of error detection and can identify hidden defects that other testing methods cannot. The process provides concrete suggestions for additional testing and helps to identify flaws in designs that were not previously considered. The big benefit of mutation testing is that it helps to ensure the quality of code by detecting problematic bugs that are difficult to find with traditional testing methods.

Is a test set evaluation technique for a program (having a set of tests generated, we can evaluate how effective it is, based on the results obtained by this test on the mutants of the program).

💻 Example

Let's have a look at this code sample where we read the x and y variables and based on their values we write a specific compute:

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        if (x > 0) {
            write(x + y);
        } else {
            write(x * y);
        }
    }

    public static void write(int value) {
        //...
    }

    public static void read(int x, int y) {
        //...
    }
}

And here we have the same code with a mutation applied:

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        if (x >= 0) {
            write(x + y);
        } else {
            write(x * y);
        }
    }

    public static void write(int value) {
        //...
    }

    public static void read(int x, int y) {
        //...
    }
}

The mutation is a single alteration in the if condition of the main method. In the original code, the condition is if (x > 0), and in the mutated code, it has been changed to if (x >= 0). The modification here is to replace the strict greater-than-comparison (>) with a greater-than-or-equal-to comparison (>=).

And what is the explanation...? 🤔

By making this simple change, the behaviour of the program can potentially be affected. In the original code, the write method is called only when x is greater than 0, and otherwise, the write method with the multiplication of x and y is called. However, in the mutated code, the write method with the addition of x and y will be called when x is greater than or equal to 0.

Now, during mutation testing, the test suite will be executed against this mutated version of the MutationExample class. If the test suite fails to detect this artificial fault introduced by the mutation (i.e., it passes successfully), it indicates that the tests may have insufficient coverage or are not sensitive enough to this particular mutation. On the other hand, if the test suite fails, it means the tests are effective in detecting the mutation, demonstrating their ability to identify faults and validating the quality of the test suite.

🚙 Utility of mutation testing

Evaluating Test Suite Effectiveness:

Mutation testing helps gauge the ability of a test suite to detect faults or errors in the code.

Suppose you have a test suite for a sorting algorithm (selection sort). By applying mutation testing, you introduce a mutation that swaps two elements incorrectly. If the test suite successfully detects this mutation, it indicates the effectiveness of the tests in identifying faults and ensuring correct sorting.

// Original code
public boolean isSorted(int[] array) {
    for (int i = 0; i < array.length - 1; i++)  {  
            int index = i;  
            for (int j = i + 1; j < array.length; j++){  
                if (array[j] < array[index]){  
                    index = j; 
                }  
            }  
            int smallerNumber = arr[index];   
            array[index] = array[i];  
            array[i] = smallerNumber;  
        }  
}

// Mutation: Swapping two elements incorrectly
public boolean isSorted(int[] array) {
   for (int i = 0; i < array.length - 1; i++)  {  
            int index = i;  
            for (int j = i - 1; j < array.length; j++){  
                if (array[j] < array[index]){  
                    index = j; 
                }  
            }  
            int smallerNumber = arr[index];   
            array[index] = array[i];  
            array[i] = smallerNumber;  
        }  
}

@Test
public void testIsSorted() {
    int[] array = {1, 2, 3};
    assertTrue(isSorted(array)); // Original code passes the test
    assertFalse(isSorted(array)); // Mutation fails the test, indicating effective fault detection
}

Fault Localization

When a mutation is not detected by the test suite, mutation testing helps identify potential weaknesses in the test cases or areas of the code that may lack appropriate test coverage. This allows developers to focus their efforts on improving specific test cases or adding new ones to enhance fault detection and localization.

During mutation testing, if a specific mutation goes undetected by the test suite, you can analyze which test cases failed to identify the fault. This helps pinpoint weaknesses in the test suite, allowing you to add targeted test cases or improve existing ones to enhance fault localization.

// Original code
public int divide(int a, int b) {
    return a / b;
}

// Mutation: Incorrect operation
public int divide(int a, int b) {
    return a * b;
}

@Test
public void testDivide() {
    assertEquals(2, divide(10, 5)); // Original code passes the test
    assertEquals(2, divide(10, 5)); // Mutation passes the test, indicating a potential weakness in the test suite
}

Quality Assurance and Code Quality Improvement

By identifying areas of the code that are not adequately covered by tests, mutation testing helps improve the overall quality of the software. It encourages the development of more robust and comprehensive test suites, leading to higher-quality code and reduced likelihood of undetected faults in production.

Imagine you are developing a calculator application. By performing mutation testing, you introduce a mutation that alters the logic for multiplication. If the test suite detects this mutation, it highlights the need for improved code quality and reinforces the importance of comprehensive testing.

// Original code
public int multiply(int a, int b) {
    return a * b;
}

// Mutation: Faulty multiplication logic
public int multiply(int a, int b) {
    return a - b;
}

@Test
public void testMultiply() {
    assertEquals(20, multiply(4, 5)); // Original code passes the test
    assertEquals(-1, multiply(1, 1)); // Mutation fails the test, highlighting the need for improved code quality
}

Identifying Weaknesses in Design and Specifications

Mutation testing can reveal flaws in the software's design or specifications that were not initially considered. By exploring different scenarios and potential code modifications, mutation testing helps expose vulnerabilities and can guide improvements in the design and requirements.

Suppose you have a test suite for a banking application. Through mutation testing, you introduce a mutation that modifies the interest calculation formula. If the test suite fails to identify this mutation, it suggests flaws in the design or specifications, indicating the need for reevaluation and potential adjustments.

// Original code
public double calculateInterest(double principal, double rate, int years) {
    return principal * rate * years;
}

// Mutation: Incorrect interest calculation formula
public double calculateInterest(double principal, double rate, int years) {
    return principal + (principal * rate * years);
}

@Test
public void testCalculateInterest() {
    assertEquals(500, calculateInterest(1000, 0.05, 10)); // Original code passes the test
    assertEquals(1500, calculateInterest(1000, 0.05, 10)); // Mutation fails the test, indicating a potential flaw in design or specification
}

Confidence in Software Reliability

Through mutation testing, developers and stakeholders gain greater confidence in the reliability and resilience of the software. By demonstrating the ability of the test suite to detect artificial faults, mutation testing contributes to a higher level of assurance that the software can handle real-world scenarios and potential issues.

By using mutation testing, you introduce mutations that simulate exceptional scenarios, such as invalid inputs or edge cases. If the test suite successfully detects these mutations, it instils confidence in the software's reliability and resilience to handle unexpected situations.

// Original code
public int divide(int a, int b) {
    return a / b;
}

// Mutation: Division by zero
public int divide(int a, int b) {
    return a / 0;
}

@Test
public void testDivide() {
    assertEquals(2, divide(10, 5)); // Original code passes the test
    assertThrows(ArithmeticException.class, () -> divide(10, 0)); // Mutation throws an exception, confirming software resilience and confidence
}

Continuous Integration and Regression Testing

Mutation testing can be integrated into the continuous integration (CI) process, allowing developers to automatically run mutation tests alongside other automated tests. This helps identify regressions and ensure that code modifications do not inadvertently introduce new faults or weaken the existing test coverage.

➗Mutation operators

Mutation operator = The rule that applies to a program to create mutants;

Many mutation operators have been explored by researchers. Here are some examples of mutation operators for imperative languages:

• Statement deletion;

• Statement duplication or insertion, e.g. goto fail;

• Replacement of boolean subexpressions with true and false;

• Replacement of some arithmetic operations with others, e.g. + with *, - with / ;

• Replacement of some boolean relations with others, e.g. > with >=, == and <= ;

• Replacement of variables with others from the same scope (variable types must be compatible);

• Remove the method body;

These mutation operators are also called traditional mutation operators. There are also mutation operators for object-oriented languages, concurrent constructions, complex objects like containers, etc. Operators for containers are called class-level mutation operators. For example, the muJava tool offers various class-level mutation operators such as Access Modifier Change, Type Cast Operator Insertion, and Type Cast Operator Deletion. Mutation operators have also been developed to perform security vulnerability testing of programs.

🤔Mutation Testing Technique

Mutation testing employs several steps to evaluate the effectiveness of a test suite in detecting artificial faults introduced through code mutations. Here are the key techniques used in mutation testing:

Mutant Generation:

In this technique, a set of mutants (modified versions) of the original code is generated by applying various mutation operators. Each mutant represents a specific artificial fault, created by altering the code in a predefined way.

Test Suite Execution:

The generated mutants are subjected to the test suite execution. The test suite consists of a collection of test cases designed to validate the correctness and robustness of the software.

Mutation Score:

The mutation score is a metric that quantifies the effectiveness of the test suite in detecting mutations. It is calculated by determining the percentage of mutants that are killed (i.e., detected as faulty) by the test suite. A higher mutation score indicates a more comprehensive and effective test suite.

Equivalent Mutants:

Equivalent mutants are mutations that do not alter the program's behaviour or result in observable changes. These mutants are typically excluded from the evaluation process, as they do not contribute to assessing the quality of the test suite.

Surviving Mutants:

Surviving mutants are the mutations that are not detected by the test suite, meaning the corresponding faults are not identified. These surviving mutants indicate weaknesses in the test suite and highlight areas where additional test cases or improvements are required.

Test Case Effectiveness:

During mutation testing, the focus is on assessing the effectiveness of individual test cases in detecting mutations. Test cases that are successful in killing mutants are considered valuable and contribute to the overall mutation score.

Mutation Operators:

Mutation operators are specific rules or patterns used to modify the code and create mutants. These operators define the types of mutations that can be applied, such as changing conditional operators, altering arithmetic operations, modifying variable assignments, and more.

⬇️First-order mutants

First-order mutants are a type of mutation that involves making a single small change to the original code. These mutations typically introduce simple faults, such as changing a conditional operator, altering an arithmetic operation, or modifying a variable assignment.

First-order mutants are created by applying basic mutation operators that target specific elements of the code, such as binary operators, unary operators, constants, and variables. The purpose of first-order mutants is to evaluate the ability of the test suite to detect simple and easily identifiable faults.

For example, consider a conditional statement if (x > 0) in the original code. A first-order mutant could change the relational operator from > to >=, resulting in the mutated code if (x >= 0). This mutation tests whether the test suite is capable of detecting the change in the condition and its impact on the program's behaviour.

First-order mutants are relatively straightforward and provide a good starting point for mutation testing. They help assess the test suite's ability to identify basic faults and ensure that even small changes in the code can be effectively detected by the tests. However, first-order mutants may not capture more complex faults or subtler issues that require higher-order mutations to manifest.

⬆️Higher-order mutants

Higher-order mutants are a more advanced type of mutation that involves making multiple and potentially complex changes to the original code. Unlike first-order mutants, which make single small alterations, higher-order mutants introduce more extensive modifications that can result in significantly different program behaviours.

Higher-order mutants are created by applying compound mutation operators that combine multiple mutation operators or introduce intricate changes across different parts of the code. These mutations aim to challenge the test suite's ability to detect more complex faults and assess the robustness of the testing approach. They provide a more comprehensive assessment of the test suite's ability to handle intricate code modifications and ensure the software's resilience against more sophisticated faults.

It is important to note that higher-order mutants require careful consideration and analysis due to the increased complexity and potential impact on the program's behaviour. The generation and evaluation of higher-order mutants can be more computationally expensive compared to first-order mutants, but they provide valuable insights into the thoroughness and effectiveness of the testing process.

💻 Example

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        if (x > 0) {
            write(x + y);
        } else {
            write(x * y);
        }
    }

    public static void write(int value) {
        //...
    }

    public static void read(int x, int y) {
        //...
    }
}

Order 2 mutant on a single execution:

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        if (x >= 0) {
            write(x + y + 1);
        } else {
            write(x * y);
        }
    }

    public static void write(int value) {
        //...
    }

    public static void read(int x, int y) {
        //...
    }
}

In general, only 1-order mutants are used in practice.

The reasons are:

• A large number of 2 or higher-order mutants slows down the tests;

• Coupling-effect;

🪜Basics of mutation testing

Mutation testing is built upon two fundamental concepts: the competent programmer hypothesis and the coupling effect. Let's begin by exploring the first concept...

Competent programmer hypothesis

When tackling a specific problem, programmers typically develop code that closely resembles a correct solution for that problem. Consequently, the presence of errors or faults within the code can be identified by solely employing first-order mutants.

It assumes that developers write code that is functionally correct and follows the intended logic. According to this hypothesis, the majority of faults in a program are introduced through mistakes or oversights in the code implementation, rather than fundamental flaws in the underlying design.

In other words, the competent programmer hypothesis posits that if a developer creates a faulty piece of code, it is more likely to be due to human error or oversight rather than a deliberate intention to implement faulty logic. Therefore, when conducting mutation testing, the hypothesis assumes that most mutations introduced into the code will likely result in faults that deviate from the intended behaviour. The effectiveness of a test suite is evaluated by its ability to detect these introduced faults (mutations) and identify deviations from the expected behaviour. If the test suite fails to detect a significant number of mutations, it suggests that the tests may not be thorough enough or sensitive to potential faults, highlighting areas for improvement.

Coupling effect

The choice of test data plays a crucial role in distinguishing errors within slightly deviating programs, particularly when those errors become more complex. Empirical evidence reveals that a test suite capable of differentiating between a program and its first-order mutants is highly likely to be effective in discerning second-order mutant programs as well.

An intuitive explanation for this phenomenon lies in the observation that simple errors tend to be more elusive and challenging to detect. On the other hand, complex errors tend to manifest themselves more prominently, making them more susceptible to identification by a broader range of tests.

💪Strong mutation / 😩weak mutation

A T-test is considered to kill a mutant, denoted as M, if it can distinguish the behaviour of M from that of the original program, referred to as P. This distinction is based on the observation of their different behaviours during the T-test.

Now, the question arises: When do we observe the behaviours of the two programs?

During the T-test, both P and M are executed in different states. This means that the program's status, including the values of the affected variables, is observed after the execution of the modified instruction.

Additionally, the state changes propagate until the end of the program. This includes observing the values of the returned variables and other effects, such as modifications to global variables, files, or databases, immediately after the program's execution is completed.

It's worth noting that weak mutation occurs when only the first condition (observation of the program's status) is satisfied, while strong mutation requires both conditions to be met for proper observation and distinction between P and M.

Program P

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        y = y + 1;
        if (x > 0) {
            write(x);
        } else {
            write(y);
        }
    }
}

Mutant M

public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x,y);
        y = y - 1;
        if (x > 0) {
            write(x);
        } else {
            write(y);
        }
    }
}

The ( 1, 1 ) test distinguishes between P and M from the point of view of weak mutation, but does not distinguish between P and from the point of view of strong mutation.

The ( 0, 1 ) test distinguishes between P and M from the point of view of strong mutation.

Strong mutation: stronger. It is ensured that the test detects T with real problems.

Weak mutation: requires less computing power; closely related to the idea of ​​coverage

🟰Equivalent mutants

Equivalent mutants refer to mutated versions of code that have the same observable behaviour as the original code. In other words, equivalent mutants produce the same outputs for the given set of test cases and do not introduce any discernible differences in the program's behaviour.

We need to decide whether or not the mutants are equivalent to be able to evaluate the effectiveness of the tests

From a theoretical point of view: in general, the problem of determining if a mutant is equivalent to the parent program is undecidable (it is equipped with a halting problem)

In practice: the determination of equivalence is done by analyzing the code.

Determining equivalent mutants can be a complex process – the main practical problem of the mutation testing technique

An example of an equivalent mutant for the provided code can be achieved by simply swapping the order of the initialisation for x and y:

// Original code
public class MutationExample {
    public static void main(String[] args) {
        int x = 0;
        int y = 0;
        read(x, y);
        y = y + 1;
        if (x > 0) {
            write(y);
        } else {
            write(x);
        }
    }
}

// Mutation code
public class MutationExample {
    public static void main(String[] args) {
        int y = 0;     
        int x = 0; // <-- swapped
        read(x, y);
        y = y + 1;
        if (x > 0) {
            write(x);
        } else {
            write(y);
        }
    }
}

🧮Mutation score (MS)

Mutation score is a metric used in mutation testing to quantify the effectiveness of a test suite in detecting mutations. It represents the percentage of mutations that are killed or detected by the test suite out of the total number of generated mutations.

The mutation score is calculated by dividing the number of killed mutations by the total number of generated mutations and multiplying the result by 100 to get a percentage. A higher mutation score indicates a more effective test suite, as it signifies a greater ability to detect and kill mutations.

MS(T) = D/(L+D), where:

• D – the number of distinguished mutants;

• L – the number of non-equivalent mutants (live mutants);

📍Conclusion

In conclusion, mutation testing emerges as a powerful technique that revolutionizes the landscape of software testing. Throughout this article, we have explored the intricacies and utilities of mutation testing, delving into its fundamental concepts, techniques, and benefits.

By introducing artificial faults (mutations) into the code and assessing the ability of the test suite to detect these mutations, mutation testing provides valuable insights into the quality and effectiveness of the testing process. It evaluates the thoroughness of the test suite, identifies areas of improvement, and enhances the overall reliability and resilience of the software.

Happy coding! 🙂

🔍 Overview

Structural testing is another important part of the software development process, as it helps to ensure the quality and reliability of a software system. This type of testing focuses on the internal structure of the software and verifies that it is designed and built according to industry standards and best practices.

By evaluating the various components of the system and the relationships between them, structural testing can detect potential weaknesses and defects that could cause problems down the line. This article will provide an overview of structural testing, including its benefits, techniques, and challenges.

🔑 Key Features

• The test data is generated based on the implementation (program), without taking into account the specification(s) of the program;

• To use structural testing methods, the program can be represented as a directed graph;

• The test data is chosen to go through all the elements (instruction, branch, or path) of the graph at least once. Depending on the type of elements chosen, different measures of graph coverage will be defined: Instruction level coverage, branch level coverage or path level coverage;

📍 Converting an application into an oriented graph

• For a sequence of instructions, a node is inserted:

  • if c then s1 else s2:

    

  • while c do s:

    

  • repeat s until c:

    

💻 Example

We will use the same example of the application from the previous Functional Testing article.

import java.util.Scanner;

public class CharacterSearch {

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        String inputString;
        char searchChar;
        String searchAgain = "y";

        while (searchAgain.equals("y")) {
            // get the input string
            System.out.print("Enter a string of no more than 20 characters: ");
            inputString = scanner.nextLine();
            while(inputString.length()>20){
                System.out.println("String is too long, please enter a string of no more than 20 characters:");
                inputString = scanner.nextLine();
            }
            // get the character to search for
            System.out.print("Enter a character to search for: ");
            searchChar = scanner.nextLine().charAt(0);

            // search for the character in the string
            int charIndex = inputString.indexOf(searchChar);
            if (charIndex == -1) {
                System.out.println("The character '" + searchChar + "' was not found in the string '" + inputString + "'.");
            } else {
                System.out.println("The character '" + searchChar + "' was found at position " + (charIndex + 1) + " in the string '" + inputString + "'.");
            }

            // ask the user if they want to search for another character
            System.out.print("Search for another character? (y/n): ");
            searchAgain = scanner.nextLine();
        }
        System.out.println("Thank you for using the Character Search program!");
    }
}

The graph representation will be:

🌍 Coverages

In structural testing, coverage refers to the extent to which the source code is executed during testing. Various coverage criteria can be used to measure the degree of code coverage achieved during testing.

One approach to measuring coverage is to use a control flow graph, which is a graphical representation of the program's control flow. Based on the control flow graph, different coverage criteria can be defined, such as:

• Statement coverage: each instruction (node in the graph) is executed at least once;

• Branch coverage: each branch in the graph is executed at least once;

• Path coverage: each path through the graph is executed at least once;

📍 Statement coverage

Statement coverage is a metric used in structural testing that measures the percentage of individual statements in a program that have been executed during testing. In other words, it refers to the degree to which the code has been exercised by the test cases.

In the context of structural testing, achieving statement coverage means that every statement in the code has been executed at least once during testing. This is typically considered the minimum level of coverage that should be achieved through structural testing.

To achieve statement coverage, testers need to focus on those statements in the code that are controlled by conditions, which correspond to the branches in the control flow graph. By testing both the true and false branches of each condition, testers can ensure that all statements in the code have been executed at least once.

💻 Example

Let's say we have a Java program that calculates the average of two numbers. Here's the code:

public class AverageCalculator {
    public static double calculateAverage(double num1, double num2) {
        double sum = num1 + num2;
        double average = sum / 2;
        return average;
    }
}

To achieve statement coverage, we need to ensure that each statement in the code is executed at least once during testing. In this case, that means we need to test both the assignment statement for the sum variable and the assignment statement for the average variable.

Here's an example of a JUnit test case that achieves statement coverage:

import org.junit.Test;
import static org.junit.Assert.assertEquals;

public class AverageCalculatorTest {
    @Test
    public void testCalculateAverage() {
        double num1 = 10;
        double num2 = 20;
        double expectedAverage = 15;
        double actualAverage = AverageCalculator.calculateAverage(num1, num2);
        assertEquals(expectedAverage, actualAverage, 0.01);
    }
}

In this test case, we're passing in the values 10 and 20 for num1 and num2, respectively, and we're expecting the calculated average to be 15. This test case ensures that both the sum and average statements are executed, thus achieving statement coverage.

🔹 Statement coverage weaknesses

While statement coverage is a useful metric for measuring the thoroughness of testing in some cases, it does have certain weaknesses:

1. Limited effectiveness in detecting faults: Achieving 100% statement coverage does not necessarily mean that all potential faults in the code have been detected. It is possible to achieve high statement coverage while still leaving certain faults undetected. This is because statement coverage does not take into account the behaviour of the code under different inputs or conditions.

2. Difficulty in achieving complex programs: For large and complex programs, achieving high statement coverage can be difficult and time-consuming, since there may be many possible execution paths and combinations of inputs to consider.

3. Focus on execution, not correctness: Statement coverage focuses on the extent to which code has been executed, rather than whether it has been executed correctly. In other words, statement coverage can tell us which parts of the code have been executed, but it does not provide any guarantee that the code is working correctly.

4. False sense of security: Achieving high statement coverage can give testers a false sense of security, leading them to believe that the code is free of faults when in fact some may still be present.

5. Lack of guidance on test case selection: Statement coverage does not provide guidance on which test cases to select to achieve the desired coverage, which can make it difficult for testers to develop effective test suites.

📍 Decision coverage

Decision coverage, also known as branch coverage or ramification coverage, is a metric used in structural testing that measures the degree to which each decision point in the code has been exercised during testing. It is an extension of statement coverage that focuses on the control flow of the program, rather than just the individual statements.

To achieve decision coverage, testers need to ensure that every possible branch in the code has been executed at least once. This means generating test cases that exercise each decision point in the code in both the true and false directions. This includes branches that are not explicitly covered by if/else statements, such as null branches and default cases in switch statements.

💡 Remarks

• The decision means any branch in the graph, even when it does not appear explicitly in the program.

• For example, for the construction of for i:= 1 to n from Pascal, the default condition is i<=n.

📍 Condition coverage

To achieve condition coverage, testers need to ensure that each condition within a decision has been evaluated as both true and false. For example, if a decision takes the form of c1 || c2 or c1 && c2, then condition coverage is achieved by testing each condition c1 and c2 in both true and false directions.

Condition coverage is useful in cases where certain conditions within a decision are more critical or complex than others, as it allows testers to focus their efforts on these conditions. However, it should be noted that achieving 100% condition coverage does not guarantee that all potential faults in the code have been detected, as it does not take into account the interaction between different conditions or inputs.

💻 Example

Using the code example with CharacterSearch from the beginning...

• (n, x, c, s) = (0, , , _)

• (n, x, c, s) = (25, , , _)

• (n, x, c, s) = (1, a, a, y)

• (n, x, c, s) = (_, _, b, Y)

🔹 Condition coverage weaknesses

While condition coverage can help detect certain faults, it is not a foolproof method and has its weaknesses. One such weakness is that it may not necessarily achieve branch coverage, as it only focuses on individual conditions within a decision. For example, the data used in a condition coverage test may not result in the program executing all possible branches of a decision.

For instance, consider the code snippet below:

while (response == 'y' || response == 'Y') {
    // some code here
}

If we only focus on condition coverage and test with data where the condition (response == 'y' || response == 'Y') evaluates to true, the loop will continue indefinitely and we may miss testing the exit condition. In this case, a more comprehensive testing approach that includes decision or branch coverage may be required to ensure all possible code paths are executed.

To overcome this weakness, testers can use other testing techniques in conjunction with condition coverage, such as a decision or branch coverage, to ensure more comprehensive coverage of the code. By using multiple testing techniques in combination, testers can increase their chances of detecting faults in the code.

📍 Condition/decision coverage

Generate test data so that each condition in a decision must take both a true value and a false value (if possible) and every decision must also take both a true value and a false value.

• (n, x, c, s) = (0, _, _, _)

• (n, x, c, s) = (25, _, _, _)

• (n, x, c, s) = (1, a, a, y)

• (n, x, c, s) = (_, _, b, y)

• (n, x, c, s) = (_, _, B, n) produces the false value for the remaining global condition ((response=='y') ||(response='Y')

📍 Multiple condition coverage

Multiple condition coverage is a structural testing technique that aims to test all possible combinations of truth values for the individual conditions within a decision. This testing technique ensures that all possible combinations of truth values for the conditions are tested, thus providing more thorough coverage than other testing techniques like condition coverage.

For example, if a decision has three conditions, A, B, and C, then multiple condition coverage requires testing all eight possible combinations of true and false values for each condition: A=true, B=true, C=true; A=true, B=true, C=false; A=true, B=false, C=true; A=true, B=false, C=false; A=false, B=true, C=true; A=false, B=true, C=false; A=false, B=false, C=true; A=false, B=false, C=false.

While multiple-condition coverage provides more thorough coverage than other testing techniques, it can result in a large number of test cases, especially when the number of conditions is large. This is because the number of possible combinations grows exponentially as the number of conditions increases. Hence, there may be a trade-off between coverage and the practicality of generating and executing the required number of test cases.

📍 Modified condition/decision (MC/DC) coverage

Modified Condition/Decision Coverage (MC/DC) is a structural testing technique that ensures each condition in a decision statement independently affects the outcome of the decision. MC/DC requires that each condition be tested with all possible combinations of the other conditions and that each condition should be evaluated to be both true and false at least once.

In MC/DC, each condition should be evaluated in such a way that it changes the outcome of the decision statement, and the other conditions should be held constant. This technique helps to identify and test the unique decision points within a program.

MC/DC is commonly used in safety-critical applications such as aviation and medical devices, where errors can have serious consequences. This technique provides a higher level of assurance that the software is functioning correctly and meets the required safety standards.

A test set satisfies MC/DC coverage when:

• Each condition in a decision takes both a true value and a value fake;

• Each decision takes both a true and a false value;

• Each condition independently influences the decision from which side face;

There are several advantages to using Modified Condition/Decision Coverage (MC/DC) in structural testing:

1. Thorough Testing: MC/DC requires that each condition be tested with all possible combinations of the other conditions, ensuring that all decision outcomes are tested. This technique provides a thorough and rigorous testing approach that can identify potential errors or bugs.

2. Effective Fault Localization: MC/DC can help in localizing the faults by identifying the specific condition(s) that caused a failure or error. This can reduce the time and effort needed to locate and fix the issue.

3. Better Quality Assurance: MC/DC is commonly used in safety-critical applications such as aviation and medical devices, where errors can have serious consequences. By using this technique, the software can be tested to a higher level of assurance and meet the required safety standards.

4. Reduced Maintenance Costs: MC/DC testing can help identify issues earlier in the development cycle, reducing the cost and effort required to fix issues in later stages of the software development lifecycle.

5. Improved Test Efficiency: By focusing on the unique decision points within a program, MC/DC testing can help reduce the number of tests required while still providing thorough coverage. This can improve test efficiency and reduce testing time and effort.

💻 Examples of test cases

1. Using AND operator in MC/DC:

t1 and t3 covers C1

t1 and t2 covers C2

1. Using OR operator in MC/DC:

t2 and t3 covers C1

t1 and t3 covers C2

1. Using XOR operator in MC/DC:

t2 and t3 covers C1

t1 and t2 covers C2

💻 And a more complex example: C = C1 ∧ C2 ∨ C3

📍Conclusion

In conclusion, structural testing plays an essential part in ensuring the quality and reliability of software systems. The techniques described in this article allow for a thorough analysis of the internal structure of the software, ensuring that all possible paths and decision points are tested.

This technique focuses on identifying and modelling the relationships between the inputs and outputs of a program, as well as the logical connections between them. We will also discuss the benefits of using this method and provide examples of its application in functional testing.

It is a visual representation of the logical relationship between causes and effects, expressible as a Boolean expression.

Cause = any condition in the specification(s) that may affect the response of the program;

Effect = program response to a combination of input conditions;

The effect is not necessarily an output (it can be an error message, a display, a database modification, or even an internal test point).

Types of Cause-Effect relationships

• Implies: if C then Ef

• Not – Implies: if (¬ C) then Ef

• And – Implies: if (C1 && C2) then Ef

• Or – Implies: if (C1 || C2) then Ef

Types of constraints between causes

• E (exclusive): either C1 or C2 (at most one of them)

  

• I (inclusive): At least C1 or C2

• O (one and only one): One and only one of C1 and C2

• R (requires) C1 requires C2 (if C1 then C2)

Types of constraints between effects

• M (Masks): Ef1 masks Ef2 (if Ef1 then ¬Ef2)

Example 💻

Let's see a simple example of a Cause-Effect Graph.

A company sells on the web computers (CPU1, CPU2, CPU3), printers (PR1, PR2), monitors (M20, M23, M30) and additional memory (RAM256, RAM512, RAM1G). An order includes between 1 and 4 items, at most one of the 4 categories mentioned. The Graphic Integrate consists of 4 windows (for the 4 product categories) and a window for displaying the items received as a gift.

The M20 and M23 monitors can be bought with any CPU or alone. M30 can only be bought together with CPU3. PR1 is offered as a gift for buying CPU2 or CPU3. Monitors and printers, apart from M30, can be bought separately, without buying the CPU. When buying one CPU1 you get a RAM256 upgrade, and with the purchase of a CPU2 or CPU3 RAM512 upgrade is received. When buying a CPU3 and an M30, receive a RAM1G upgrade and PR2 as a gift.

Extracting the causes:

• C1: Purchase of CPU1

• C2: Purchase of CPU2

• C3: Purchase of CPU3

• C4: Purchase of PR1

• C5: Purchase of PR2

• C6: Purchase of M20

• C7: Purchase of M23

• C8: Purchase of M30

Getting the effects:

• Ef1: RAM256

• Ef2: RAM512 and PR1 (can be considered separation effects, but it can unnecessarily complicate the graph)

• Ef3: RAM1G and PR2

• Ef4: no gift

Decision Table

A decision table is a tool that is commonly used in conjunction with the cause-effect graphing technique in functional testing. It is a tabular representation of all possible inputs and outputs for a specific system or component, based on the causes and effects identified in the cause-effect graph.

Decision tables are useful for identifying any missing combinations of inputs and outputs, and for testing the system or component with a comprehensive set of test cases. The decision table can also be used to organize and document the test cases and results, making it a useful tool for both the testing and development teams.

Input: A cause-and-effect graph having causes C1, …, CP and effects Ef1, …, Efq.

Output: A decision table with N = p + q rows and M columns, where M depends on the relationship between cause and effect.

The procedure for creating a decision table 📋

1. Initialize no_columns = 0 (empty decision table);

2. For i = 1 to q;

   1. E = EFI (selects the following effect for processing);

   2. Find the combinations of conditions that produce the effect of;

   3. Let V1, ..., VMI these combinations, MI > 0. Set VK(j), p < j ≤ p+q, to 1 if the EFJ effect occurs as a result of that combination, and to 0 if not;

   4. Update the decision table;

   5. Add columns V1, ..., VMI to the table starting with position No._columns + 1;

   6. no_columns = no_columns + mi;

Example

Creating decision table

Step 1: nr_columns = 0;

Step 2: i = 1;

Step 2.1: e = Ef1;

Step 2.2: Searching the values for C1, C2, C3 such that ¬ (C1 ∧ C2) ∨ C3 = 1;

In addition, the constraint C3 implies C1 is applied;

Add C4 = 0 and the corresponding values ​​for Ef1 and Ef2;

Step 2.3: The obtained matrix is ​​transposed and added to the decision table, starting with position nr_columns + 1 = 1;

Step 2.4: No_columns = 0 + 5 = 5 are updated;

Step 3: i = 2;

Step 3.1: e = Ef2;

Step 3.2: The values ​​of C1, C2, C3, C4 are sought so that (¬ (C1 ∧ C2) ∨ C3) ∧ C4 = 1;

Step 3.3: Using the combinations C2, C2, C3 previous for Ef1, we get:

In addition, the constraint that C2 and C4 should not exist simultaneously:

Add the corresponding values ​​for Ef1 and Ef2:

Step 3.4: No_columns = 5 + 3 = 8 are updated;

Generating Test Cases

Each column in the decision table generates at least one case of testing, corresponding to the respective C1, …, Cp combination.

Note: C1, …, Cp are generally expressions that use variables, etc., so several cases can be selected for combination testing.

Problem: Explosion of states due to the combination of causes.

Solution: Limiting the number of test cases using heuristics.

Conclusion

Cause Effect Graphing is a valuable technique for functional testing that enables software developers to understand the relationships between the inputs and outputs of a system or its component. This technique provides a visual representation of the logical relationships between causes and effects, expressed as a Boolean expression.

More examples of this technique can be seen in this repo.

These techniques are widely used to ensure that a software system is working correctly and is free of defects. We will explore the concepts behind each technique, and how they can be applied to different types of software systems. By the end of this article, you will have an overview understanding of how to effectively test your software using these powerful techniques.

Overview 🔍

Functional Testing is a type of software testing that validates the software system against the functional requirements and specifications. The purpose of functional tests is to test each function of the software application, provide the appropriate information and check production against functional requirements.

Key Features

• The test data is generated according to the program specifications, the program structure plays no role;

• The ideal specification type for functional testing includes preconditions and subsequent requirements;

• Most functional methods are based on partitioning input data so that data belonging to the same partition will have (identical) properties associated with the specified behaviour;

Practically, due to time and budget considerations, it is not possible to perform exhausting testing for each set of test data, especially when there is a large pool of input combinations.

Equivalence Partitioning

The first type of Functional Testing is Equivalence Partitioning, also known as Equivalence Class Partitioning (ECP), and the basic idea is partitioning the domain of the problem (input data) in equivalence partitions or equivalence classes so that, from the specification point of view, the data in a class is treated in the same way. Since all values in a class have specified the same behaviour, it can be assumed that all values in a class will be processed in the same way, so it is enough to choose one value from each class.

In addition, the output field will be treated in the same way, and the resulting classes will be converted in reverse engineering into classes of the input field.

The equivalence classes must not overlap, so any overlapping classes must be broken down into separate classes. Once the classes have been identified, a value is chosen from each class. In addition, invalid data (which is outside of classes and is not processed by any class) may also be chosen. The choice of values in each class is arbitrary because it assumes that all values will be processed in the same way.

Simple Example 💻

This program checks whether a character is present within a string of 20 characters or less. It prompts the user to enter a string of a specific length (n) between 1 and 20 and then prompts the user to enter a character (c) to search for in the previously entered string. The program will then output the position of the first instance of the character in the string or a message indicating that it was not found. The user can then choose to search for another character by typing "y" or end the program by typing "n".

Let's write the specification:

import java.util.Scanner;

public class CharacterSearch {

    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        String inputString;
        char searchChar;
        String searchAgain = "y";

        while (searchAgain.equals("y")) {
            // get the input string
            System.out.print("Enter a string of no more than 20 characters: ");
            inputString = scanner.nextLine();
            while(inputString.length()>20){
                System.out.println("String is too long, please enter a string of no more than 20 characters:");
                inputString = scanner.nextLine();
            }
            // get the character to search for
            System.out.print("Enter a character to search for: ");
            searchChar = scanner.nextLine().charAt(0);

            // search for the character in the string
            int charIndex = inputString.indexOf(searchChar);
            if (charIndex == -1) {
                System.out.println("The character '" + searchChar + "' was not found in the string '" + inputString + "'.");
            } else {
                System.out.println("The character '" + searchChar + "' was found at position " + (charIndex + 1) + " in the string '" + inputString + "'.");
            }

            // ask the user if they want to search for another character
            System.out.print("Search for another character? (y/n): ");
            searchAgain = scanner.nextLine();
        }
        System.out.println("Thank you for using the Character Search program!");
    }
}

 public int indexOfCharInString(String inputString, char searchChar) {
        if (inputString.length() > 20) {
            return -1;
        }
        return inputString.indexOf(searchChar);
    }

In this example, I've added a new method indexOfCharInString(inputString, searchChar) to the CharacterSearch class that takes the inputString and searchChar as inputs, and returns the index of the first occurrence of the searchChar in the inputString.

import org.junit.Test;
import static org.junit.Assert.*;

public class CharacterSearchTest {

    CharacterSearch cs = new CharacterSearch();

    @Test
    public void testIndexOfCharInString() {
        //Positive Test Case
        String inputString = "abcdefghijklmnopqrst";
        char searchChar = 'a';
        int expectedResult = 0;
        int result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        //Negative Test Case
        inputString = "abcdefghijklmnopqrstuvwxyz";
        searchChar = 'z';
        expectedResult = -1;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for max length of string
        inputString = "abcdefghijklmnopqrsz";
        searchChar = 'z';
        expectedResult = 19;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for min length of string
        inputString = "a";
        searchChar = 'a';
        expectedResult = 0;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for special characters
        inputString = "!@#abcdefghijklmnopq";
        searchChar = '#';
        expectedResult = 2;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);
    }
}

In the test class, CharacterSearchTest, I've created a test method testIndexOfCharInString() to test it using JUnit framework then I've created test cases for the positive, negative, max length of string, min length of string and special characters to test the method using the equivalence partitioning technique.

The test method first creates an instance of the CharacterSearch class, then it calls the indexOfCharInString(inputString, searchChar) method passing the inputString and searchChar as inputs, it then compares the expected result with the actual result, if they are equal the test will pass otherwise it will fail. This way we are testing the method for all possible inputs and also for the edge cases.

Including all of our conditions, we obtain the following domain:

Input data 👈

• an integer n;

• a string x;

• the searching character c;

• the option to search for a character (s), or not;

Input domain and constraints

• n must be between 1 and 20, so there are 3 classes of equivalence:

  • N_1 = 1..20

  • N_2 = { n | n < 1}

  • N_3 = {n | n > 20}

• The whole n determines the length of the string and nothing is stated about the different treatment of strings of different lengths so the second entry does not determine additional classes of equivalence;

• c does not determine additional equivalence classes;

• The option to search for a new character is binary, so 2 classes of equivalence are distinguished:

  • S_1 = { y } (yes, search for another character)

  • S_2 = { n } (no, do not search for another character)

Output data 👉

• The position at which the character is found in the string;

• A message that shows whether it was found or not;

We divide the output into 2 domain classes: One for the character in the string and one for the missing character.

• C_1(x) = { c | c is in x}

• C_2(x) = { c | c is not in x}

Equivalence Classes

At this point, we can extract equivalency classes. Equivalence classes are used to divide the input domain of a system or software into partitions of similar input values. An Equivalence class is a set of inputs or outputs that should behave in the same way for the same system or software. In this case, we extract the entire curriculum in the form of a combination of individual classes:

• C_111 = { (n, x, c, s) | n \in N_1, |x| = n, c \in C_1(x), s \in S_1}

  For example, this case represents:

  1. n \in N_1: n is a number between 1 and 20;

  2. |x| = n: length of string x is equal with n;

  3. c \in C_1(x): character c is in string X;

  4. s \in S_1: yes, search for another character;

• C_112 = { (n, x, c, s) | n \in N_1, |x| = n, c \in C_1(x), s \in S_2}

  For example, this case represents:

  1. n \in N_1: n is a number between 1 and 20;

  2. |x| = n: length of string x is equal with n;

  3. c \in C_1(x): character c is in string X;

  4. s \in S_1: no, do not search for another character;

• C_121 = { (n, x, c, s) | n \in N_1, |x| = n, c \in C_2(x), s \in S_1}

• C_122 = { (n, x, c, s) | n \in N_1, |x| = n, c \in C_2(x), s \in S_2}

• C_2 = { (n, x, c, s) | n \in N_2}

• C_3 = { (n, x, c, s) | n \in N_3}

Testing data

The test dataset is composed by selecting an entry value for each equivalence class. For example:

• C_111 : (3, abc, a, y)

• C_112 : (3, abc, a, n)

• C_121 : (3, abc, d, y)

• C_122 : (3, abc, d, n)

• C_2 : (0, _, _, _)

• C*_*3 : (25_, _, _)

The advantages

1. Increased efficiency: By partitioning the input domain into equivalence classes, testers can create a smaller set of test cases that are representative of a larger set of inputs. This allows for more efficient testing, as fewer test cases need to be created and executed.

2. Reduced costs: Because fewer test cases need to be created, the overall cost of testing is reduced. This can be especially beneficial for large or complex systems where the cost of testing can be significant.

3. Improved coverage: Equivalence partitioning helps to ensure that the system or software is tested for a wide range of inputs, including the boundaries of the input domain. This helps to identify any issues or bugs that may occur at these boundaries, which can improve overall system quality.

4. A better understanding of the system: By creating test cases that cover a wide range of inputs, testers gain a better understanding of how the system behaves under different conditions. This can be useful in identifying areas where the system may be particularly fragile or vulnerable.

5. Better test case design: By identifying the equivalence classes the test engineer can design the test cases more effectively, and can cover the possible inputs and edge cases.

6. Better maintenance: Equivalence partitioning can be useful in identifying areas of the system or software that may change frequently, which can help to ensure that these areas are tested thoroughly and that any changes are properly validated.

The disadvantages

While equivalence partitioning is a powerful technique for software testing, there are also some potential disadvantages to using it:

1. Complexity: Identifying and defining the appropriate equivalence classes can be a complex task, especially for large or complex systems. Testers may need to have a deep understanding of the system or software to properly identify the appropriate equivalence classes.

2. Limited coverage: While equivalence partitioning can help to improve the coverage of the input domain, it may not cover all possible inputs. Some inputs may fall outside of the defined equivalence classes, which can lead to potential defects or bugs going undetected.

3. Subjectivity: The definition of equivalence classes is often based on the tester's subjective interpretation of the system or software's requirements. This can lead to different testers identifying different equivalence classes, which can make it difficult to ensure consistent testing across different teams or projects.

4. Assumptions: Equivalence partitioning relies on certain assumptions about how the system or software behaves, which may not be accurate. This can lead to defects or bugs going undetected, or to test cases that are not valid for the system or software.

5. Time-consuming: Identifying and defining the appropriate equivalence classes can be time-consuming, especially for large or complex systems. This can lead to delays in the testing process,

Boundary Value Analysis

Now let's talk about another cool testing technique...Boundary Value Analysis 😎

Boundary value analysis is a testing technique that focuses on testing the boundaries of the input domain of a system or software. The goal of boundary value analysis is to identify and test inputs that are at or near the boundaries of the input domain, as these inputs are more likely to cause errors or defects in the system or software.

The idea behind boundary value analysis is that the behaviour of a system or software can be different at the boundaries of the input domain than it is in the middle of the input domain. For example, a program that accepts an age as input and checks if the age is greater than 18 is likely to behave differently when the age is 18 than it would when the age is 19.

Boundary value analysis is often used in conjunction with equivalence partitioning to provide more comprehensive coverage of the input domain.

During the testing process, the tester will identify the boundaries of the input domain such as minimum and maximum values, and then create test cases that focus on these boundaries. For example, the tester would create test cases for the minimum and maximum values, and one test case for the value just below and just above the boundaries.

Example

import org.junit.Test;
import static org.junit.Assert.*;

public class CharacterSearchTest {

    CharacterSearch cs = new CharacterSearch();

      @Test
    public void testIndexOfCharInString2() {
        // Test case for the minimum length of string
        String inputString = "a";
        char searchChar = 'a';
        int expectedResult = 0;
        int result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for the maximum length of string
        inputString = "abcdefghijklmnopqrsz";
        searchChar = 'z';
        expectedResult = 19;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for the first character of the string
        inputString = "abcdefghijklmnopqrst";
        searchChar = 'a';
        expectedResult = 0;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for the last character of the string
        inputString = "abcdefghijklmnopqrsz";
        searchChar = 'z';
        expectedResult = 19;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for special characters
        inputString = "!@#abcdefghijklmnopq";
        searchChar = '#';
        expectedResult = 2;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);
    }
}

In this example, I've created test cases that focus on the boundaries of the input domain, such as the minimum and maximum length of the input string, the first and last characters of the string, and special characters.

By testing these specific cases, we can identify any issues that may occur at the boundaries of the input domain, which can improve overall system quality.

• N_1 = 1..20

  • 1, 20 (boundary value) and a value from within;

• N_2 = {n | n < 1}

  • 0 (boundary value) and a value from within;

• N_3 = {n | n > 20}

  • 21 (boundary value) and a value from within;

• C_1(x) = { c | c is in x}

  • On the first position in x, on the last position in x, inside of x;

• C_2(x) = { c | c is not in x}

  • There are no clear borders, so no additional values appear;

Notes

The choice of boundaries is difficult and depends on the experience of the tester. For the choice of the border, the number of the appearance of c in row x: 0 appearances, 1 appearance and more than one appearance.

Category Partition

It is based on the two previous ones. It seeks to generate test data that “covers” the functionality of the system and maximizes the possibility of finding errors.

Steps

• Breaks down functional specification into units (programs, functions, etc.) that can be tested separately;

• For each unit, identify the environmental parameters and conditions (e.g. the state of the system at the time of execution) on which its behaviour depends;

• Find the categories (important properties or characteristics) of each parameter or environmental condition;

• Write the test specification. It consists of the list of categories and the list of alternatives for each category;

• Create test cases by choosing a combination of alternatives from the test specification (each category contributes zero or an alternative);

• Create test data by choosing a single value for each alternative;

Example

import org.junit.Test;
import static org.junit.Assert.*;

public class CharacterSearchTest {

    CharacterSearch cs = new CharacterSearch();

    @Test
    public void testIndexOfCharInString3() {
        // Test case for strings with length less than 20
        String inputString = "abc";
        char searchChar = 'b';
        int expectedResult = 1;
        int result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for strings with length equal to 20
        inputString = "abcdefghijklmnopqrsx";
        searchChar = 'x';
        expectedResult = 19;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);

        // Test case for strings with length greater than 20
        inputString = "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz";
        searchChar = 'z';
        expectedResult = -1;
        result = cs.indexOfCharInString(inputString, searchChar);
        assertEquals(expectedResult, result);
    }
}

In this example, I've created test cases that focus on different categories of the input domain. I've grouped the inputs into 3 categories, strings with a length less than 20, strings with a length equal to 20 and strings with a length greater than 20, and special characters.

By testing these specific categories, we can identify any issues that may occur with different lengths of the input string which can improve overall system quality. It's important to note that this is just an example and you should adjust the test cases according to your implementation and the requirements of the system.

• Break down the specification into units: We have only one unit;

• Identify parameters: n, x, c, s;

• Find categories:

  • n: if it is in the valid range 1..20;

  • x: if it is of minimum, maximum or intermediate length;

  • c: if it occupies the first or last position or position inside x or does not appear in x;

  • s: if it is positive or negative;

• Categorize each category into alternatives:

  • n: <0, 0, 1, 2..19, 20, 21, >21;

  • x: minimum, maximum or intermediate length;

  • c: the position is first, inside, or last or c does not appear in x;

  • s: y, n;

We are writing testing specifications:

• For n

  • {n | n < 0}

  • 0

  • 1

  • 2..19

  • 20

  • 21

  • {n | n > 20}

• For x

  • {x | |x| = 1}

  • {x | 1 < | x | < 20}

  • {x | |x| = 20}

• For c

  • { c | c is in the first position in x}

  • { c | c is inside x}

  • { c | c he is in the last position in x}

  • { c | c not in x}

• s

  • y

  • n

Test Cases

• The test specification should result in 7 * 3 * 4 * 2 = 168 test cases;

• Some combinations of alternatives make no sense and can be eliminated;

• The alternatives will only be combined if the selection conditions are satisfied;

• For example, the number of test cases is reduced to 24;

Examples of test cases

• n1

• n2

• n3x1c1s1

• n3x1c1s2

• n3x1c4s1

• n3x1c4s2

• n4x2c1s1

• n4x2c1s2

• n4x2c2s1

• n4x2c2s2

• n4x2c3s1

• n4x2c3s2

• n4x2c4s1

• n4x2c4s2

• n5x3c1s1

• n5x3c1s2

• n5x3c2s1

• n5x3c2s2

• n5x3c3s1

• n5x3c3s2

• n5x3c4s1

• n5x3c4s2

• n6

• n7

Advantages and disadvantages

The starting steps (identification of environmental parameters and conditions as well as categories) are not well-defined and are based on the experience of the tester. On the other hand, once these steps have been passed, the application of the method is very clear.

Category Partitioning is more clearly defined than previous functional methods and can produce more comprehensive test data that tests additional functionality. On the other hand, due to the combinatorial explosion, very large test data can result.

Conclusion

In conclusion, functional testing is an essential part of the software development process. Equivalence Partitioning, Boundary Value Analysis, and Category Partition are some of the techniques that can be used to ensure that a system functions correctly. By using these techniques, we can identify and isolate issues early on in the development process which can save time and resources in the long run.

Equivalence Partitioning helps to divide the input domain into smaller, more manageable chunks, making it easier to identify test cases. Equivalence Classes are the specific group of inputs that are used to test a system. By using Equivalence Classes, we can ensure that our test cases are representative of the entire input domain.

Boundary Value Analysis is a technique that focuses on the limits of the input domain. By testing the boundaries of the input domain, we can identify and isolate issues that may occur at the limits of the system.

Category Partition is a technique that groups inputs into specific categories. By testing each category separately, we can identify and isolate issues that may occur within a specific category of inputs.

In this article, I have shown you how to use these techniques to test a program that checks if a character is in a string of no more than 20 characters. I hope that you found the information in this article helpful and that you now have a better understanding of how to use these techniques to improve the quality of your software.

In this article, we have covered the first aspect of Functional Testing. In the following instalment, we will delve into the topic Cause Effect Graphing.

Those interested in learning more about Functional Testing can read more in the presentation of Aditya P. Mathur about the Foundations of Software Testing, and an additional in-depth example can be found on my GitHub project. ✨

Reference 📙

[1] Gist One: https://gist.github.com/mihaichris/f60105f9617e651ece7531b0ffbf543e

[2] GitHub Project: https://github.com/mihaichris/kata-ohce

[3] Aditya P. Mathur. Foundations of Software Testing, Pearson Education 2008. Chapter 3: Domain Partitioning