ShawnMcCool

This is just an example.. Go make you're own!

ShawnMcCool

<?php namespace Sterling\BladeParsing;

class BladeParser
{
    protected $tags = [];

    public function parse($view)
    {
        foreach ($this->tags as $tag) {
            if ($tag->getMatchCount($view) > 0) $view = $tag->transform($view);

ShawnMcCool

#!/bin/bash

# "./lowresvga.sh" to enable 1024x768
# "./lowresvga.sh off" to return
# This was made for a Thinkpad T450s, substitute your devices.

if [ "$1" = "off" ] ; then
	echo "disabling"
	xrandr --output DP2 --off
	xrandr --output eDP1 --mode 1920x1080

ShawnMcCool

Examples:

public function sendSingleExample() {
    (new SendMailViaAPI('<postmark-server-token>'))->single(
        new Mail('sender name', 'sender email', 'recipient email', 'hello from exampletown', '<strong>this is bold</strong> this is not.')
    );
}

public function sendBatchExample() {

ShawnMcCool

alias mvltr="~/scripts/mvltr.sh"
alias ltr="ls -ltr"

ShawnMcCool

using System;
using System.Collections.Generic;
using System.Text;
using System.Linq;
using Tabi.DataObjects;

namespace Tabi.Logic
{
    public class KalmanLatLong : PositionEntry // Implementation taken from: https://stackoverflow.com/questions/1134579/smooth-gps-data/15657798#15657798
    {

ShawnMcCool

This tests behavior on the process "CreateConferenceTicketsForWebinarCustomers".

It's possible to create a working test that looks like the "minimum possible" example. But the "actual" example has additional information that supplements the test. The null parameter with default values pattern is not new.

In this case, the named parameters improve the comprehensibility of the tests.

This is one of hundreds of tests that I've used this technique for. When testing various paths through the same process, being able to swap values in then given/when/then steps can be really beautiful.

ShawnMcCool

Core Principles:

• tests are an executable story
  • most production similar implementation possible
  • communicate story along with implementation
• no inheritance
• no unnecessary features like data providers
• give full control over error and success reporting
  • assertions can have both success and error messages
• assertions can arbitrarily have added context such as 'array diff'

ShawnMcCool

Overview

In this gist, I attempt to communicate techniques for defining explicit boundaries over naturally occuring boundaries (in this case, the boundary between domain and service/data layers) to empower both testing and to improve comprehensibility of the system.

In my view, testing and application code are one-and-the-same and should evolve together. Testing code should not be an after-thought. I believe that haphazardly designing application code and test code leads to lead-time penalities.

If you'd like to reply, consider replying to this twitter thread. Additionally, I am available on Twitter @ShawnMcCool.

Note: I acknowledge that no techniques are right for everyone. But I have a long history with these techniques and I found them quite adequate for large and small-scale systems.