The “GENIUS” file

At WordPress-BDD, we introduce the concept of a Genius file. In order to be happy, you have to know what you want. As the business stakeholder, the Genius files is your golden record when dealing with WordPress-BDD.com. It is your single source of truth.

You have to have an idea in your mind.

The Genius file is the place where you, the business stakeholder, go to see how the idea you have in your mind, is translating into work being done in reality, by your developer.

There are no hard and fast rules for the genius file, and your developer will help you build yours. It resides as a simple private post, here on this server. It is not publicly accessible. You will be given a link and credintials to sign on.

As a business person, you may have internal processess that produce some kind of documentation that you intend to pass on to the developer. Things like UML charts, Gherkin files, specifications, requirements etc. Whatever you have – great – most of this goes into the genius file. Feel free to pass us napkins with coffee stained hyroglyphs. Whatever ya got.

If you discuss something verbally with your developer, expect to see a note in the Genius file [usually in the comments section].

You can edit anything you want, any way you want in the genius file. It belongs mostly to you, and is intended for you to understand. In fact, this is your highest responsibility in this process: UNDERSTAND THE GENIUS FILE. If you see something you don’t personally understand, please ask!

Be aware that the system keeps revisions and tracts all changes. You can’t mess it up.

Invoices, media, content and personel data go elsewhere.

Tips

K.I.S.S. Keep it simple, stupid.
It’s called a Genius file because it’s genius to assume we’re all stupid. The idea here is to be as concise as possible. We’re trying to come to an understanding, between you – the business stakeholder – and the development team. The Genius file is something everyone must understand.

The best wat to communicate with your developer is to verbally speak to him, and then read the genius file and confirm that what you just tried to communicate is written down. If you don’t see what you tried to communicate, try again.

The LESS data the better. The time for large volumes of data to be put into development comes during the unit and acceptance testing phases.

The Genius file contains broad language, written in plain language, and the DSL [the domain specific language]. The DSL is a vocabulary specific to your domain. For instance, the phrase “it should make sure the plumbing is working” would mean something totally different to a house builder versus a proctologist. We define keywords from the DSL in the Genius file.

Quality of Work [in PHP / WordPress outsourcing]

The quality of work done by low cost outsourcers is an obvious issue. You can overcome this problem by instituting a strict Test Driven Development cycle with your programmers.

The quality of work done by low cost outsourcers is an obvious issue. You can overcome this problem by instituting a strict Test Driven Development cycle with your programmers.

Technique: The 4/7 work unit

When hiring low cost outsourcers, I use what I call the 4/7 scheduling technique. The work day is 4 hours long, and one week out.

4 hour work day: I have noticed that computer programmers work approximetely for four hours. If you make them sit in front of their workstations for 8 hours, you get about the same ammount of work done as when you sit them down for 4 hours. I leave it to the philosophers to discuss why, it’s just true. Knowledge workers should work in 4 hour shifts.

One week out: I hire low cost LAMP programmers on sites like Upwork and Freelancer all the time. You can debate the morality of hiring overseas, or offering low wages, but you shouldn’t debate the metrics.
You can post an ad for a PHP programmer and from the moment you post the ad until the time the programmer is working can be as low as 15 minutes. So there is no lag time to get the worker.
The concept of “one week out” means that if you hire a programmer this way, he will work for approximately one week before you notice a significant drop off in the quality of work, or the outsourcer simply stops responding. This is just a fact of life. How long would you keep working an $8/hr job with zero chance of promotion? These people aren’t stupid, just broke. It’s fine to offer a low wage, because that’s money that human being wasn’t going to have before they met you. Be upfront. Don’t nickle and dime. But don’t expect that person to be happy about it, and don’t expect them to do any kind of work that requires them to sleep on it. They’ll decide there are greener pastures somewhere else.

This is fine though, and part of the paradigm. As long as you maintain security best practices, high turnover isn’t a problem.

Test Driven Development really shines as a methodology when you have low skilled programmers. It simply produces very high quality code, it’s just time consuming. With ultra low cost programmers, time isn’t a factor. You can just hire more manpower and go to a 24 hour schedule.

In terms of WordPress, the difficulty lies in setting up the test environment. Low cost programmers can easily understand the TDD cycle, and can be taught quickly how to write tests. It’s the setting up of the system that they can’t do.

You should setup the development server yourself, and simply give access credentials to the

Hiring low cost, off-shore WordPress / PHP outsourcers

How to get cheap software for WordPress using Test Driven Development.

Post an ad on a site like Upwork.com or Freelancer.com for a low cost PHP programmer, and you’ll experience something unlike anything else in business. You’ll receive applications faster than you can possibly read them. A vertitable gusher of low grade computer programmers. Give me your tired, your poor, your huddled masses.

$5/hr software developers, what could go wrong?
Obviously a lot. However, these programmers represent a massive untapped talent pool, and Test Driven Development is the technique you can use to leverage this talent. Using TDD, you can safely, effectively, and efficiently use low cost human talent on your projects.

Issue #1: Quality of work
Issue #2: Onboarding and retention
Issue #3: Security

Concept Massive talent pool
Concept Cost comparisons
Concept No employees
Concept 24 hours a day

Let’s be the best WordPress dev shop on Earth!

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

Understanding WordPress Codeception configuration files

Doing proper Test Driven Development [TDD] in WordPress, is actually easier than cowboy coding the old way. What is quite difficult however, is understanding and setting up all the configuration files. This guide will help.

The Server

In order to run WP-Codeception, you have to have a working installation of WordPress running on a web server you have access to. This can be any type of server, be it an Ubuntu laptop running Apache-Tomcat, a cloud based server, a Windows machine with a Vagrant box, or whatever. You’ll need access to the command line via a shell, and you’ll need admin access and the ability to load software. You should have Git, and Composer installed globally and at least a rudimentary understanding of haow to use them. Most of this guide assumes an Ubuntu 16LTS server with Apache2, as this is what I use, and you can get one for free. If you have a Windows machine, you can install Ubuntu on a memory stick and turn a junk laptop into a high powered server. You can get a cloud based server from Amazon or Google for next to nothing.

Understanding DNS and subdomains

The Domain Name System [DNS] is the system your browser uses to resolve names like generalchicken.net to IP addresses like 34.197.171.101. A server connected to the internet generally has one IP address, usually one main domain, but it can also have many subdomains. For instance, this server hosts the domains generalchicken.net and another blog, messagetothefish.com. Both have the same IP address, but different domain names.
When an HTTP or HTTPS request is sent to this server, the request should have a header called the host which indicates to the server what domain a resonse is expected from.
Internally, the server sends each request to a particular directory, based on what subdomain is named in the host header. On most Ubuntu WordPress setups I have seen, the main domain the server hosts is usually set to:
/var/www/html/
and subdomains go from there
/var/www/html/sub1/
/var/www/html/sub2/

Understanding this is important because if you are setting up a local development version of WordPress, you are going to want to be able to set subdomains up.

The default setup on Ubuntu, is for the domain “localhost” to point to /var/www/html . Therefore, to access your local WordPress site, open a browser like Chrome, and got to http://localhost/ and you should get the WordPress install screen.

Another consideration is that most forms of testing work the best when you don’t have any state. That is, the database is either reset to a starting point, or totally scrubbed after each test. If you’re not used to this, you may accidentally delete anything you have on your site, especially if you’re using it for anything. My personal setup is that I use http://localhost/ for unit testing, and I have another WordPress install, called http://laptop.dev/ where I have a database that doesn’t reset.

Free themes

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

The conceptual difference between mockery and prophecy

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.