a testify usage flow

I’ve undergone the procedure to add Testify to Package Control and have added a little feature to make my life easier. How much easier I’m going to show.

TDD or “Write tests first”

I’m going to implement the DefaultArgumentParser class and will just build its skeleton

<?php 
namespace TAD\Helpers;

class DefaultArgumentsParser
{
    public function __construct(){}
    public function getDefaults(){}
    public function setDefaults(){}
    public function getDefault(){}
    public function setDefault(){}
    public function removeDefault(){}
    public function parse(){}
}

after that, using codeception, I will generate a test class

codecept generate:phpunit unit DefaultArgumentParser

and will edit it brainstorming about the methods and how those should behave

<?php

class DefaultArgumentParserTest extends \PHPUnit_Framework_TestCase
{
    protected function setUp()
    {
    }

    protected function tearDown()
    {
    }

    // tests
constructor sets defaults to past defaults
constructor throws for non associative array argument
set defaults throws for non associative array argument
set defaults sets defaults to empty array when passed null value
remove default throws for non string key argument
remove default removes default
remove default returns null if attempting to remove non existing default
set default throws for non string key argument
set default sets to null for null value argument-
get default throws for non string key argument
get default returns null when requesting non existing default
parse throws for non associative array argument
parse returns associative array
parse returns empty array if no defaults are set
parse returns argument array if no defaults are set
parse return intersection array
parse returns default array when passed array not containing any default key
}

Aside for what codeception generated I’m writing in plain natural language what I expect from the class methods. The - symbol trailing a line will prevent the plugin from generating a data provider method: since this behaviour is triggered using for and with I have to explicitly prevent the plugin from doing so.
Selecting all the lines and activating the plugin will fill my test class with test methods and relative data providers

After that it’s the usual red light, green light, refactor cycle of TDD. Just a little faster.

The big deal to me

The same way sketching works for getting ideas out of my mind quickly and easily being able to write the test methods all together before hand and then implementing them and then implementing code allows me to define my class methods and states in the same mind set. What I did before was not different but simply longer: I would write all the expectations as comments and then implement each test

//constructor sets defaults to passed defaults
//constructor throws for non associative array argument
//set defaults throws for non associative array argument
//set defaults sets defaults to empty array when passed null value
...

I’m just automating what can be automated, that’s all. And I like it.