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.

I appreciate your input