Testing the Untestable

Unit Tests are Great !
• Proof that your code does what it is supposed to do
• Proof that refactoring code doesn’t break its functionality
• Automated Regressions Tests
• Verify that new code doesn’t break existing code
• Unit Tests are a part of the documentation of the code

TDD is Great !
• Writing tests helps design how the code should work
• Write tests as we define the public methods
• All green tests tell us when the coding is complete
• Bugfixing
• Write test for bug
• Fix bug so that test passes

Testing the Untestable
• 100% Code Coverage is over-rated
• Prioritise writing Tests for the code that needs testing
• Diminishing returns

• Test Doubles
• Let the code run
• Mock as little as possible
• Database access
• E-Mailing
• Test values

• Constructor does Real Work
• Indirect Collaborators
• Global State & Singletons
• Class Does Too Much

Constructor does Real Work
• Difficulties
• Creating/Initializing Collaborators
• Communicating with other services, and logic to set up its own
state
• Forcing subclasses/mocks to inherit unwanted behaviour
• Prevents instantiation or altering collaborators in the test.

• Warning Signs
• new keyword in a constructor
• Static method calls in a constructor
• Anything more than argument validation and field assignment in constructors
• Object not fully initialized after the constructor finishes
• Control flow (conditional or looping logic) in a constructor
• Separate Initialisation methods

• Why?
• Inflexible and prematurely coupled design
• Violates Single Responsibility Principle
• Testing Directly is Difficult
• Subclassing and Overriding to Test is Still Flawed
• It Forces Collaborators on Us

Indirect Collaborators
• Difficulties
• “Middle Men” make change difficult
• Unnecessary complexity and code bloat

• Warning Signs
• Objects are passed in but never used directly
• Only used to get access to other objects
• Suspicious names like context, environment, principal,
container, or manager

• Why?
• Hard to identify the collaborator methods that we need to mock
• Necessary to create mocks that return other mocks

Global State & Singletons
• Difficulties
• Global state mutated in one test can cause a subsequent or
parallel test to fail unexpectedly.
• Forcing subclasses/mocks to inherit unwanted behaviour
• Prevents instantiation or altering collaborators in the test.

• Warning Signs
• Use of Singletons
• Using Static Properties or Methods
• Using Registries or Service Locators
• Static Initialisation Blocks

• Why?
• Changes to global state can be made from anywhere
• Unexpected initial state for individual tests

• Difficulties
• Tests for individual Methods can’t easily be isolated from other
methods

• Warning Signs
• Class description uses the word “and”
• Too many methods
• Too many properties
• Too many collaborators

The ideal number of arguments for a function is zero (niladic). Next
comes one (monadic) followed closely by two (dyadic). Three
arguments (triadic) should be avoided where possible. More than three
(polyadic) requires very special justification—and then shouldn't be
used anyway.
Bob Martin – “Clean Code”

public function __construct(
MagentoFrameworkModelContext $context,
MagentoFrameworkViewDesignInterface $design,
MagentoFrameworkRegistry $registry,
MagentoStoreModelAppEmulation $appEmulation,
MagentoStoreModelStoreManagerInterface $storeManager,
MagentoFrameworkAppRequestInterface $request,
MagentoNewsletterModelTemplateFilter $filter,
MagentoFrameworkAppConfigScopeConfigInterface $scopeConfig,
MagentoNewsletterModelTemplateFactory $templateFactory,
MagentoFrameworkFilterFilterManager $filterManager,
array $data = []
) {
parent::__construct($context, $design, $registry, $appEmulation, $storeManager, $data);
$this->_storeManager = $storeManager;
$this->_request = $request;
$this->_filter = $filter;
$this->_scopeConfig = $scopeConfig;
$this->_templateFactory = $templateFactory;
$this->_filterManager = $filterManager;
}

• Why?
• Difficult to modify behaviour of one responsibility without
changing/breaking others
• Muddled Responsibilities

namespace reporting;
class dateCalculator {
protected $currentDate;
public function __construct() {
$this->currentDate = new DateTime();
}
public function weekToDate() {
$startDate = clone $this->currentDate;
$startDate->modify('last monday');
return new dateRange(
$startDate->modify('midnight'),
(clone $this->currentDate)->modify('midnight')
);
}
}

class dateCalculatorTest extends PHPUnitFrameworkTestCase {
public function testDateCalculatorWeek() {
$dateCalculator = new dateCalculator();
$week = $dateCalculator->weekToDate();
$this->assertInstanceOf('reportingdateRange', $week);
$this->assertInstanceOf('DateTime', $week->startDate);
$this->assertEquals(
DateTime::createFromFormat('Y-m-d|', '2018-01-08'),
$week->startDate
);
$this->assertInstanceOf('DateTime', $week->endDate);
$this->assertEquals(
DateTime::createFromFormat('Y-m-d|', '2018-01-10'),
$week->endDate
);
}
}

• Dependency Injection
• Inject either a date value or a DateTime object into the constructor

public function __construct(string $date = 'now') {
$this->currentDate = new DateTime($date);
}
);
}
}

public function __construct(DateTime $dto) {
$this->currentDate = $dto;
}
);
}
}

• Dependency Injection (Inversion of Control)
• Inject either a date value or a DateTime object into the constructor
• Not always an option if we can’t change the codebase
• e.g. If we’re writing tests preparatory to refactoring
• May require significant changes wherever the class we’re testing is
used within the main codebase
• Or introducing a Dependency Injection Container

• In the case of DateTime, we can modify the the
DateTime constructor
• If we’re using namespacing

$this->currentDate = new DateTime("@" . time());
}
....
}

function time() {
return strtotime('2018-01-10 01:23:45');
}
.... Assertions
}
}

• In the case of DateTime, we can modify the the
DateTime constructor
• If we’re using namespacing
• Overriding the time() function with a namespaced
time() function
• So we set our own value to be returned by a call to time()

• Move the assignment of $currentDate and the
instantiation of the DateTime to a separate method
called from the constructor
• We can then mock that new method in our tests

protected function getCurrentDate() {
return new DateTime();
}
$this->currentDate = $this->getCurrentDate();
}
....
}

$dateCalculator = $this->getMockBuilder('reportingdateCalculator')
->setMethods(['getCurrentDate'])
->getMock();
$dateCalculator->expects($this->once())
->method('getCurrentDate')
->will(
$this->returnValue(new DateTime('2018-01-10 01:23:45'))
);
.... Assertions
}
}

• Or Use Reflection

$dateCalculator = $this->getMockBuilder('reportingdateCalculator')
->disableOriginalConstructor()
->setMethods(['getCurrentDate'])
->getMock();
$dateCalculator->expects($this->once())
->method('getCurrentDate')
->will(
$this->returnValue(new DateTime('2018-01-10 01:23:45'))
);
....
}
}

....
// now call the constructor
$reflectedClass = new ReflectionClass('reportingdateCalculator');
$constructor = $reflectedClass->getConstructor();
$constructor->invoke($dateCalculator);
.... Assertions
}
}

• Anonymous Classes
• http://php.net/manual/en/language.oop5.anonymous.php

$dateCalculator = new class() extends dateCalculator {
// parent::__construct();
$this->currentDate = new DateTime('2018-01-10 01:23:45');
}
};
.... Assertions
}
}

• https://github.com/MarkBaker/SpyMaster

$spy = (new SpyMasterSpyMaster($dateCalculator))
->infiltrate(SpyMasterSpyMaster::SPY_READ_WRITE);
$spy->currentDate = new DateTime('2018-01-10 01:23:45');
.... Assertions
}

• Make sure we test against different dates using a
phpunit dataprovider

/**
* @dataProvider testDateCalculatorWeekProvider
**/
public function testDateCalculatorWeek($baseline, $expectedResult) {
$dateCalculator = new class($baseline) extends dateCalculator {
public function __construct($baseline) {
// parent::__construct();
$this->currentDate = new DateTime($baseline);
}
};
.... Assertions
}

• Mockery
• https://github.com/mockery/mockery
• AspectMock
• https://github.com/Codeception/AspectMock

• Mocking the Filesystem
• https://github.com/mikey179/vfsStream

• Assertions for HTML Markup
• https://github.com/stevegrunwell/phpunit-markup-assertions

Who am I?
Mark Baker
@Mark_Baker
https://github.com/MarkBaker
http://uk.linkedin.com/pub/mark-baker/b/572/171
http://markbakeruk.net

Testing the Untestable

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Testing the Untestable

Semelhante a Testing the Untestable (20)

Mais de Mark Baker

Mais de Mark Baker (20)

Último

Último (20)

Testing the Untestable

Notas do Editor