Unit Test for Repository Functions in Magento 2

Question

I have a class utilizing the Magento 2 AttributeRepository. Can I write a unit test for my class which gets the attribute based on the attribute code?

namespace Company\Catalog\Test\Unit\Model;


use Company\Catalog\Helper\LandingPage;
use Company\Catalog\Model\Brand;
use Magento\Eav\Model\AttributeRepository;
use Magento\Store\Model\StoreManagerInterface;

class BrandTest extends \PHPUnit_Framework_TestCase
{
    /** @var  Brand */
    private $brand;

    /** @var  AttributeRepository */
    private $attributeRepository;

    /** @var  StoreManagerInterface */
    private $storeManager;

    /** @var  LandingPage */
    private $landingPageHelper;

    protected function setUp()
    {
        $this->landingPageHelper = $this->getMockBuilder(LandingPage::class)
            ->disableOriginalConstructor()
            ->getMock();
        $this->attributeRepository  = $this->getMockBuilder(AttributeRepository::class)
            ->disableOriginalConstructor()
            ->getMock();
        $this->storeManager = $this->getMockBuilder(StoreManagerInterface::class)
            ->disableOriginalConstructor()
            ->getMock();

        $this->landingPageHelper
            ->method('getBrandAttributeCode')
            ->willReturn('brands');

        $this->brand = new Brand($this->storeManager, $this->attributeRepository, $this->landingPageHelper);
    }

    public function testGetBrandAttributeCode()
    {
        $expected = 'brands';
        $this->assertEquals($expected, $this->brand->getBrandAttributeCode());
    }

    public function testGetBrandAttribute()
    {
        $expected = 'brands';
        $attribute = $this->brand->getBrandAttribute($expected);
        echo $attribute->getAttributeCode();
        $this->expectOutputString($expected);
    }
}

Should I even prepare a mock data for repository or can I get the actual value from the database using the AttributeRepository?

Answer 1

Should I even prepare a mock data for repository or can I get the actual value from the database using the AttributeRepository?

This is the decision between unit tests and integration tests.

• Integration tests test the real interaction with Magento and will hit the database. These tests are valuable to prove that your code (still) works together with the framework and other components and to find regressions.

• Unit tests test your code in isolation and should not use the real repository. These tests are valuable in test driven development to guide your design, they can quickly test your business logic with all edge cases.

For unit tests of a class that uses core repository you will end up with a complex mock setup. It's possible and I've done it for attribute repositories, but a better approach is to get rid of the complex dependency and leave it in a thin wrapper (which only needs integration tests)

I've written about the topic here: What to mock in a Magento 2 unit test

“Only mock types you own” [...] should not be taken as a strict rule, otherwise you end up with the other extreme, having wrappers over wrappers for everything. But it can be extremely helpful to simplify the API and tailor it to your needs.

Simplify complicated API

Here is a possible wrapper for the product repository, if you need to find products by manufacturer:

interface ProductRepository
{
    /**
     * @api
     * @return ProductInterface[]
     */
    public function productsByManufacturer($manufacturer);
}

There, no search criteria and no search result. It is easier to mock and also easier to use. The calling code is only interested in manufacturer and products, we leave the framework details in the implementation of our wrapper.

You might ask, how to test this wrapper. The answer is, it should be tested via integration tests of the whole feature, without mocks. A unit test does not make sense for it.

If your Brand class does not more than retrieving a brand attribute, you already have your wrapper. Don't waste time with unit tests for this and write integration tests instead. In other classes that use Brand, you can then easily mock Brand and do not need to care about the attribute repository.