Scenario Driven Unit Tests in Codeception. RFC

gistfile1.md

I'm trying to improve the concept of scenario-driven unit tests in Codeception.

The goal is to make them:

• readable
• easiest for mocks
• IDE friendly
• better with very\long\PSR\class\names

Here I took one sample unit test with mocks from this blog post. Despite author says that was wrong for him to write such test, let's try rewriting it with new Codeception paradigm.

gistfile2.php

<?php
 
namespace Foo\BarBundle\Tests\Manager;
 
use Foo\BarBundle\Manager\ReportManager;
 
class ReportManagerTest extends \PHPUnit_Framework_TestCase
{
    public function testGetFiles()
    {
        $company = $this->getMock('Foo\BarBundle\Entity\Company');
        $company->expects($this->once())
            ->method('getCode')
            ->will($this->returnValue('foo'));
 
        $user = $this->getMock('Symfony\Component\Security\Core\User\UserInterface');
        $user->expects($this->once())
            ->method('getSelectedCompany')
            ->will($this->returnValue($company));
 
        $token = $this->getMock('Symfony\Component\Security\Core\Authentication\Token\TokenInterface');
        $token->expects($this->once())
            ->method('getUser')
            ->will($this->returnValue($user));
 
        $securityContext = $this->getMock('Symfony\Component\Security\Core\SecurityContextInterface');
        $securityContext->expects($this->exactly(2))
            ->method('getToken')
            ->will($this->returnValue($token));
 
        $reportManager = new ReportManager('bar', $securityContext);
        $this->assertCount(0, $reportManager->getFiles(2013));
    }
}

gistfile3.php

<?php
namespace Foo\BarBundle\Tests\Manager; 
use Foo\BarBundle\Manager\ReportManager;
 
class ReportManagerCest
{
    /** 
    * @var Symfony\Component\Security\Core\SecurityContextInterface
    */
    protected $security;
    protected $reportManager;
    public function testGetFiles(\CodeGuy $I)
    {
        $I->have($this->security->getToken()->getCompany()->getUser()->getCode()->returns('foo'));
        $I->have($this->reportManager, new ReportManager('bar', $this->security));
        $I->execute($this->reportManager->getFiles(2013));
 
        $I->seeResultCountEquals(0);
        $I->seeMethodInvoked($this->security->getToken());
    }
}

Well, ofcourse second way is better, but i think that number of people that will really use cests will not be very big because of this reasons:It's really sometimes hard to get the edge between cests and clear unit tests, and yes they have pluses but i think not so much to make developers use only them and not classic phpunit. Anyway codeception now can handle phpunit tests as is, so i think maybe it is a good time to rethink scenario unit-tests and make them more like in behat (i like the way of story in behat) to only test functionality of the components, so it will be like this BDD->TDD, or just leave it as is (or if u have more time make it more specBDD). But i think that if they will be more like in behat "true BDD", it wil be better and will help other developers make theirs applications better, because first they will be think about behavior (here will go codeception bdd) and then use unit-tests for more detailed developing (here will go classic phpunit tests in codeception), and after this they can use functional/acceptance tests with codeception. So in this way after all codeception will be more powerful and more "fullstack" for developers.