DEV Community: Joshua Johnson

FireStudio Video Tutorial - Debug Panels

Joshua Johnson — Sat, 23 Nov 2019 03:15:51 +0000

https://www.youtube.com/watch?v=yZmFjVfCZ4U

Sharing a video I just uploaded as a tutorial and introduction video to FireStudio, a Wordpress plugin packed with tools for developers.

Wordpress Action Hooks Order of Execution

Joshua Johnson — Tue, 19 Nov 2019 14:55:24 +0000

https://ua1.us/updates/wordpress/wordpress-hook-order-of-execution/

The Vision for FireStudio and Our Other UA1 Labs’ PHP “Fire” Libraries

Joshua Johnson — Fri, 08 Nov 2019 20:00:51 +0000

At UA1 Labs, over the past 2-3 years we have been busy building out a software suite we call FireStudio. FireStudio, and its accompanying libraries (FireTest, FireBug, FireDi, FireSQL), have all been actively developed for one reason. To enable web users to secure their privacy on the web and services on the web. With the focus of technology on cloud, big data, and machine learning, we have a growing concern of what that means for the average user of the web and their privacy.

To achieve data privacy we want to make it simple enough for each person to own their data and be able to distribute it via their personal API.

Background

Early on in my career, I recognized an issue with the web. Using any web services would force me to give up my privacy. Everything I do on the web is being tracked, analyzed, and used to target a reaction from me. Most of the time, I’m being targeting to make a purchase, and sometimes I’m targeted to react with an action. Major tech companies have gotten so good at targeting reactions and behaviors, they can even predict, within a certain accuracy, what your reaction will be based on the collection of data they have about you and other people. I don’t want to live in that world.

History of FireStudio

Ever since I’ve learned to code, I’ve had a continuation of a dream to build out a system that would allow users of the web to control how their data is used. There has been many variations and implementations of this idea over the past 15 years I’ve been developing.

Zoose

For me, it all started with Zoose. My very first attempt at building out a PHP application. It was a CMS that used the concept of editable content to allow users to edit titles/images/content directly within the webpage they were viewing. At the time, it felt like working in word. The framework itself featured a flat file database as I wasn’t sure what MySQL was or how to use it. So I built my own. http://buildzoose.com was created with a forum and I attempted to open source it. The framework ended up being used in several client’s production servers and did well for a bit. One client still uses it today to run their listing website.

Z20 (or Zoose 2.0)

After learning about some design patterns and becoming more mature with my coding practices, I realized how hard Zoose was to maintain. So I decided to start rebuilding Zoose on another code base. This time I would centralize my approach around Dependency Injection. Z20 was a short lived iteration. As a framework built around DI isn’t really a framework at all. Z20 would eventually become Ulfberht, which would then turn into FireDi. I built many different projects with this framework including a Twitter bot that would allow users to tweet pixel information at it that would place that pixel on a canvas in an experiment we called “Social Art” (https://twitter.com/tweetcreate).

This framework became more about making money and less about driving innovation around the cause of data privacy on the web. For me, everything I’ve built, the end goal was to build tools that would allow for a decentralized web that would still allow people to share info, photos, likes, etc. After realizing that things weren’t going in the direction I wanted them to, I decided to pivot yet again and refocus my efforts towards pure data privacy.

FireStudio

The idea for FireStudio was born. I decided I would take everything I’ve learned and focus all of my energy on solving the problem I had set out to solve 10 years earlier. I mapped out everything I would need to solve this problem and would just start building. I needed debug tools, testing automation tools, a way to connect to a database, security tools. Everything I would need I listed.

FireDB

One of the first things I set my effort on was to build a database that would allow users to secure data. I wanted a NoSQL database that would allow users to store any type of data that they wanted to. But I didn’t want users to have to deal with, “well how do I setup a MongoDB instance to connect to my application?” Sure there is cloud solutions for stuff like this, but that stuff is hard. Especially for the average web user.

This would become a 4 month journey to build my own flat file database system that users could just download and use. Now archived https://github.com/joshualjohnson/firedb.

FireSQL

Along the way of building out FireDB, I found that the database itself wasn’t very performant after you got to more than 2 million records within a collection. All of the features I wanted were there, but I wanted the database itself to be more performant than it was. So, I took all that I had learned in FireDB and applied it to FireSQL. A solution that would take a SQL database and make it into a NoSQL database. I settled on this as a solution because most LAMP services provide MySQL out of the box.

FireBug

FireBug came along because I needed to debug FireSQL/FireDB as I was building it. I wanted the more efficient way to debug and I needed more than just var_dump. I wanted to know how long queries were taking, performance of code, etc. So I created FireBug as a way to have a debug panel that could have all of the things I needed.

By the way, FireBug’s name was a total accident and was never meant to step on the heals of FireBug the Firefox extension. More about that here https://ua1.us/updates/firebug/why-did-the-firebug-php-debug-panel-project-copy-its-name-from-the-dev-tools-built-for-firefox/

FireTest

FireTest came along because when I was building out FireSQL/FireDB, I needed a way to test multiple scenarios as I was developing. The scope grew too big for me to manually test all of its functionality every time I went to add new functionality. So I build out a test automation tool that allowed me to verify everything was still working as expected.

FireDi

As mentioned before, this originally came from Z20.

Finally FireStudio

It took me a little under 2 years to write all of the code I would need to create all of the components of FireStudio. But yet I still have no app for a user to run that will allow them to share their data on the web without sacrificing privacy! I envision FireStudio to be an application that runs on a server. Which will allow a user to host their own data via a restful API. One that they own and control who can access it. I would like to see apps created that could be used to access individual user api’s. Rather than having to host a user’s data, I would like to see these apps simply consume their data.

I started to build out a stand alone application, but recently decided to ship this as a WordPress plugin.

Why Put FireStudio In WordPress Plugin?

For me, the answer is simple. The vision for WordPress and the vision for FireStudio are pretty much inline. WordPress wants to make it possible for the world to share information. FireStudio wants to make it possible to share data.

The post The Vision for FireStudio and Our Other UA1 Labs’ PHP “Fire” Libraries appeared first on UA1 Labs.

FireBug – Adding Your Own Debug Panels

Joshua Johnson — Fri, 08 Nov 2019 04:17:21 +0000

In this tutorial, we will cover how to add your own debug panels to FireBug. This feature of FireBug is what really make it a useful tool for what you are developing! Since I recently integrated FireBug into a WordPress Plugin, we will be using this use case for our tutorial today. One goal we had when doing this integration was to add a custom debug panel that would give us all of the SQL Queries that WordPress makes when loading a page.

Start Creating Your Custom Panel

For this tutorial, we are going to assume you’ve successfully integrated FireBug into your project. To recap the simplest integration looks like this:

<?php
$fireBug = \UA1Labs\Fire\Bug::get();
$fireBug->enable();
echo $fireBug->render();

A custom FireBug debug panel consists of two parts. The class that represents the content of the panel. And the template that is bound to the class to render the results you are looking for. So let’s start by building out your class.

<?php
namespace UA1Labs\Fire\Studio\Feature\Debug\Panel;
use \UA1Labs\Fire\Bug\Panel;
class WpSqlQueries extends Panel
{
    const ID = 'wpsqlqueries';
    const NAME = 'Wordpress SQL {{count}}';

    public function __construct()
    {
        parent::__construct(self::ID, self::NAME,__DIR__. '/../templates/panels/sql-queries.phtml');
    }
}

Above you will find an example of the basic boilerplate code to start building out the data for your panel. Of course, there are so many ways to create the class. This is the way we do it at UA1 Labs. Other implementations are acceptable as well.

Notice, we have included a template file within our parent constructor. So let’s go ahead and get the boilerplate code prepared for that part of the custom panel we are creating.

<?php
// nothing to display yet ;)

Now that you have the basic boiler plate, we can go ahead and start adding the code that will display our queries.

Our Custom Code For Displaying WP Queries

Before we get started adding our custom code, let’s first talk about how WordPress gives us the information about the queries it runs to load a page. WordPress has a configuration, that when turned on, will store the settings in its global $wpdb object. So for us to even get these queries, we can simply add define(‘SAVEQUERIES’, true); within our code.

The post FireBug – Adding Your Own Debug Panels appeared first on UA1 Labs.

FireTest – Example Unit Testing Individual Classes Without A Framework

Joshua Johnson — Mon, 28 Oct 2019 21:27:32 +0000

I recently got a request on how you might Unit Test an individual class that doesn’t belong to a framework. So, here’s an example class we will be unit testing using FireTest.

Let’s start out by creating a new project from scratch:

mkdir fire-test-example
cd fire-test-example
composer init
...
composer require ua1-labs/firetest

Now, update composer.json to include the test runner file script.

"scripts": {
    "test": "php vendor/ua1-labs/firetest/scripts/runner.php --dir=/. --ext=.TestCase.php"
}

Now let’s create our example class at src/FormPost.php

<?php

use \Exception;

class FormPost
{
    public $writeToDb;

    public function __construct()
    {
        $this->writeToDb = false;
    }

    public function handleFormPost()
    {
        $firstName = isset($_POST['firstName']) ? $_POST['firstName'] : '';
        $lastName = isset($_POST['lastName']) ? $_POST['lastName'] : '';
        if ($this->validateFormData($firstName, $lastName)) {
            $this->writeToDatabase($firstName, $lastName);
        } else {
            throw new Exception('Please fill in all form data.');
        }
    }

    private function validateFormData($firstName, $lastName)
    {
        // code to verify form data
        if (!$firstName || !$lastName) {
            return false;
        }

        return true;
    }

    private function writeToDatabase()
    {
        // code to write to database
        $this->writeToDb = true;
    }

}

Now add it to Composer’s Autoload schema by adding the following lines to the composer.json file.

"autoload": {
    "files": ["src/FormPost.php"]
}

Now, let’s create our src/FormPost.TestCase.php file. I’ve already created the unit test scenarios we are going to test for.

<?php

use \UA1Labs\Fire\Test\TestCase;

class FormPostTestCase extends TestCase
{

    private $formPost;

    public function beforeEach()
    {
        $_POST = [];
        $this->formPost = new FormPost();
    }

    public function testHandleFormPost()
    {
        $this->should('Validate a form and write the values to a database.');
        $_POST['firstName'] = 'UA1';
        $_POST['lastName'] = 'LABS';
        $this->formPost->handleFormPost();
        $this->assert($this->formPost->writeToDb === true);
    }

    public function testHandleFormPostBadRequest()
    {
        $this->should('Throw an Exception because form data is missing.');
        try{
            $this->formPost->handleFormPost();
            $this->assert(false);
        } catch (Exception $e) {
            $this->assert(true);
        }
    }

}

Now that you have your Class and your TestCase file, you are ready to run the unit tests. Remember before we added a run script to the composer.json file? We are now going to run that.

composer run test

Or just run the runner script using the PHP command:

php vendor/ua1-labs/firetest/scripts/runner.php --dir=/. --ext=.TestCase.php

You will get the following results:

FireTest: *************************************************************
FireTest: ███████╗██╗██████╗ ███████╗████████╗███████╗███████╗████████╗
FireTest: ██╔════╝██║██╔══██╗██╔════╝╚══██╔══╝██╔════╝██╔════╝╚══██╔══╝
FireTest: █████╗ ██║██████╔╝█████╗ ██║ █████╗ ███████╗ ██║   
FireTest: ██╔══╝ ██║██╔══██╗██╔══╝ ██║ ██╔══╝ ╚════██║ ██║   
FireTest: ██║ ██║██║ ██║███████╗ ██║ ███████╗███████║ ██║   
FireTest: ╚═╝ ╚═╝╚═╝ ╚═╝╚══════╝ ╚═╝ ╚══════╝╚══════╝ ╚═╝   
FireTest: *************************************************************
FireTest: [STARTING] Test suite is located at "/home/tutorials/fire-test-example/src"
FireTest: [STARTING] Finding all files with the extension ".TestCase.php"
FireTest: [LOADING] Test file "/home/tutorials/fire-test-example/src/FormPost.TestCase.php"
FireTest: [LOADING] Test class "FormPostTestCase"
FireTest: [RUNNING] FormPostTestCase::testHandleFormPost()
FireTest: [PASSED] Validate a form and write the values to a database.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] FormPostTestCase::testHandleFormPostBadRequest()
FireTest: [PASSED] Throw an Exception because form data is missing.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: ***********************************************************
FireTest: ███████╗██╗ ██╗ ██████╗ ██████╗███████╗███████╗███████╗
FireTest: ██╔════╝██║ ██║██╔════╝██╔════╝██╔════╝██╔════╝██╔════╝
FireTest: ███████╗██║ ██║██║ ██║ █████╗ ███████╗███████╗
FireTest: ╚════██║██║ ██║██║ ██║ ██╔══╝ ╚════██║╚════██║
FireTest: ███████║╚██████╔╝╚██████╗╚██████╗███████╗███████║███████║
FireTest: ╚══════╝ ╚═════╝ ╚═════╝ ╚═════╝╚══════╝╚══════╝╚══════╝
FireTest: ***********************************************************
FireTest: [FINAL] (Passed: 2, Failed: 0)

Happy coding!

The post FireTest – Example Unit Testing Individual Classes Without A Framework appeared first on UA1 Labs.

How do you solve the data privacy issues of the internet?

Joshua Johnson — Mon, 28 Oct 2019 16:36:32 +0000

If you could invent a solution that solves the problem of data privacy what does that look like?

PHP Unit Tests with FireTest and FireDI

Joshua Johnson — Sat, 26 Oct 2019 16:45:03 +0000

As we talked about before, at UA1 Labs, we were interested in testing our PHP code, but didn’t want to deal with the overhead and complexity of the current PHP testing frameworks. We thought we could make it simpler. So we created our own PHP test automation framework (FireTest). Along with FireTest, we created a Dependency Injection library (FireDI). When building out FireDI, we decided to add functionality that would allow us to easily mock our dependencies so that that isolating our classes and testing our code would be easy.

A little disclaimer here: As we share our best practices and code examples, we realize that our ideal workflows and best practices might not match with what you feel works best for you. As we have learned, there are multiple ways to code a project. This is what we find works best for us.

Writing Unit Tests with FireTest and FireDI

In this tutorial, we will cover our best practices for using FireTest along with FireDI to write unit tests for our PHP code. If you don’t already have FireTest setup in your project, you can follow our Getting Started Guide to get it setup.

Writing tests for MyClass:

<?php

use \MyDependency;

class MyClass 
{
    private $myDependency;

    public function __construct(MyDependency $myDependency)
    {
        $this->myDependency = $myDependency;
    }

    public function myLogicalFunction()
    {
        if ($this->myDependency->isLogicalToDoSo()) {
            return true;
        }
        return false;
    }
}

As you can see in the MyClass example above, to test the myLogicalFunction(), you will need to create test cases for both when $this->myDependency->isLogicalToDoSo() returns true, and when it returns false.

With FireDI, you’ll be able to mock the MyDependency class.

use \UA1Labs\Fire\Test\TestCase;
use \UA1Labs\Fire\Di;
use \MyClass;

class MyClassTestCase extends TestCase
{
    private fireDi;
    private myClass;

    public function setUp()
    {
        $this->fireDi = new Di();
    }

    public function tearDown()
    {
        unset($this->fireDi);
    }

    public function testMyLogicalFunction()
    {
        $this->fireDi->set('MyDependency', new MyDependencyMock());
        $myDependency = $this->fireDi->get('MyDependency');
        $myClass = $this->fireDi->get('MyClass');

        $this->should('Return true when MyDependency::isLogicalToDoSo() returns true');
        $myDependency->isLogicalToDoSoValue = true;
        $this->assert($myClass->myLogicalFunction() === true);

        $this->should('Return false when MyDependency::isLogicalToDoSo() returns false');
        $myDependency->isLogicalToDoSoValue = false;
        $this->assert($myClass->myLogicalFunction() === false);
    }

}

class MyDependencyMock
{
    public $isLogicalToDoSoValue;

    public function isLogicalToDoSo()
    {
        return $this->isLogicalToDoSoValue;
    }
}

In the test case above, you will see where MyDependency was mocked with MyDependencyMock using $this->fireDi->set('MyDependency', new MyDependencyMock());. We then used FireDI to gain access to the instance of MyDependencyMock so that we could set the variable isLogicalToDoSoValue. This is so when MyClass called the isLogicalToDoSo() method, it would return the desired value of true or false, depending on which test case you were testing for.

The post PHP Unit Tests with FireTest and FireDI appeared first on UA1 Labs.

FireDI Release 2.1.0

Joshua Johnson — Fri, 18 Oct 2019 10:34:44 +0000

FireDI 2.1.0 was just released. Here’s what’s new:

Implemented PSR-11 Container Interface. Here’s what that means. FireDI is compliant with an agreed upon standard for how you should implement a container of objects.
Updated code base to follow PSR-2 Coding Standards. In a previous work situation, we followed Zend 1.* standards for coding. I adopted many of those not working on a modern framework. I had to update the code base to be compliant with PSR-2.
Implemented Di::has(). As part of the PSR-11 standard, I had to add a method to determine if this particular container “has” an object in it. So what that means under the hood is can this container resolve what you are asking for.
Updated the Di::set() interface to take in a callable and updated the logic of dependency resolution to invoke the callable as part of resolving the dependency. That means you can set factories to return objects for specific dependencies.
Included an MIT license! This way you can trust that the code you are using cannot be taken back from you.

The post FireDI Release 2.1.0 appeared first on UA1 Labs.

FireDI – Advanced Use Cases

Joshua Johnson — Thu, 17 Oct 2019 22:25:46 +0000

FireDI can do a lot more than just resolve your dependencies for you. This tutorial, we are going to cover other scenarios where FireDI can become helpful.

For Mocking In Test Cases

When working on testing your code, you will find that from time to time, you will need to mock a dependency for the class you are testing.

<?php
class TheClassImTesting {
    public function __construct(MyDependentClass $myDependentClass) {}
}

Now to mock MyDependentClass!

<?php
$fireDi = new \UA1Labs\Fire\Di();
$myDependentClassMock = Mock::get('MyDependentClass');
$fireDi->set('MyDependentClass', $myDependentClassMock);

$theClassImTesting = $fireDi->get('TheClassImTesting');

For Injecting New Objects Every Time

By default, FireDI will cache all objects (including object dependencies) within the container object cache. This is so the next time you need the object, it is already ready for you and is just simply returns. From time to time, however, you may need for a specific object to return a new instance every time it is needed.

<?php
// to prevent an object from caching, you may pass a factory into the Di::set() method.

$fireDi = new \UA1Labs\Fire\Di();
$fireDi->set('MyNewObjectEveryTime', function() {
    new MyNewObjectEveryTime();
});

For Interface Dependencies

In many cases, you might have a class that has a constructor dependency on an interface.

<?php
inteface MyInterface {}

class MyClass implements MyInterface {}

class InterfaceDependentClass 
{
    public function __construct(MyInterface $MyInterface) {}
}

In the example above, you will notice that InterfaceDependentClass depends on an object that implements MyInterface. If you want to resolve this, you would need to new MyClass() and pass the resulting instance object into the InterfaceDependentClass constructor. Or you can simply have FireDI do that for you!

<?php
$fireDi = new \UA1Labs\Fire\Di();
$myClass = $fireDi->get('MyClass');
$fireDi->set('MyInterface', $myClass);

$interfaceDependentClass = $fireDi->get('InterfaceDependentClass');

The post FireDI – Advanced Use Cases appeared first on UA1 Labs.

What's Your Favorite PHP Test Automation Tools?

Joshua Johnson — Wed, 16 Oct 2019 13:29:53 +0000

FireTest – Getting Started

Joshua Johnson — Mon, 14 Oct 2019 21:19:37 +0000

Getting started with FireTest is easy. Our goal with FireTest was to make it as simple as possible to integrate it into your project and start writing tests for the code you’ve written.

Install FireTest

composer require ua1-labs/firetest

Create Your First Test

Creating test cases in FireTest is as simple as adding a TestCase class and running the FireTest runner.php script. Your first step into creating FireTest Test Cases are to find the class you’d like to test. Create a file in the same directory and call it {classname}.TestCase.php. Copy and paste the boiler plate code into the newly created Test Case file.

<?php

use UA1Labs\Fire\Test\TestCase;

class MyTestCase extends TestCase
{
    //my test suite logic
}

Now you may use event hook methods to bootstrap your tests.

Event Hook Methods In Test Cases

With every test that you write, you will need to setup the environment to setup your test environment to run your code in. For example, almost for every test you write, you will first need to obtain a new instance of the object you are testing. Event Hook Methods are going to give you the ability to do this.

setUp() A method that is invoked when the when the testcase is first intialized.
beforeEach() A method that is invoked before each test method is invoked.
afterEach() A method that is invoked after each test method is invoked.
tearDown() A method that is invoked when the test case is finish running all test methods.

Test Methods

Test methods are another kind of event hook. The test method is where you will actually test your code. FireTest will loop through each of these test methods and execute the code. These methods are ran between the beforeEach() and afterEach() method.

Test methods begin with the work “test.” This is how FireTest dictates if it should be running the method during the testing phase of the life cycle. You can name the method whatever you want, however, it will need to begin with the work test (all lowercase).

public function testMyCode1()
{
    // my test code here
}

public function testMyCode2()
{
    // my test code here
}

Testing Your Code

Once you have mastered the event hooks and have setup your testing environment, you will then need to be able to tell what test are you running and how you will prove that it was successful. that is where the should() and assert() methods come in. To write tests start out by telling what this test is going to prove using a should statement. Think of testing like saying “this test should…” and fill in the blank.

$this->should('Return a number when I pass in a number.');
$result = my_number_converter(4);
$this->assert(is_number($result));

Now Run FireTest Runner.php

FireTest has a built in test runner so that you don’t have to bootstrap your own test suites together. Simply run the following command from the root directory of your project and watch FireTest do its thing.

php vendor/ua1-labs/firetest/scripts/runner.php

Test Results

Test results will then provide you with feedback whether your tests have passed or not.

ua1-labs:firedi josjohns$ php vendor/ua1-labs/firetest/scripts/runner.php
FireTest: *************************************************************
FireTest: ███████╗██╗██████╗ ███████╗████████╗███████╗███████╗████████╗
FireTest: ██╔════╝██║██╔══██╗██╔════╝╚══██╔══╝██╔════╝██╔════╝╚══██╔══╝
FireTest: █████╗ ██║██████╔╝█████╗ ██║ █████╗ ███████╗ ██║   
FireTest: ██╔══╝ ██║██╔══██╗██╔══╝ ██║ ██╔══╝ ╚════██║ ██║   
FireTest: ██║ ██║██║ ██║███████╗ ██║ ███████╗███████║ ██║   
FireTest: ╚═╝ ╚═╝╚═╝ ╚═╝╚══════╝ ╚═╝ ╚══════╝╚══════╝ ╚═╝   
FireTest: *************************************************************
FireTest: [STARTING] Test suite is located at "/home/projects/firedi"
FireTest: [STARTING] Finding all files with the extension ".TestCase.php"
FireTest: [LOADING] Test file "/home/projects/firedi/UA1Labs/Fire/Di/Graph.TestCase.php"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\Di\GraphTestCase"
FireTest: [LOADING] Test file "/home/projects/firedi/UA1Labs/Fire/Di/ClassDefinition.TestCase.php"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\Di\ClassDefinitionTestCase"
FireTest: [LOADING] Test file "/home/projects/firedi/UA1Labs/Fire/Di.TestCase.php"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\DiTestCase"
FireTest: [LOADING] Test file "/home/projects/firedi/vendor/ua1-labs/firetest/UA1Labs/Fire/Test/TestCase.TestCase.php"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\Test\TestCaseTestCase"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\Test\TestCaseMock"
FireTest: [LOADING] Test file "/home/projects/firedi/vendor/ua1-labs/firetest/UA1Labs/Fire/Test/Suite.TestCase.php"
FireTest: [LOADING] Test class "Test\UA1Labs\Fire\Test\SuiteTestCase"
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testConstructor()
FireTest: [PASSED] Not throw an exception when the class is constructed
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testAddResource()
FireTest: [PASSED] Add a resource to the resource graph.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testAddDependencies()
FireTest: [PASSED] Add dependencies to a resource.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testAddDependency()
FireTest: [PASSED] Add a dependency to a resource.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testRunDependencyCheck()
FireTest: [PASSED] Return an error code of "1" (Resourece Not Found).
FireTest: [PASSED] Contain which resource was missing.
FireTest: [PASSED] Return and error code "2" (Circular Dependnecy).
FireTest: [PASSED] Contain the resource of which caused the circular dependency.
FireTest: [RESULT] (Passed: 4, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testGetDependencyResolveOrder()
FireTest: [PASSED] Resolve dependencies in the order they need to be resolved.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\GraphTestCase::testResetDependencyCheck()
FireTest: [PASSED] Reset a dependency check.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Di\ClassDefinitionTestCase::testConstructor()
FireTest: [PASSED] Not throw an exception when the class is constructed
FireTest: [PASSED] Have set a serviceId of "Test\UA1Labs\Fire\Di\MyTestClass".
FireTest: [PASSED] Have set a classDef as a ReflectionClass object.
FireTest: [PASSED] Have set a dependency of "Test\UA1Labs\Fire\Di\MyDependentClass"
FireTest: [RESULT] (Passed: 4, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testConstructor()
FireTest: [PASSED] The constructor should not throw an execption and be an instance of Di.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testPutObject()
FireTest: [PASSED] Put an object in the cache without an exception.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testGetObject()
FireTest: [PASSED] Resolve all dependencies for TestClassA and return the TestClassA object.
FireTest: [PASSED] Have placed TestClassA, TestClassB, and TestClassC within the object cache.
FireTest: [PASSED] Resolve all dependencies for TestClassD and return it.
FireTest: [PASSED] Have set ::A as TestClassA on TestClassD object.
FireTest: [PASSED] Have set ::B as TestClassB on TestClassD object.
FireTest: [PASSED] Have set ::C as TestClassC on TestClassB.
FireTest: [PASSED] Throw an exception if a the class you are trying to get does not exists.
FireTest: [PASSED] Throw an exception if a circular dependency is detected.
FireTest: [RESULT] (Passed: 8, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testGetWithObject()
FireTest: [PASSED] Return a TestClassB object.
FireTest: [PASSED] Prove that TestClassB has a $C variable that is TestClassC.
FireTest: [PASSED] Prove that the object cache does not contain a TestClassB
FireTest: [PASSED] Throw and exception if a the class you are trying to get does not exists.
FireTest: [RESULT] (Passed: 4, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testGetObjectCache()
FireTest: [PASSED] Return an object cache array with a key "TestObject".
FireTest: [PASSED] Return an object cache with the object we put into it.
FireTest: [RESULT] (Passed: 2, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\DiTestCase::testClearObjectCache()
FireTest: [PASSED] Remove all objects from the object cache
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Test\TestCaseTestCase::testConstructor()
FireTest: [PASSED] Return an instance object of the TestCase object without throwing an exception.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: [RUNNING] Test\UA1Labs\Fire\Test\SuiteTestCase::testConstructor()
FireTest: [PASSED] Return an instance object of the Suite object without throwing an exception.
FireTest: [RESULT] (Passed: 1, Failed: 0)
FireTest: ***********************************************************
FireTest: ███████╗██╗ ██╗ ██████╗ ██████╗███████╗███████╗███████╗
FireTest: ██╔════╝██║ ██║██╔════╝██╔════╝██╔════╝██╔════╝██╔════╝
FireTest: ███████╗██║ ██║██║ ██║ █████╗ ███████╗███████╗
FireTest: ╚════██║██║ ██║██║ ██║ ██╔══╝ ╚════██║╚════██║
FireTest: ███████║╚██████╔╝╚██████╗╚██████╗███████╗███████║███████║
FireTest: ╚══════╝ ╚═════╝ ╚═════╝ ╚═════╝╚══════╝╚══════╝╚══════╝
FireTest: ***********************************************************
FireTest: [FINAL] (Passed: 33, Failed: 0)

Add The Test Command To Your Composer.json

To make things a lot simpler for you to run all of your test cases, simply add the test runner to the script section of your project’s composer.json.

"scripts": {
    "test": "php vendor/ua1-labs/firetest/scripts/runner.php"
}

The post FireTest – Getting Started appeared first on UA1 Labs.

The History of FireTest - A New PHP Test Automation Framework

Joshua Johnson — Mon, 14 Oct 2019 03:18:44 +0000

UA1 Labs has officially released version 2.0.0 of FireTest. But why are we so focused on building yet another testing framework when there are so many already out there?

What Exactly is FireTest?

FireTest is a PHP test automation framework that allows you to automate tests as you write code. It was written in PHP for testing PHP code.

Why Did You Write Your Own Test Automation Framework?

For us the answer was simple, we looked into the many testing frameworks written for PHP and weren’t quite satisfied with what we were seeing. We wanted a light weight and flexible framework that wouldn’t get in the way of our workflow. We wanted to ensure that when we ran our automated tests that the results were valuable to us in catching bugs.

Most of the frameworks we looked at were so focused on code coverage, unit testing, CAP score. They missed out on the important thing. Does the code I’m writing still do what I want it to? And if we find a bug, how can I write a test so that the same bug doesn’t happen again. All other frameworks we worked with didn’t provide the flexibility we were looking for.

So we invented FireTest! We admit, it seems primitive in nature compared to the other popular testing frameworks, but we feel like we needed to get back to basics. Stop bloating our testing to reduce the complexity of the code you are writing. Instead we wanted to focus on simplicity and ease of use.

The post The History of FireTest appeared first on UA1 Labs.