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
→ Conﬁdence 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 testing
is simple & easy.

What makes a
test 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 does
one thing.

Clean Code
is for
Production Code &
Test Code

What does
"simple to write"
mean?

Test code
depends on
production code

It are properties of the
production code
that make testing
easy or hard.

"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!

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 the
class do?

1. Prevents inactive customer logins.
2. Sends notiﬁcation emails.
3. Adds a column to the customer grid.

Lets split it into
Netzarbeiter_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 simpler
to test?

Only minor difference in
testing effort.

Why?

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

Second attempt:
Lets go beyond
superﬁcial changes.

Lets look at the design.

What collaborators are used?

Collaborators:
Netzarbeiter_CustomerActivation_Helper_Data
Mage_Customer_Model_Customer
Mage_Customer_Model_Session
Mage_Customer_Model_Group
Mage_Customer_Helper_Address
Mage_Customer_Model_Resource_Customer_Collection
Mage_Core_Controller_Request_Http
Mage_Core_Controller_Response_Http
Mage_Core_Exception
Mage_Core_Model_Session
Mage_Core_Model_Store
Mage_Sales_Model_Quote_Address
Mage_Sales_Model_Quote
Mage_Eav_Model_Config
Mage_Eav_Model_Entity_Type
Mage_Adminhtml_Block_Widget_Grid_Massaction
Mage_Adminhtml_Block_Widget_Grid

Almost all of them are core classes.

Only two classes are part of the module:
Netzarbeiter_CustomerActivation_Model_Observer

Based on the names,
why do they exist?
Netzarbeiter_CustomerActivation_Model_Observer

The names don't
tell us anything.

Extract parts by giving them
meaningful names

But where to start?

Separate business logic
from 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 link
Business logic
!
Magento

Remove all
Business Logic
from
Entry Points.

What are the
beneﬁts?

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:

{
if (! $this->isModuleActive()) {
return;
}
$this->getCustomerLoginSentry()->abortLoginIfNotActive(
$event->getData('customer')
);
}

And this class is
simpler to test?

Yes, as there is
much less logic.

Most of the logic is delegated to
collaborators.

);

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 Doubles
in 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 ﬁne.
/**
* @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)

Injected collaborators
make for simple tests!

Delegation allow us to create
classes with a speciﬁc purpose.

We can give descriptive names.

Model with speciﬁc 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
→ Observer
→ Controller
→ Model Rewrite
→ Test

Back to the example code...

There is one other thing here that makes testing easier:
{
if (! $this->isModuleActive()) {
return;
}
);
}

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

Why does that
improve testability?

Creating a mock with
magic 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);

Summary

What makes code
simple to test?

→ Separation of
Business Logic
and
Entry Points

→ Small classes

→ Encapsulation of Business Logic in
speciﬁc classes

→ Delegation to
injectable dependencies

→ Real methods
over
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)

More Related Content

Viewers also liked (10)

Similar to Writing Testable Code (for Magento 1 and 2) (20)

More from vinaikopp (11)

Recently uploaded (20)

Writing Testable Code (for Magento 1 and 2)