PHP Code Sniffer is a tool to detect violations of a defined coding standard such as PSR2. Read more about it here: https://github.com/squizlabs/PHP_CodeSniffer

If you would also like to check out the accompanying YouTube video, here’s the link:

Now let’s go ahead and set it up.

1. Add Code Sniffer to composer.json file

First we need to include a dependency for squizlabs/php_codesniffer in our composer.json file. For example:

{
    "require-dev": {
        "squizlabs/php_codesniffer": "3.*"
    }
}

2. Install the dependency through PHPStorm’s interface

Then let’s go to our project’s composer.json file in PHPStorm, and click “Install”.

This should run composer update…

How reliable are the tests we write? Are they covering the edge cases? What happens when the code changes? Do the tests still pass?

Welcome to testing our tests. Of course to make any tests reliable it has to cover all the edge cases that an application may find itself in. Testing both the correct input flow and wrong input flow, throwing unexpected inputs, dealing with exceptions and security issues come into the picture. All these steps and thought processes help us write good tests and various test cases to cover it all.

But what if we could automate at…

Hey there, welcome to part 4! Today we’ll learn how to mock. Mocking is a process where you create a fake instance of a real class, and test against it. This is so that, you do not have to worry about the real functionality of external dependencies inside a class. This makes unit testing a lot easier and reliable.

Please check out Part3, if you have not read it yet: https://hackernoon.com/php-test-driven-development-part-3-unit-testing-continued-db5d332197ec

Although PHPUnit does have mocking capabilities, it is not as full fledged as that of Mockery’s (http://docs.mockery.io/en/latest/). We’ll be using Mockery for all our mocking needs. Another good thing…

Now continuing from Part 2, let’s revisit the test we were looking at:

Please check out Part 2, if you have not read it yet: https://hackernoon.com/php-test-driven-development-part-2-unit-testing-c327ba3fbf14

If you would also like to check out the accompanying YouTube video, here’s the link:

We learned that asserts are statements that we use to verify or check if our output is what we need.

Here, we are checking if “true” is true. Which is obvious duh, right? This test is really of no use to us. It does not test any of our code. …

All right, welcome to part 2 of “PHP Test Driven Development” series. Today we will go through the PHPUnit setup in detail.

Please check out Part 1, if you have not read it yet: https://hackernoon.com/php-test-driven-development-part-1-introduction-5483362d79b5

If you would also like to check out the accompanying YouTube video, here’s the link:

We will be using the Laravel framework to make it easier for us to get started. It will also help me to show you how to do testing for real life applications.

I will assume you have used Laravel before. This will help me focus on the testing side…

Test Driven Development is a coding practice where you write a test first then write the code to pass that test, usually in a short iterative cycle.

Test Driven Development (TDD), was popularized by Kent Beck. TDD is one of the main techniques followed in his Extreme Programming software development methodology.

If you would also like to check out the accompanying YouTube video, here’s the link:

Now let’s visualize TDD in steps:

1. Write a test (enough to make it fail)
2. Run it, and see it fail.
3. Write the code.
4. Run the test again and see it pass.
5. Repeat Step…

All right. Let’s go over and refactor our code from part one.

Let’s once again look at our FlightController:

First of all let’s move saveData() into a Repository class. It’s easy since all the Database related code is in this method. For your own code base, if you do not have a separate method, we would have to do that first. This makes it easier to move it into a different layer.

Now this is our FlightRepository class:

All we did was move the “saveData” method from the controller to its own separate class.

For the “log” method…

When I first started using this architecture, I had no name for it. But having a name will make it easier for us to remember it. Let’s call it the “Extensible Architecture”. That is because, it is basically an extension to MVC. We just added new design patterns and layers to bring shape to this architecture.