Neeraj Das

Foodies (web app)

Thu, 02 Mar 2023 00:00:00 +0000

Overview

This case study focuses on designing a responsive web app for the existing “Foodies” food delivery mobile app, as described in this case study.

It targets customers who prefer devices with large screen sizes (laptops, tablets or desktops) to mobile devices.

The Problem

Some people prefer devices with large screen sizes for online activities.

The Goal

Design a food delivery responsive web app that allows users to easily order healthy meals and get it delivered at their doorstep.

My Role

UX designer designing a food delivery responsive web app from conception to delivery.

Responsibilities

Conducting interviews, paper and digital wireframing, low and high-fidelity prototyping, conducting usability studies, accounting for accessibility, and iterating on designs.

User research

I conducted interviews and created empathy maps to understand the users’ problems. The primary user group were people who preferred devices with large screen sizes for online activities.

This user group confirmed initial assumptions about potential customers. Research also revealed that apart from screen size, the availability of a mobile device was also a factor limiting users from using the mobile app.

Pain points

Accessibility

Either the target users don't have access to a mobile device or have difficulties using one.

Persona

Pratyush

Age: 31 Education: MBBS Occupation: Doctor Hometown: Sambalpur, Odisha

"Healing the world and searching for tools that can help me live a better life"

Goals

Make time for each of his patients
To have easy access to healthy food

Frustrations

Having a busy schedule makes it difficult for him to prepare a meal

Pratyush is a Doctor with a busy and demanding schedule at a hospital in Sambalpur. He cares a lot about being available to his patients and often takes appointments at the last minute. He lives alone and mostly orders food online. Text-heavy and unresponsive apps make it difficult for him to find and order the right food.

Starting the design

Wireframes

Low-fidelity prototype

Using the completed set of digital wireframes, I created a low-fidelity prototype. The primary user flow was to select a restaurant and order food. This prototype was used in a usability study.

Usability study

I used the high-fidelity prototype for the usability study and it revealed aspects of the designs that needed refining.

Findings

Menu tab was missing from the restaurant page.
Important links: Help, Contact and About were missing from the design.

Refining the design

I added the Menu tab and the missing links.

High fidelity prototype

The final high-fidelity prototype presented cleaner user flows for ordering food and checkout. It also met user needs for payment on delivery option.

Play prototype

Accessibility considerations

Provided access to users who are visually impaired through adding alt text to images for screen readers.
Used icons to help make navigation easier.
Used detailed imagery for food items to help all users better understand the designs.

Takeaways

Impact

Users love the web version of the food delivery mobile app.

Quote from peer feedback

"Wow, now I don't have to switch devices to order food while working on my laptop. Big thanks to the Foodies team for thinking about this."

What I learned

While designing this app, I learned that the first ideas for an app are only the beginning of the process. Usability studies and peer feedback influenced each iteration of the app's designs.

Next steps

Conduct another round of usability studies to validate whether the pain points users experienced have been effectively addressed.

Conduct more user research to determine any new areas of need.

Blood donor

Tue, 21 Feb 2023 00:00:00 +0000

Overview

“Blood Donor” is a mobile app designed to help people donate or find blood donors. It targets people who have difficulties finding a blood donor.

The Problem

People have difficulties finding blood donors.

The Goal

Design an app to help people donate or find blood donors easily.

My Role

UX designer designing a blood donation and procurement app from conception to delivery.

Responsibilities

Conducting interviews, wireframing, low and high-fidelity prototyping, conducting usability studies, accounting for accessibility, and iterating on designs.

User research

I conducted interviews and created empathy maps to understand the users’ problems. The primary user group were people who had faced a situation where they needed a blood donor.

Pain points

Finding donors

Posting on multiple social platforms is tiring, consumes a lot of time and doesn't give a positive response.
Unable to find donors who are nearby or available.

Availability

Unaware of the availability of blood, travelling to different blood banks is a pain.

Persona

Nancy

Age: 26 Education: B Ed Occupation: Teacher Hometown: Bhubaneswar

"Looking for a tool that can help me find blood donors near me"

Goals

To find blood on time
To find the right blood match
Easily connect to a donor

Frustrations

Trouble finding donors
Unavailability of blood

Nancy is a teacher at a primary school in Bhubaneswar. She is suffering from a chronic illness which requires frequent blood transfusions. She lives with her parents and hopes to find an easy way to find blood donors during her treatment.

Starting the design

Wireframes

Low-fidelity prototype

Using the completed set of digital wireframes, I created a low-fidelity prototype. The primary user flow was to find a blood donor. This prototype was used in a usability study.

Usability study

I conducted two rounds of usability studies. Findings from the first study helped guide the designs from wireframes to mockups. The second study used a high-fidelity prototype and revealed what aspects of the mockups needed refining.

Round 1 findings

The design didn’t include a sign-in process for recipients to help find a blood donor fast. Because of this, users couldn’t track their requests after closing the app.

Round 2 findings

The “blood group” and “state” appeared to be text input fields which should have been dropdown menus.

Refining the design

I added a simple phone number and OTP sign-in process to help users track their requests.

I added icons to make “blood group” and “state” appear like dropdown menus.

High fidelity prototype

The final high-fidelity prototype presented cleaner user flows for finding a blood donor.

Play prototype

Takeaways

Impact

The app makes users feel the "Blood donors" app does a nice job finding a blood donor.

Quote from peer feedback

"The app made it so easy and quick to find a blood donor. I would definitely use this app."

What I learned

While designing this app, I learned that the first ideas for an app are only the beginning of the process. Usability studies and peer feedback influenced each iteration of the app's designs.

Next steps

Conduct another round of usability studies to validate whether the pain points users experienced have been effectively addressed.

Conduct more user research to determine any new areas of need.

Foodies

Tue, 21 Feb 2023 00:00:00 +0000

Overview

Foodies is a food delivery mobile app. It strives to deliver a wide range of food items from various restaurants. It targets customers who lack the time to prepare meal and helps them order food online and get it at their doorstep.

The Problem

Busy workers and commuters lack the time necessary to prepare a meal.

The Goal

Design a food delivery app that allows users to easily order healthy meals and get it delivered at their doorstep.

My Role

UX designer designing a food delivery app from conception to delivery.

Responsibilities

Conducting interviews, paper and digital wireframing, low and high-fidelity prototyping, conducting usability studies, accounting for accessibility, and iterating on designs.

User research

I conducted interviews and created empathy maps to understand the users I’m designing for and their needs. A primary user group identified through research was working adults who don’t have time to cook meals.

This user group confirmed initial assumptions about potential customers, but research also revealed that time was not the only factor limiting users from cooking at home. Other user problems included obligations, interests, or challenges that make it difficult to get groceries for cooking or go to restaurants in-person.

Pain points

Time

Working adults are too busy to spend time on meal prep.

Accessibility

Platforms for ordering food are not equipped with assistive technologies.

Information Architecture

Text-heavy menus in apps are often difficult to read and order from.

Persona

Pratyush

Age: 31 Education: MBBS Occupation: Doctor Hometown: Sambalpur, Odisha

"Healing the world and searching for tools that can help me live a better life"

Goals

Make time for each of his patients
To have easy access to healthy food

Frustrations

Having a busy schedule makes it difficult for him to prepare a meal

User journey map

Mapping Pratyush’s user journey revealed how helpful it would be for users to have access to a food delivery app.

Starting the design

Paper wireframes

Taking the time to draft iterations of each screen of the app on paper ensured that the elements that made it to digital wireframes would be well-suited to address user pain points. For the home screen, I prioritized a quick and easy ordering process to help users save time.

Digital wireframes

As the initial design phase continued, I made sure to base screen designs on feedback and findings from the user research.

Low-fidelity prototype

Using the completed set of digital wireframes, I created a low-fidelity prototype. The primary user flow I connected was selecting a restaurant and ordering food, so the prototype could be used in a usability study.

Usability study

I conducted two rounds of usability studies. Findings from the first study helped guide the designs from wireframes to mockups. The second study used a low-fidelity prototype and revealed what aspects of the mockups needed refining.

Round 1 findings

Users want to be able to edit quantity of food items from the review page as well

Round 2 findings

Refining the design

Early designs didn’t have a way to edit quantity from the Review page, but after the usability studies, I updated the Review order page to allow Quantity adjustments.

The second usability study revealed that the Sign Up page didn’t have a Sign In link. Added it.

High fidelity prototype

The final high-fidelity prototype presented cleaner user flows for ordering food and checkout. It also met user needs for payment on delivery option.

Play prototype

Accessibility considerations

Provided access to users who are visually impaired through adding alt text to images for screen readers.
Used icons to help make navigation easier.
Used detailed imagery for food items to help all users better understand the designs.

Takeaways

Impact

The app makes users feel the "Foodies" team thinks about how to meet their needs.

Quote from peer feedback

"The app made it so easy to select a restaurant and order food! I would definitely use this app for a delicious, fast, and healthy meal."

What I learned

While designing this app, I learned that the first ideas for an app are only the beginning of the process. Usability studies and peer feedback influenced each iteration of the app's designs.

Next steps

Conduct another round of usability studies to validate whether the pain points users experienced have been effectively addressed.

Conduct more user research to determine any new areas of need.

UX Design

Tue, 21 Feb 2023 00:00:00 +0000

Foodies

Food delivery mobile app.

View case study Play prototype

Foodies

Food delivery responsive web app.

View case study Play prototype

Blood Donor

Mobile app to help people donate or find blood donors.

View case study Play prototype

Web development

Tue, 21 Feb 2023 00:00:00 +0000

MATERIAL STYLE

A Material Design UI Library based on Bootstrap.

Read full blog Visit Material Style

CueSync

A JavaScript library designed to simplify the integration of interactive transcripts into multimedia content.

Visit CueSync

Marqueefy

A custom Marquee component used to create horizontal or vertical scrolling content.

Visit Marqueefy

Locked out of SSH after enabling UFW on Ubuntu EC2 instance?

Thu, 03 Jun 2021 00:00:00 +0000

Locked out of SSH after enabling UFW on Ubuntu EC2 instance?

The solution is to stop the instance and instruct it to disable the firewall program upon restart.

WARNING: Before starting this procedure, review the following:

Stopping and starting the instance erases any data on instance store volumes. Be sure that you back up any data on the instance store volume that you want to keep. For more information, see Determine the root device type of your AMI.
Stopping and restarting the instance changes the public IP address of your instance. It’s a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.

Stop your instance. (Do not terminate)
In the console, select your instance and go to Actions -> Instance Settings -> Edit user data

Select Modify user data as text and paste the following:

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
ufw disable
iptables -L
iptables -F
--//

Save and Restart the instance and SSH should work. The user data disables UFW and flushes any iptable rules blocking SSH access.
After successfully connecting via SSH, you may reset the user data by following previous steps. Select Modify user data as text, delete all text and save.

When a user data script is processed, it is copied to and run from /var/lib/cloud/instances/instance-id/. The script is not deleted after it is run. Be sure to delete the user data scripts from /var/lib/cloud/instances/instance-id/ before you create an AMI from the instance. Otherwise, the script will exist in this directory on any instance launched from the AMI.

Reference

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html

https://aws.amazon.com/premiumsupport/knowledge-center/execute-user-data-ec2/

Adding PHPUnit code coverage to SonarQube

Mon, 19 Apr 2021 00:00:00 +0000

Code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage.

We need Xdebug installed in our system to generate a code coverage report. Run the following commands (Linux) or check Xdebug installation instruction if the commands don’t work.

sudo apt-get install php-xdebug
sudo service apache2 restart

Generating code coverage

To generate code coverage, update phpunit.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/9.3/phpunit.xsd"
 bootstrap="vendor/autoload.php"
 cacheResultFile=".phpunit.cache/test-results"
 executionOrder="depends,defects"
 beStrictAboutOutputDuringTests="true"
 beStrictAboutTodoAnnotatedTests="true"
 failOnRisky="true"
 failOnWarning="true"
 verbose="true">

 <php>
 <server name="DOCUMENT_ROOT" value="ABSOLUTE_PATH_TO_DOCUMENT_ROOT"/>
 </php>

 <coverage cacheDirectory=".phpunit.cache/code-coverage">
 <include>
 <directory suffix=".php">src</directory>
 </include>
 <report>
 <clover outputFile="report/tests-clover.xml"/>
 <html outputDirectory="report"/>
 </report>
 </coverage>
 <testsuites>
 <testsuite name="default">
 <directory suffix="Test.php">tests</directory>
 </testsuite>
 </testsuites>
 <logging>
 <junit outputFile="report/tests-junit.xml"/>
 <testdoxHtml outputFile="report/testdox.html"/>
 </logging>
</phpunit>

And run tests:

./vendor/bin/phpunit

If you get a warning: XDEBUG_MODE=coverage or xdebug.mode=coverage has to be set, Run the tests as:

XDEBUG_MODE=coverage ./vendor/bin/phpunit

Viewing coverage in a browser

Output directory is set as report. So, open report/index.html on a browser to see the code coverage.

Adding Code Coverage to SonarQube

SonarQube uses coverage.report.clover and logging.junit to show code coverage.
coverage.report.html generates a code coverage report in HTML.
logging.testdoxHtml generates an HTML report containing a list of Test Cases written.
outputFile sets report path.

Add report paths to sonar properties file

sonar.tests=tests
sonar.php.tests.reportPath=report/tests-junit.xml
sonar.php.coverage.reportPath=report/tests-clover.xml

sonar.tests = path to the test directory of your project
sonar.php.tests.reportPath = path to junit report
sonar.php.coverage.reportPath = path to clover report

Exclude files that are not unit tested

sonar.test.exclusions=tests/app/**
sonar.coverage.exclusions=tests/app/**

sonar.test.exclusions = files excluded from unit tests
sonar.coverage.exclusions = files excluded from code coverage

Run Sonar scanner

Getting started with PHPUnit

Tue, 18 Aug 2020 00:00:00 +0000

A unit test provides a strict, written contract that a piece of code must satisfy. As a result, unit tests find problems early in the development cycle.

The goal is to isolate each part of the program and verify that it is correct.

PHPUnit is a well-known testing framework for PHP. It uses assertions to verify that a specific component or unit behaves as expected.

The purpose of this tutorial is to introduce you to the basics of PHPUnit.

Installation

Before we start writing our first unit test, we need to have PHPUnit installed. The installation process is documented at https://phpunit.de/.

Writing our first test

Before we begin,
Please Clone / Download the example code from GitHub.
Copy env.example.php to env.php and replace default values.
Create a DB phpunit and import sql/phpunit.sql.
Update ABSOLUTE PATH TO DOCUMENT ROOT in phpunit.xml.
Run composer install in the root directory.

To get started, we need something to test, so for the first example, I’ve written a simple PHP class Average that calculates the average of an array of integers.

src/Average.php

<?php declare(strict_types=1);

class Average
{
 private function ensureIsValidArrayOfIntegers(array $numbers): void
 {
 foreach ($numbers as $number) {
 if (!filter_var($number, FILTER_VALIDATE_INT)) {
 throw new InvalidArgumentException(
 sprintf(
 '"%s" is not a valid number',
 $number
 )
 );
 }
 }
 }

 public function getAverage(array $numbers): float
 {
 $this->ensureIsValidArrayOfIntegers($numbers);

 return array_sum($numbers) / count($numbers);
 }
}

Basic coventions for writing tests with PHPUnit:

The tests for a class Class go into a class ClassTest.
ClassTest inherits (most of the time) from PHPUnit\Framework\TestCase.
The tests are public methods that are named test*.
Alternatively, we can use the @test annotation in a method’s docblock to mark it as a test method.
Inside the test methods, assertion methods are used to assert that an actual value matches an expected value.

To ensure that our class Average works, we need to create a test class AverageTest that extends PHPUnit\Framework\TestCase.

tests/AverageTest.php

<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;

final class AverageTest extends TestCase
{
 /**
 * Test for an Exception if invalid argument type is passed.
 */
 public function testExceptionFromInvalidArgumentType(): void
 {
 $this->expectException(TypeError::class);

 $average = new Average();
 $verage->getAverage('string');
 }

 /**
 * Test for an Exception if invalid argument is passed.
 */
 public function testExceptionFromInvalidArgument(): void
 {
 $this->expectException(InvalidArgumentException::class);

 $average = new Average();
 $average->getAverage([1, 'a', 3, 4, 5]);
 }

 /**
 * Test for an Exception if an empty array is passed.
 */
 public function testExceptionFromEmptyArrayArgument(): void
 {
 $this->expectException(DivisionByZeroError::class);

 $average = new Average();
 $average->getAverage([]);
 }

 public function testGetAverage(): void
 {
 $average = new Average();
 $this->assertEquals(3.0, $average->getAverage([1, 2, 3, 4, 5]));
 }
}

Running our tests

Running our tests is as simple as calling the phpunit executable and pointing it at our tests. Here’s an example:

./vendor/bin/phpunit tests

Output

PHPUnit 9.5.0 by Sebastian Bergmann and contributors.

.... 4 / 4 (100%)

Time: 00:00.008, Memory: 4.00 MB

OK (4 tests, 4 assertions)

Fixtures (Setup & Teardown)

The purpose of a fixture is to ensure that there is a well known and fixed environment in which tests are run. This allows for tests to be repeatable, which is one of the key features of an effective test framework.

Examples:

Loading a database with a specific known set of data.
Preparation of input data as well as set-up and creation of mock objects.
Copying a specific known set of files

PHPUnit supports sharing the setup code. Before a test method is run, a template method called setUp() is invoked. setUp() is where we create the objects against which we will test. Once the test method has finished running, whether it succeeded or failed, another template method called tearDown() is invoked. tearDown() is where we clean up the objects against which we tested.

In AverageTest.php, it is tedious to instantiate Average class in each test case. So, we move it to setUp() and tearDown().

Also check tests/UserTest.php for another example.

tests/AverageTest.php

<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;

final class AverageTest extends TestCase
{
 protected $average;

 /**
 * This function is invoked before each test function.
 */
 protected function setUp(): void {
 $this->average = new Average();
 }

 /**
 * This function is invoked after each test function.
 */
 protected function tearDown(): void {
 unset($this->average);
 }

 /**
 * Test for an Exception if invalid argument type is passed.
 */
 public function testExceptionFromInvalidArgumentType(): void
 {
 $this->expectException(TypeError::class);

 $this->average->getAverage('string');
 }

 /**
 * Test for an Exception if invalid argument is passed.
 */
 public function testExceptionFromInvalidArgument(): void
 {
 $this->expectException(InvalidArgumentException::class);

 $this->average->getAverage([1, 'a', 3, 4, 5]);
 }

 /**
 * Test for an Exception if an empty array is passed.
 */
 public function testExceptionFromEmptyArrayArgument(): void
 {
 $this->expectException(DivisionByZeroError::class);

 $this->average->getAverage([]);
 }

 public function testGetAverage(): void
 {
 $this->assertEquals(3.0, $this->average->getAverage([1, 2, 3, 4, 5]));
 }
}

Data Providers

A test method can accept arbitrary arguments. These arguments are to be provided by one or more data provider methods. The data provider method to be used is specified using the @dataProvider annotation.

tests/AverageTest.php

/**
 * @dataProvider averageProvider
 */
public function testGetAverageUsingDataProvider(int $a, int $b, float $expected): void
{
 $this->assertSame($expected, $this->average->getAverage([$a, $b]));
}

public function averageProvider(): array
{
 return [
 [1, 2, 1.5],
 [3, 4, 3.5],
 [4, 2, 3.0],
 [4, 4, 4.0]
 ];
}

Test Doubles

When we are writing a test in which we cannot (or chose not to) use a real depended-on component (DOC), we can replace it with a Test Double. The Test Double doesn’t have to behave exactly like the real DOC; it merely has to provide the same API as the real one so that the system under test (SUT) thinks it is the real one!

The createStub and createMock methods can be used in a test to automatically generate an object that can act as a test double.

By default, all methods of the original class are replaced with a dummy implementation that returns null (without calling the original method). We can configure these dummy implementations to return a value when called Using the will($this->returnValue()) or simply willReturn method.

When the defaults used by the createStub and createMock methods do not match our needs then we can use the getMockBuilder method to customize the test double generation.

Please note that final, private, and static methods cannot be stubbed or mocked.

Stubs

The practice of replacing an object with a test double that (optionally) returns configured return values is referred to as stubbing. You can use a stub to replace a real component on which the SUT depends so that the test has a control point for the indirect inputs of the SUT.

Let’s stub ensureIsValidArrayOfIntegers method and skip validation.

tests/AverageTest.php

public function testStub(): void
{
 /**
 * createStub stubs all the methods in the stubbed class.
 * Here, ensureIsValidArrayOfIntegers and getAverage methods
 * won't be invoked from the Original Average class.
 */
 $stub = $this->createStub(Average::class);

 /**
 * Since we didn't specify the return values,
 * default values will be returned based on the functions return type.
 *
 * Return type of ensureIsValidArrayOfIntegers is void. So, nothing is returned.
 * Return type of getAverage is float. So, 0.0 is returned
 */
 $this->assertEmpty($stub->ensureIsValidArrayOfIntegers([1, 3.5, 3]));
 $this->assertEquals(0.0, round($stub->getAverage([1, 3.5, 3]), 2));
}

tests/AverageTest.php

public function testStubUsingMockBuilder(): void
{
 /**
 * Here we used getMockBuilder to stub just one method: ensureIsValidArrayOfIntegers.
 * This method won't be invoked.
 */
 $stub = $this->getMockBuilder(Average::class)
 ->setMethods(['ensureIsValidArrayOfIntegers'])
 ->getMock();

 $this->assertEmpty($stub->ensureIsValidArrayOfIntegers([1, 3.5, 3]));

 /**
 * Since, ensureIsValidArrayOfIntegers method is stubbed,
 * we are able to get an average even if we don't pass a valid array of Integers.
 *
 * getAverage method of the original Average class is invoked.
 */
 $this->assertEquals(2.5, round($stub->getAverage([1, 3.5, 3]), 2));
}

Mock Objects

The practice of replacing an object with a test double that verifies expectations, for instance asserting that a method has been called, is referred to as mocking.

Let’s create a class Logger that logs a string.

src/Logger.php

<?php declare(strict_types=1);

class Logger
{
 public function log($text): void
 {
 echo $text;
 }
}

We will add a method to the Average class that uses Logger’s log method to log average.

src/Average.php

public function logAverage(array $numbers, Logger $logger): void
{
 $this->ensureIsValidArrayOfIntegers($numbers);

 $logger->log(array_sum($numbers) / count($numbers));
}

Now let’s Mock Logger and test if log method is called.

tests/AverageTest.php

public function testMock(): void
{
 /**
 * Here, we are mocking log method of Logger class,
 * just to ensure that it is called with the specified arguments.
 * The Average class does not need to verify what happens within the Logger log method.
 */
 $mockObject = $this->createMock(Logger::class);
 $mockObject->expects($this->once())
 ->method('log')
 ->with(2.0);

 $this->average->logAverage([1, 2, 3], $mockObject);
}

XML Configuration

phpunit.xml file can be used to compose a test suite and specify other configurations. The following is an xml configuration that will add all *Test classes that are found in *Test.php files when the tests directory is recursively traversed.

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/9.3/phpunit.xsd"
 bootstrap="vendor/autoload.php"
 cacheResultFile=".phpunit.cache/test-results"
 executionOrder="depends,defects"
 beStrictAboutOutputDuringTests="true"
 beStrictAboutTodoAnnotatedTests="true"
 failOnRisky="true"
 failOnWarning="true"
 verbose="true">

 <php>
 <server name="DOCUMENT_ROOT" value="ABSOLUTE_PATH_TO_DOCUMENT_ROOT"/>
 </php>

 <testsuites>
 <testsuite name="default">
 <directory suffix="Test.php">tests</directory>
 </testsuite>
 </testsuites>
</phpunit>

running our tests

./vendor/bin/phpunit

Code Coverage

To generate code coverage, update phpunit.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/9.3/phpunit.xsd"
 bootstrap="vendor/autoload.php"
 cacheResultFile=".phpunit.cache/test-results"
 executionOrder="depends,defects"
 beStrictAboutOutputDuringTests="true"
 beStrictAboutTodoAnnotatedTests="true"
 failOnRisky="true"
 failOnWarning="true"
 verbose="true">

 <php>
 <server name="DOCUMENT_ROOT" value="ABSOLUTE_PATH_TO_DOCUMENT_ROOT"/>
 </php>

 <coverage cacheDirectory=".phpunit.cache/code-coverage">
 <include>
 <directory suffix=".php">src</directory>
 </include>
 <report>
 <clover outputFile="report/tests-clover.xml"/>
 <html outputDirectory="report"/>
 </report>
 </coverage>
 <testsuites>
 <testsuite name="default">
 <directory suffix="Test.php">tests</directory>
 </testsuite>
 </testsuites>
 <logging>
 <junit outputFile="report/tests-junit.xml"/>
 <testdoxHtml outputFile="report/testdox.html"/>
 </logging>
</phpunit>

And run tests:

./vendor/bin/phpunit

If you get a warning: XDEBUG_MODE=coverage or xdebug.mode=coverage has to be set, Run the tests as:

XDEBUG_MODE=coverage ./vendor/bin/phpunit

Output directory is set as report. So, open report/index.html on a browser to see the code coverage.

I hope this is a good introduction to the world of unit testing. Even though there are several topics I’ve not touched on, I’ve tried to give you a good point where you can start writing your tests.

Material Style - A UI Library

Tue, 08 Jan 2019 00:00:00 +0000

A year ago, I was involved in a project with the requirement to have Material Design styles and animations for the UI. Like always, I looked for frameworks or libraries that met the design specification.

The first library that I came across was Material Design Lite.
It is a super lightweight library that didn’t rely on any JavaScript frameworks. Unfortunately, it didn’t have essential components such as Select Boxes. Having found it inadequate, I moved on for the next.

MD Bootstrap
It was a popular library built on top of Bootstrap. I was curious to see if it could fulfil the requirement. Once again, I was left disappointed because the styles and animations were not as per the Material Design Guidelines. Moreover, we could not use all its components unless we purchased the PRO version of it.

Materialize
Developed by a team of students from Carnegie Mellon University, it was a complete framework that didn’t depend on Bootstrap or jQuery. But, like MD Bootstrap, the animations were not as per the Material Design Guidelines.

Thus, I still did not have any luck going my way with finding a suitable Material Design package.

And then I decided to use Bootstrap as it is and write my CSS and JS on top of it to fulfil the project’s requirement. It gave me an idea to create a UI wrapper which would have all the bootstrap components, look and behave as per the Material Design Guidelines. I set about developing it and six months later, with some hard work, research and sleepless nights, Material Style was born.

Material Style is now an easy to use UI Library based on Bootstrap 4.5 that lets you add Material Design styles and animations to Bootstrap components.

Visit Material Style

Few Components from Material Style

Firstname

Select One