[16/38] - Using PhpSpec to Test our FileMover

Hi, I'm Chris from CodeReviewVideos.com and in this video we're continuing our FileMover

test and implementation. Now going back to our implementation, to actually be able to move a file, we can do this in

a multitude of ways. The three that I can think of off the top of my head are to use either PHP's built-in

functions, or we can use something like FlySystem or Galfret, some sort of file system abstraction

or we can use the Symfony file system component. Well, as we're using Symfony anyway, we might as well make use of the components it provides

We've already got them. We don't need to include any other dependencies. And as this is a Symfony service, the way in which we'll get access to that file system is to simply inject it

Now, if you're unsure, what we can do at this point is do a PHP bin console, debug, container

and then we'll pass in file system as the thing that we're looking for. And you can see here it dumps out all the service information for us

The one that we're interested in here will be the service ID, which is file system

all one word lowercase and because we're going to be injecting this we'll need to prefix it with

the at symbol to indicate that it's a service but knowing this if we're going to inject it we can go

ahead set this up via the constructor to inject our concrete implementation of the symphony file

system and notice the use statement's been brought in i'm going to alt and return on that on the mac

to initialize the fields that should all be good and then i going to add the implementation here so it this file system and then there a bunch of methods that you can do with it the one we interested in is rename we going to rename from the existing file path to the new file path and unfortunately this is actually a

void method if we look at it it doesn't return anything it throws a couple of things and that's

quite useful but doesn't actually return anything which is why we can't just simply return the

outcome of this that's why we have to return true so now if we try and run our tests again

you can see that both of them have broken this is to be expected because now we've just changed

the implementation to expect that we're passing in a file system instance but inside our spec

we're not really doing that at all so we can start fixing this by injecting a file system

into each test making sure that we've got the right use statement and i'll just call that fs

just to make it a little bit more shorthand and again we can do it for this one and then what we

can do, apologies, what we can do is do this, be constructed with, and I can say fs to make sure

that whenever we call our file mover, it gets constructed with an instance of the file system

So again, we'll run our test now and we're back to passing because we're injecting the expected dependency. But of course, you don't want to keep having to do this for every single

test that you create. So PHP Specs got a better solution to this, which is the let function. So

we'll just say let, create that, and we'll say be constructed with. That's cool. And that's cool

We don need these anymore so just get rid of them But I do need it inside the let method or the let function So now we should still have two passing tests which we do albeit with a little less duplication

OK, but let's look back at what our tests are actually testing. So we've got it is initializable and that checks that this file mover class exists

And also now in our case that our constructor depends on a file system

It's not really testing anything in terms of our implementation. For that, we've added our own test

It can move a file from temporary to controlled storage. And we call move. with our current location our new location it should return true and that test is passing

we're not actually testing anything to do with this injected file system so this isn't actually

an instance of the file system it's called a collaborator and we can see this if we cheat a

little bit and we'll do a dump here and just rerun our test now and you can see that what's

been dumped out is an object that's an instance of a php spec collaborator and effectively what

this allows us to do is completely fake out the dependencies but also spy on them by which i mean

that we can check now that inside our file mover this file system renamed was called with these two

expected arguments so let's do that so we've got let file system what we're going to need to do is

get access to this file system a little later on in our test and to do that all we need to do is

say this file system or whatever property you wish to create equals fs and then we'll just add that

as a private field. OK so we constructed with it and everything And then we go into our test And after our test is run what we could now do is say this file system rename with these two properties or two arguments should

I say should have been called so we expect this file system rename with that and that to have been

called and if so then we should have a passing test that's quite cool and what it means is if we

jump inside our file mover maybe we change this out to be just one two three just to break it

run our tests you can see that we didn't quite meet the requirements of our tests so we know

even though we're not testing the symphony component which has its own unit tests and is

completely isolated from us we know that if we send in the right arguments assuming that code

all works that symphony are providing and that's a fair assumption to make then our code should

behave in line with that so that's really useful in my opinion and again just to bring that out

rerun the tests and we're all good so really the only thing that's left to do at this point is to

make sure that we have the appropriate service definition set up. So this is really straightforward

We have app service file mover. It's going to have the class of app bundle service file mover

And we know now that it takes one argument which is the at file system. So let's just take a quick

copy of that. Do a php bin console debug container. Paste that in and you can see well it didn't

throw an error so we can be pretty certain this service is properly configured

Thank you