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
→ Conﬁdence 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 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.

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

Hell NO!

Unit tests only provide
value for new code.

For previously untested code,
Integration Tests
are much more valuable.

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 these classes 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 entry points.

Entry points are the places Magento provides for
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 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:

{
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 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;
// ...
}
Problem: It muddies intention revealing class interfaces.

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.

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_O

Injected collaborators
make for simple tests!

Delegation allow us to create
classes with a speciﬁc 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:
{
if (! $this->isModuleActive()) {
return;
}
);
}

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

Why does that
improve testability?

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

Summary

What makes code
simple to test?

→ Separation of
Business Logic
from
Entry Points

→ Small classes
(and methods)

→ Encapsulation of
Business Logic in
speciﬁc classes

→ Delegation to
injectable dependencies

→ Favoring
real methods
over
magic methods

Is there more?

Yes!

→ Adherence to the Law of Demeter.

→ Separation of methods that causes
side 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

Recommandé

Recommandé

Contenu connexe

Similaire à Writing Testable Code (for Magento 1 and 2) 2016 Romaina

Similaire à Writing Testable Code (for Magento 1 and 2) 2016 Romaina (20)

Plus de vinaikopp

Plus de vinaikopp (8)

Dernier

Dernier (20)

Writing Testable Code (for Magento 1 and 2) 2016 Romaina