writing testable code (for magento 1 and 2)

Writing Testable Code(for Magento 1 and 2)

Writing Testable Code in Magento 1 and 2 - #MM16PL 2016-09-19 - twitter://@VinaiKopp

Assumptions


You know basic PHPUnit.


You want→ Confidence in deploys

→ Experience joy when writing tests→ Have fun doing code maintaince

→ Get more $$$ from 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 code


It are properties of the

production codethat make testing

easy or hard.Writing Testable Code in Magento 1 and 2 - #MM16PL 2016-09-19 - twitter://@VinaiKopp

"It's no big thing,but you make big things

out of little things sometimes."~~ Robert Duvall


What does easy to test code look like?


A bad case of legacy:Event Observer(for Magento 1)


<?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 write Unit Tests?


For > 500 lines of legacy?

Hell NO!Writing Testable Code in Magento 1 and 2 - #MM16PL 2016-09-19 - twitter://@VinaiKopp

What would make it simpler to test?


If the class where

smallerit 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 they 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 the entry points.


Entry points are the places Magento provides us to put our custom code.


Entry points:→ Observers→ Plugins

→ Controllers→ Cron Jobs→ Preferences

→ Console Commands


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 or 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 Netzarbeiter_CustomerActivation_Model_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;

// ...}

Problematic because it makes the class interface less clean.


Constructor Injection

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

$observer = new Netzarbeiter_CustomerActivation_Model_Observer( $mockLoginSentry );

// ...}

Problematic because standard Magento 1 instantiation.


Ugly but works fine.

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

// ...

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

Optional Dependencies?! (WTF LOL)Writing Testable Code in Magento 1 and 2 - #MM16PL 2016-09-19 - twitter://@VinaiKopp

Injected collaboratorsmake for simple tests!


Delegation allow us to createclasses with a specific purpose.


We can give descriptive names.


Model with specific responsibilityclass 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

→ Observer→ Controller

→ Model Rewrite→ Test


Back to the example code...


There is one other thing here that makes testing easier:

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

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


No magic method call.// Old code:$event->getCustomer();

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


Why does thatimprove testability?


Creating a mock withmagic methods is ugly!


Noisy code in test is distracting.$methods = array_merge( get_class_methods(Event::class), ['getCustomer']);$mockEvent = $this->getMockBuilder(Event::class) ->setMethods($methods) ->getMock();


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


SummaryWriting Testable Code in Magento 1 and 2 - #MM16PL 2016-09-19 - twitter://@VinaiKopp

What makes code simple to test?


→ Separation ofBusiness Logic

andEntry Points


→ Small classes


→ Encapsulation of Business Logic inspecific classes


→ Delegation to injectable dependencies


→ Real methodsover

magic methods


Is there more?


→ Law of Demeter.→ Separation of code that causes side

effects from code that return a value.→ No method call chaining.

→ Single level of detail within methods.


Lets keep these for another time.


But 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)

Software