General Chicken

Who am I and what do I want?

What am I trying to do?

• Test Driven / Behavior Driven Development in WordPress
• No one is doing TDD in WordPress. Why?
• How can we overcome this lacks?

Why is this a quantum leap?
Low cost and high quality are usually opposing factors, with TDD you get ABSOLUTELY lowest cost ABSOLUTELY highest quality

Why isn’t any one else doing this?
No one else knows how!

How to start

Who are you?
Angel investor
Web dev agency
Web dev salesperson
Programmer

Craigslist app

The free themes in the .org repo are the ONLY themes you should use! Commercial themes are essentially a scam on people who don’t know what they are doing.
Here are the use cases:
If you are building a single business
You want to use a child theme of a free theme in the repo. You had better have an extremly good reason not to use a theme built from Automattic [the company that makes WordPRress]. With

Every WordPress install comes with
twentysixteen
twentyseventeen
twentynineteen
Additionally, the same parent company publishes:
StoreFront
Underscores

Insist that all design be HARD CODED in the child theme
If you are an agency, and plan on building many themes for clients

Better than VVV
Development environment exactly the same as production, except domain name
Allows remote WordPress devs to do TDD
Low cost
no office required

Reduce cost by up to 90%
Better code
More maintainable
Interchangeable developers
Produces living software documentation
Devops / Agile approach
Developer plays the role of software creator and tester
Developer coordinates directly with business stakeholder

http://everzet.com/post/72910908762/conceptual-difference-between-mockery-and-prophecy

Conceptual difference between Mockery and Prophecy

Today I’ve been asked twice what’s the difference between Mockery and Prophecy just to suddenly discover that I didn’t clarify this aspect never before. Well, that’s about time.

If we were to remove all the syntactical and implementation differences between two libraries what we’ll be left with is one really big conceptual difference and it’s the fact that in contradiction to Mockery, Prophecy puts messaging (aka how objects communicate) before structure (aka when objects communicate).

Lets consider an example:

interface User
{
public function getRating();
public function setRating($rating);
}

class UserRatingCalculator
{
public function increaseUserRating(User $user, $add = 1)
{
$user->setRating($user->getRating() + $add);
}
}
Pretty simple rating calculation behaviour (though a bit artificial, I know). Now, the test with Mockery will look something like this:

$user = Mockery::mock(‘User’);
$user->shouldReceive(‘getRating’)->andReturn(2);
$user->shouldReceive(‘setRating’)->with(4)->once();

$calc = new UserRatingCalculator();
$calc->increaseUserRating($user->mock(), 2);
And test with Prophecy will look something like this:

$user = $prophet->prophesize(‘User’);
$user->getRating()->willReturn(2);
$user->setRating(4)->shouldBeCalled();

$calc = new UserRatingCalculator();
$calc->increaseUserRating($user->reveal(), 2);
Except subtle differences in syntax examples look exactly the same. Now let’s ramp up things a bit. Lets say that now we want to raise an event before and after rating change. New calculator could look like that:

class UserRatingCalculator
{
private $dispatcher;

public function __construct(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}

public function increaseUserRating(User $user, $add = 1)
{
$this->dispatcher->userRatingIncreasing($user->getRating());
$user->setRating($user->getRating() + $add);
$this->dispatcher->userRatingIncreased($user->getRating());
}
}
So now we need to also check that the dispatcher event is raised with a specific argument. In Mockery it could look like that:

$user = Mockery::mock(‘User’);
$user->shouldReceive(‘getRating’)->andReturn(2, 2, 4);
$user->shouldReceive(‘setRating’)->with(4)->once();

$disp = Mockery::mock(‘EventDispatcher’);
$disp->shouldReceive(‘userRatingIncreasing’)->with(2)->once();
$disp->shouldReceive(‘userRatingIncreased’)->with(4)->once();

$calc = new UserRatingCalculator($disp->mock());
$calc->increaseUserRating($user->mock(), 2);
The key thing to note here is how we stubbed getRating() call with 3 consequent return values. This is called structure binding – it means your test is now bound to the way your code is structured (that there are 3 consequent getRating() calls in specific order).

In Prophecy solution will look quite different:

$user = $prophet->prophesize(‘User’);
$user->getRating()->willReturn(2);
$user->setRating(Argument::type(‘integer’))->will(function($args) {
$this->getRating()->willReturn($args[0]);
});

$disp = $prophet->prophesize(‘EventDispatcher’);
$disp->userRatingIncreasing(2)->shouldBeCalled();
$disp->userRatingIncreased(4)->shouldBeCalled();

$calc = new UserRatingCalculator($disp->reveal());
$calc->increaseUserRating($user->reveal(), 2);
As you can see, Prophecy takes different approach to the same problem. Prophecy uses approach called message binding – it means that behaviour of the method does not change over time, but rather is changed by the other method.

Now, what’s the real difference between these two approaches? Consider a calculator change:

public function increaseUserRating(User $user, $add = 1)
{
$initialRating = $user->getRating();
$this->dispatcher->userRatingIncreasing($initialRating);

$user->setRating($initialRating + $add);

$resultingRating = $user->getRating();
$this->dispatcher->userRatingIncreased($resultingRating);
}
We simply assigned initial rating to internal method variable (for a clarity sake).

The trick is, this change will break Mockery test, because instead of 3 getRating() calls (and returns) you now have only two. You locked onto structure, structure changed – you got failure.

In case of Prophecy though, initial test will still pass, because test was bound purely on communicational behaviour, and it didn’t change a bit.

So the core conceptual difference is not in how you write tests, but when you fix them. Mockery sometimes could put you into the situation, where you would write tests that will inevitably fail because of the private structural refactoring. Where’s Prophecy postulates that there is no failure in this case – because the actual behaviour stayed the same.