I'm running some unit-tests using PHPUnit, and hack my application pretty hard in those tests (no other way, old code-base). Some parts of the code-base use
Yii::app()->getController()->createUrl(...);
but in this case, there is no controller, so the test fails. Is there a way to add a dummy controller dynamically in my test? Something like
Yii::app()->setController($dummyController);
Or do I have to initiate some kind of fake routing event?
You can simply use:
$ctrl = new CController('whatever you need for the id')
and use its methods. Be careful, construct method sets id only. You didn't provide too much code, so this is a general idea. Look inside createUrl() method and check if it should work.
I used this technique to render pages (and use their contents) under console enviroment.
If you need a controller for multiple tests you can set it once in the setUp method.
public function setUp()
{
parent::setUp();
Yii::app()->controller = new CController('test');
}
And then you can use it in your tests:
Yii::app()->controller->createUrl(...)
Related
I created a simple test for my new Laravel 7 application. But when I run php artisan test I get the following error.
Target [Illuminate\Contracts\View\Factory] is not instantiable.
The error doesn't appear when I go to the page in the browser.
$controller = new HomeController();
$request = Request::create('/', 'GET');
$response = $controller->home($request);
$this->assertEquals(200, $response->getStatusCode());
Although "Just write feature tests" may seem like a cop-out ("They're not unit tests!"), it is sound advice if you do not want to get bogged down by framework-specific knowledge.
You see, this is one of those problems that come from using facades, globals, or static methods. All sorts of things happen outside of your code (and thus your test code) in order for things to work.
The problem
To understand what is going on, you first need to know how Laravel utilizes Containers and Factories in order to glue things together.
Next, what happens is:
Your code (in HomeController::home() calls view() somewhere.
view() calls app() to get the factory that creates Views1
app() calls Container::make
Container::make calls Container::resolve1
Container::resolve decides the Factory needs to be built and calls Container::build to do so
Finally Container::build (using PHP's ReflectionClass figures out that \Illuminate\Contracts\View\Factory can not be Instantiated (as it is an interface) and triggers the error you see.
Or, if you're more of a visual thinker:
The reason that the error is triggered is that the framework expects the container to be configured so that a concrete class is known for abstracts (such as interfaces).
The solution
So now we know what is going on, and we want to create a unit-test, what can we do?
One solution might seem to not use view. Just inject the View class yourself! But if you try to do this, you'll quickly find yourself going down a path that will lead to basically recreating loads of framework code in userland. So not such a good idea.
A better solution would be to mock view() (Now it is really a unit!). But that will still require recreating framework code, only, within the test code. Still not that good.[3]
The easiest thing is to simply configure the Container and tell it which class to use. At this point, you could even mock the View class!
Now, purists might complain that this is not "unit" enough, as your tests will still be calling "real" code outside of the code-under-test, but I disagree...
You are using a framework, so use the framework! If your code uses glue provided by the framework, it makes sense for the test to mirror this behavior. As long as you don't call non-glue code, you'll be fine![4]
So, finally, to give you an idea of how this can be done, an example!
The example
Lets say you have a controller that looks a bit like this:
namespace App\Http\Controllers;
class HomeController extends \Illuminate\Routing\Controller
{
public function home()
{
/* ... */
return view('my.view');
}
}
Then your test[5] might look thus:
namespace Tests\Unit\app\Http\Controllers;
use App\Http\Controllers\HomeController;
use Illuminate\Contracts\View\Factory;
class HomeControllerTest extends \PHPUnit\Framework\TestCase
{
public function testHome()
{
/*/ Arange /*/
$mockFactory = $this->createMock(Factory::class);
app()->instance(Factory::class, $mockFactory);
/*/ Assert /*/
$mockFactory->expects(self::once())
->method('make')
->with('my.view')
;
/*/ Act /*/
(new HomeController())->home();
}
}
A more complex example would be to also create a mock View and have that be returned by the mock factory, but I'll leave that as an exercise to the reader.
Footnotes
app() is asked for the interface Illuminate\Contracts\View\Factory, it is not passed a concrete class name
The reason Container::make does nothing other than call another function is that the method name make is defined by PSR-11 and the Laravel container is PSR compliant.
Also, the Feature test logic provided by Laravel already does all of this for you...
Just don't forget to annotate the test with #uses for the glue that is needed, to avoid warnings when PHPUnit is set to strict mode regarding "risky" tests.
Using a variation of the "Arrange, Act, Assert" pattern
This is not how you test endpoints in Laravel. You should let Laravel instantiate the application as it is already setup in the project, the examples you can see here.
What you already wrote can be rewritten to something like this.
$response = $this->call('GET', route('home')); // insert the correct route
$response->assertOk(); // should be 200
For the test to work, you should extend the TestCase.php, that is located in your test folder.
If you're finding this in The Future and you see #Pothcera's wall of text, here's what you need to know:
The ONLY reason he's doing any of that and the ONLY reason you're seeing this in the first place in a Unit test is because he and you haven't changed from PHPUnit\Framework\TestCase to Tests\TestCase in the test file. This exception doesn't exist when you extend the test case that includes app().
My advice would be to simply extend the correct base test case and move on with your life.
I am trying to use guzzle 6.x on a CakePHP 2.x application.
What I need to do is to initialize Guzzle Client to some of my controllers but on the controllers that it will be loaded I need it to be loaded with the same configuration.
Basically what I don't know is which is the best approach to implement it. I was thinking about the following:
Shall I create a function in AppController that will create and return a Guzzle object and then save it to a protected property inside AppController? Maybe a function like setUpGuzzle() and call this function on the Controllers I need to load Guzzle Client.
Shall I create a component and then load Guzzle Client to a public property of this component. Then I could use it like this $this->HttpClient->client->post()
Shall I create a component and write one function for each of Guzzle public function? So I will have something like this $this->HttpClient->post().
Thing is I don't like any of the above and I was hopping maybe there could be another way to do this. For example create a components which loads the Guzzle Client in a controller or loads the Guzzle Client inside the component collection.
Do you really need Guzzle? I agree that the old Cake2 HTTP socket is old fashioned but is there something it can't do that requires you to add yet another lib?
Use a trait, as long as you're not stuck to an ancient php version this is a clean solution. Here is some pseudo-code that will give you the high level idea:
trait HttpSocket {
protected $_httpSocket = null;
protected $_httpSocketConfig = [
// Default config goes here
];
public function getHttpSocket() {
if (empty($this->_httpSocket)) {
// Not sure how the constructur works, so it's just an example
$this->_httpSocket = new Guzzle($this->_httpSocketConfig);
}
return $this->_httpSocket;
}
}
If you ever need to change the config or the whole socket implement ion you just have to change it in a single place without the overhead of a component. Also this can be use in any class, not just controllers. What you're looking for is more or less a simple factory like method, no need for a whole controller.
If you can't use a trait then you'll have to use a component or just put the above code not inside a trait nor a component but directly inside your AppController, but you won't be able to use it outside the scope of the controllers that inherit that controller then.
I'm trying to understand Tests and Mockery a bit more with Laravel. I have a repository pattern setup, which my controller users. I want to test my basic getAllUsers()method:
public function test_get_all_users_method()
{
$repo = Mockery::mock('Acme\Repositories\User\UserRepository');
$repo->shouldReceive('all')->once()->andReturn('foo');
$controller = new Acme\Controllers\Api\UserController($repo);
$response = $controller->getComponents();
$this->assertEquals('foo', $response);
}
As I understand it, I'm mocking my UserRepository, and I expect my UserRepository to have it's all() method hit. This returns some dummy data and I expect to see this in my response output.
So that works fine. The all() method exists in my Eloquent implementation of the repository. However, if I remove the all() method, the test still passes... Why would it? Surely the test should fail.
If this is normal, I'm struggling to understand why I'd test my controller like this, since I could pass any old method name into it even if it exists or not.
Cheers
That's how mockery operates by default, I like it that way because it allows me to develop by wishful thinking, i.e. I wish my UserRepository interface had an all method.
You can tell mockery to disallow it though, it's a bit ugly, but you can put this in your test bootstrap file:
\Mockery::getConfiguration()->allowMockingNonExistentMethods(false);
You could also set this up to control it with an environment variable or something, so you allow mocking non-existent methods during normal use, but prevent it on your continuous integration run etc.
Background: I'm working on an MVC framework for some practice, and want to make sure everything is 100% unit tested.
The setup currently is to have an instance of the application class (Ex_App). The main script asks a Dispatcher/Router for a controller name. This controller name is the name of a class implementing Ex_Controller. The result is returned as an instance of Ex_Dispatch_Result. This result is passed to the Ex_App instance using an invokeController($dispatchResult) function.
And this is where magic happens. The listing below is an excerpt:
$controllerName = $dispatchResult->getControllerName();
... checks for validaty of class name ...
$controller = new $controllerName();
$controller->prepare($this);
I'm using PHPUnit to do my unit testing, and am able to mock the dispatch result, correctly check that validating the class name of the controller works. The problem is how to check if prepare is called.
I'd like to do something similar to:
$mockController = $this->getMockBuilder('Ex_Controller')
->setMockClassName('Invoke_Correct_Controller')
->getMock();
$mockController->expects($this->once())->method('prepare');
However since a new instance of Invoke_Correct_Controller is created upon calling invokeController, it will not be this mock and thus the expects() call is completely irrelevant.
I could make the Ex_Dispatch_Result class responsible for returning a controller and testing that, but before returning an instance I will need to verify the correctness of the class name and in my opinion that responsibility should be with the Ex_App class and not the "dumb shell" Ex_Dispatch_Result class.
Is there something I am missing in the PHPUnit framework that I could use to test the code here, or some useful pattern that could work in my instance? I feel passing around controller names scales way better than passing around instances of controllers from the start, requiring the initialization of every possible controller. So, I kinda want to stick to passing around names and using the Ex_App as a factory for the controller instance.
Maybe I'm just over-thinking part of this problem, but that happens sometimes. It's why a fresh look by a third party often works :-)
There are couple of things you could do:
Extract controller creation logic to separate class e.g. ControllerFactory, and then mock controller factory instance, so that it returns your $mockController.
Extract controller creation logic to separate method and use partial mocking.
Return $mockController from $dispatchResult->getControllerName(), which probably requires mocking of $dispatchResult or even something else.
If you want more detailed answer, please provide more code samples of your classes and methods.
I'm writing some unit tests (PHPUnit 3.6) for my controllers and want to verify that the correct actions etc.. are being fired. This is easy enough. However some of the controllers also perform certain actions via models that are undesirable such as inserting records into a database.
I am aware I need to mock these but am unclear how to do this. Taking the following example controller (cut down for clarity):
public function addAction()
{
$data = $this->getRequest()->getPost();
$model = $this->getModelFactory()->getCompetitionModel()->insert($data); }
}
Note, all I want to do is verify that the correct controller and action have been dispatched but do not want the record actually inserted. Likewise I have equivalents for delete etc.. I don't want records actually deleted.
What actually needs mocking here? The competition Model, the database adapter, or the model factory, or all three? How do I inject these? I have tried (again cut down for brevity):
public function testAddActionIsDispatched()
{
$this->request->setMethod('POST');
$this->request->setPost(array($data…));
$modelMock = $this->getMockBuilder('Competition_Adder')
->disableOriginalConstructor()
->getMock();
$factoryMock = $this->getMockBuilder('ModelFactory')
->disableOriginalConstructor()
->getMock();
// Configure the stub.
$factoryMock->expects($this->any())
->method('getCompetitionModel')
->will($this->returnValue($modelMock));
$modelMock->expects($this->once())
->method('insert')
->will($this->returnValue(true));
$this->dispatch('/mymodule/add/');
$this->assertController('test');
$this->assertAction('add');
$this->assertResponseCode(200);
}
}
It was my understanding that PHPUnit magically substituted any references to the originals with the mocks so that when the dispatch was called the fake mocks are used in their place. This isn't happening. Can someone please clarify how this is achieved?
It looks like your mocks are set up correctly. I actually didn't know you could return mocks from mocks until I saw your question and researched it a bit.
What's happening here is that you need to make the method getModelFactory() return an instance of your mock factory. Right now it just returns the real thing.
I'm not sure what happens in your getModelFactory method, so it is hard for me to say how you could override it to make it return your mock factory.
But maybe you don't have to override it. In my ZF app, I don't test controllers, but to test stuff that requires saving stuff to my models, I just change to a test database in my configuration file for testing. I use Doctrine1.2, so I just start a transaction in the setUp() method and a rollback in the tearDown method().
My test database is completely empty, and I basically create the necessary data in each test method with some test specific factory classes. The drawback is it does seem to use a lot of memory. I think it hits 200MB on about 140 tests and not all of these require database access.
I just use this method since it is the easiest for me to implement since I only had to change the database config. If you're not working a very large scale project, this may work for you. You could also run your tests against a test database using sqlite in memory, which should work for you since are not testing the database in your test. The data just gets inserted and then at the end of test, it's gone. In my project, I use a MySQL test database, because I wanted it be as close to what is in production as possible.
Example (You're probably not using Doctrine. I'm just illustrating how I use transactions and rollback to keep my test database in a consistent state):
public function setUp()
{
$this->bootstrap = new Zend_Application(
APPLICATION_ENV, APPLICATION_CONFIG);
parent::setUp();
$bootstrap = $this->bootstrap->getBootstrap();
$this->_conn = Doctrine_Manager::connection();
$this->_conn->beginTransaction();
}
public function tearDown()
{
$this->_conn->rollback();
$this->_conn->close();
}
Yep, check out the previous answer. I can agree in all cases. But the same thing can't be implemented with MySQL and Zend_Db. That's because Zend_Db doesn't have nested transactions.
So the only thing you can do is to use test database and rebuild it after each tests.
Check out how it is done via Codeception testing framework with Zend Framework and Db module.