writing testable code (for magento 1 and 2) 2016 romaina

Writing Testable Code(for Magento 1 and 2)

Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Assumptions!


You know basic PHPUnit.


You want→ Confidence in deploys

→ Experience joy when writing tests→ Have fun doing code maintaince→ Get more $$$ out of testing


In short, you want→ Testable code


When is code "testable"?


When testingis simple & easy.


What makes atest simple?


It is simple to write.


It is easy to read.


What does"easy to read"

mean?


It's intent is clear.


The test is short.


Good names.


It only doesone thing.


Clean Codeis for

Production Code& Test Code


What does"simple to write"

mean?


Test codedepends on

production codeWriting Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

It are properties of the

production codethat make testing

easy or hard.Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

What does easy to test code look like?


Magento 1 Example:Event Observer(Legacy Code)


<?php

use Varien_Event_Observer as Event;

class Netzarbeiter_CustomerActivation_Model_Observer{ // Check if the customer has been activated, if not, throw login error public function customerLogin(Event $event) {...}

// Flag new accounts as such public function customerSaveBefore(Event $event) {...}

// Send out emails public function customerSaveAfter(Event $event) {...}

// Abort registration during checkout if default activation status is false public function salesConvertQuoteAddressToOrder(Event $event) {...}

// Add customer activation option to the mass action block public function adminhtmlBlockHtmlBefore(Event $event) {...}

// Add the customer_activated attribute to the customer grid collection public function eavCollectionAbstractLoadBefore(Event $event) {...}

// Add customer_activated column to CSV and XML exports public function coreBlockAbstractPrepareLayoutAfter(Event $event) {...}

// Remove the customer id from the customer/session, in effect causing a logout public function actionPostdispatchCustomerAccountResetPasswordPost(Event $event) {...}}


Are we going to writeUnit Tests?


Hell NO!Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Unit tests only providevalue for new code.


For previously untested code,Integration Tests

are much more valuable.


What would make it simpler to test?


If the class wheresmallerit would be simpler to test.


First attempt:Splitting the class based on purpose.


What does theclass do?


1. Prevents inactive customer logins.2. Sends notification emails.

3. Adds a column to the customer grid.


Lets split it intoNetzarbeiter_CustomerActivation_Model...

..._Observer_ProhibitInactiveLogins

..._Observer_EmailNotifications

..._Observer_AdminhtmlCustomerGrid


<?php


class Netzarbeiter_CustomerActivation_Model_Observer_ProhibitInactiveLogin{ // Check if the customer has been activated, if not, throw login error public function customerLogin(Event $event) {...}

// Abort registration during checkout if default activation status is false public function salesConvertQuoteAddressToOrder(Event $event) {...}

// Remove the customer ID from the customer/session causing a logout public function actionPostdispatchCustomerAccountResetPasswordPost(Event $event) {...}}


<?php


class Netzarbeiter_CustomerActivation_Model_Observer_EmailNotifications{ // Flag new accounts as such public function customerSaveBefore(Event $event) {...}

// Send out emails public function customerSaveAfter(Event $event) {...}}


<?php


class Netzarbeiter_CustomerActivation_Model_Observer_AdminhtmlCustomerGrid{ // Add customer activation option to the mass action block public function adminhtmlBlockHtmlBefore(Event $event) {...}

// Add the customer_activated attribute to the customer grid collection public function eavCollectionAbstractLoadBefore(Event $event) {...}

// Add customer_activated column to CSV and XML exports public function coreBlockAbstractPrepareLayoutAfter(Event $event) {...}}


Is this simplerto test?


Only minor difference in

testing effort.


Why?


The same tests as before.Only split into three classes.


Second attempt:Lets go beyond

superficial changes.


Lets look at the design.


What collaborators are used?


Collaborators:Netzarbeiter_CustomerActivation_Helper_DataMage_Customer_Model_CustomerMage_Customer_Model_SessionMage_Customer_Model_GroupMage_Customer_Helper_AddressMage_Customer_Model_Resource_Customer_CollectionMage_Core_Controller_Request_HttpMage_Core_Controller_Response_HttpMage_Core_ExceptionMage_Core_Model_SessionMage_Core_Model_StoreMage_Sales_Model_Quote_AddressMage_Sales_Model_QuoteMage_Eav_Model_ConfigMage_Eav_Model_Entity_TypeMage_Adminhtml_Block_Widget_Grid_MassactionMage_Adminhtml_Block_Widget_Grid


Almost all of them are core classes.


Only two classes are part of the module:Netzarbeiter_CustomerActivation_Model_ObserverNetzarbeiter_CustomerActivation_Helper_Data


Based on the names, why do these classes exist?

Netzarbeiter_CustomerActivation_Model_ObserverNetzarbeiter_CustomerActivation_Helper_Data


The names don't tell us anything.


Extract parts by giving them

meaningful names


But where to start?


Separate business logicfrom entry points.


Entry points are the places Magento provides for our custom code.


Entry points:→ Observers→ Plugins

→ Controllers→ Cron Jobs→ Preferences

→ Console CommandsWriting Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Entry points linkBusiness logic

!Magento


Remove allBusiness Logic

fromEntry Points.


What are the benefits?


For testing:

The custom code can be triggered independently of the entry point.


In our example,what is the

entry point?


Observer


Old Observer Code:


public function customerLogin($observer){ $helper = Mage::helper('customeractivation'); if (!$helper->isModuleActive()) { return; }

if ($this->_isApiRequest()) { return; }

$customer = $observer->getEvent()->getCustomer(); $session = Mage::getSingleton('customer/session');

if (!$customer->getCustomerActivated()) { $session->setCustomer(Mage::getModel('customer/customer')) ->setId(null) ->setCustomerGroupId(Mage_Customer_Model_Group::NOT_LOGGED_IN_ID);

if ($this->_checkRequestRoute('customer', 'account', 'createpost')) { $message = $helper->__('Please wait for your account to be activated');

$session->addSuccess($message); } else { Mage::throwException($helper->__('This account is not activated.')); } }}


New Code, without business logic:


public function customerLogin(Event $event){ if (! $this->isModuleActive()) { return; }

$this->getCustomerLoginSentry()->abortLoginIfNotActive( $event->getData('customer') );}


And this class issimpler to test?


Yes, as there ismuch less logic.


Most of the logic is delegated to collaborators.


$this->getCustomerLoginSentry()->abortLoginIfNotActive( $event->getData('customer'));


How does the delegation look in detail?


private static $sentryClass = 'customeractivation/customerLoginSentry';

/** * @return CustomerLoginSentry */private function getCustomerLoginSentry(){ return $this->loginSentry ?? Mage::getModel(self::$sentryClass);}


The login sentry can be injected.


That means,

it can be replaced by a test double.


Dependency Injection


DI is a Magento 2 thing, right?


DI can be everywhere!


Injecting Test Doublesin Magento 1


Setter Injection

public function testDelegatesToLoginSentry(){ $mockLoginSentry = $this->createMock(LoginSentry::class); $mockLoginSentry->expects($this->once()) ->method('abortLoginIfNotActive');

$observer = new Netzarbeiter_CustomerActivation_Model_Observer();

$observer->loginSentry = $mockLoginSentry;

// ...}

Problem: It muddies intention revealing class interfaces.Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Constructor Injection

public function testDelegatesToLoginSentry(){ $mockLoginSentry = $this->createMock(LoginSentry::class); $mockLoginSentry->expects($this->once()) ->method('abortLoginIfNotActive');

$observer = new Netzarbeiter_CustomerActivation_Model_Observer( $mockLoginSentry );

// ...}

Problem: Standard Magento 1 instantiation can't do it.Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Ugly but hey it works.

/** * @param LoginSentry $loginSentry */public function __construct($loginSentry = null){ $this->loginSentry = $loginSentry;}

// ...

private function getCustomerLoginSentry(){ return $this->loginSentry ?? Mage::getModel(self::$sentry);}

Paradoxical: Optional Dependency Injection..? o_OWriting Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

Injected collaboratorsmake for simple tests!


Delegation allow us to createclasses with a specific purpose.


We can give descriptive names.


Model with one responsibility:class Netzarbeiter_CustomerActivation_Model_CustomerLoginSentry


public function abortLoginIfNotActive( Mage_Customer_Model_Customer $customer) { if (! $customer->getData('customer_activated')) { $this->getSession()->logout(); $this->getDisplay()->showLoginAbortedMessage(); }}


This business logic is now independent of the entry point.


It can be called from anywhere:

→ Test→ Observer→ Controller

→ Model Rewrite


Back to the example code...


One other subtle thing here makes testing easier:

public function customerLogin(Event $event){ if (! $this->isModuleActive()) { return; }

$this->getCustomerLoginSentry()->abortLoginIfNotActive( $event->getData('customer') );}


No magic method __call() calls!// Old "magic" code:$event->getCustomer();

// New code:$event->getData('customer')


Why does thatimprove testability?


Creating a mock withmagic methods is ugly!


Lots of setup code in tests

distracts

from the important parts.


Noisy test double creation:$methods = array_merge( get_class_methods(Event::class), ['getCustomer']);$mockEvent = $this->getMockBuilder(Event::class) ->setMethods($methods) ->getMock();


Much nicer:$mockEvent = $this->createMock(Event::class);


SummaryWriting Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

What makes codesimple to test?


→ Separation ofBusiness Logic

fromEntry Points


→ Small classes(and methods)


→ Encapsulation of Business Logic inspecific classes


→ Delegation to injectable dependencies


→ Favoringreal methods

overmagic methods


Is there more?


Yes!Writing Testable Code in Magento 1 and 2 - #MM16RO 2016-10-28 - twitter://@VinaiKopp

→ Adherence to the Law of Demeter.


→ Separation of methods that causesside effects from

methods returning values.


→ Avoidance of method call chaining.


→ Methods having a single level of detail.


Lets keep these for another time.


So most importantly...


...have fun writing tests!


(tell you me comment)(ask? you me question)

(thank you)


http://mage2katas.com/


writing testable code (for magento 1 and 2) 2016 romaina

Software