[34/38] - Tested Image Preview... Sort Of :)

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

test driven approach to wallpaper updates and this time we're looking at adding in the

image preview feature which is when we go to edit or update an existing wallpaper as

long as it's got an image associated with it we would like to see that inside the Easy

Admin Bundle backend. Now there's a bunch of ways that we could go about testing this and the only way that

we're going to cover in this video is to do so using PHP spec but because this is a visual feature

you may wish to use a tool like Selenium and a library such as Codeception or BHAT to actually

test that that behavior the behavior of seeing the image come on the screen is happening as expected

because we're only focusing on the PHP spec side of things we're not going to be able to test

every single part of this process specifically we're not going to be able to test the template

if we look under app, resources, views. And then under our form

we've got our image underscore upload HTML twig template and our PHP spec test is not going to be able to touch on this

Instead, we're going to focus on testing our uploaded file type. And to begin with, we'll test the existing implementation

which is all the stuff that you see on the screen currently. And then we'll copy in parts of the implementation

from our untested approach, which predominantly will be this piece around build view

where we're wanting to add in a file URI, depending on whether we're in a create or update screen depends on whether we want to have access

to a path on that file uri or not so as it stands currently we don't yet have a test for our uploaded

file type so let's go ahead and create one and i'm going to run this straight away to make sure that

php spec is passing and that looks good so i've gone ahead and i've opened up the uploaded file

type and the uploaded file type spec and we're going to get started by adding in a new test

And in this first test we gonna check what happens when we call build form So if we mock the builder then after we called build form we would like to assert that the add method was called with the arguments of file

file type class, and the options of multiple being false. So we'll call our function, it can build a form

And to get ourselves started, we'll call this build form. And we know that build form expects to be given an instance of form builder interface

and an array of options. So we'll mock the form builder interface and even though we don't own it

because it's an interface we should have no problems here. We don't need to mock the array

we'll just pass in an empty array anyway. And so our assertion is that after build form has been

called our builder mocks add method should have been called with the arguments as they are in our

existing function so we'll say should have been called let's make sure that we import this file type class and let's see where we get with that

next up we need to test the build view method and straight away we can see that our form view

which we will be using here is not an interface and even worse we're using a public property

which is this array of vars but even so let's give it a shot and see where we get so create a

new function which says that it can build a view and we'll know that we need to call this build

view and build view takes three arguments the view the form and the options so say we'll have a view

variable a form variable and an empty array of options now we have neither the view nor the form

So I'll just try and get PHP spec to mock these. And our assertion here is that after we've called build view

whatever we have set as the full underscore name on our view vars

should be concatenated with the string open brackets file close brackets So on our view we start off by setting on the vars this full underscore name key to have the value and we just have QWERTY as the value

So our assertion will be that after we've called build view, our view vars full name should return QWERTY open brackets file

Okay, let's give this a shot. And unfortunately that doesn't work. We can see here an indirect modification of overloaded property

vars has no effect so that's a bit of a scary looking notice that we're getting there

so let's see what we can do so we already know that we shouldn't be mocking what we don't own

so let's try refactoring this we'll start off by creating a view which will be a new instance

of the form view and is that good enough to get us to where we need to be well let's try our tests

okay slightly different problem now we're getting an exception call to a member function should

return on a string so here we are view vise full name should return and then this string so the

problem is that should return is being called on whatever is set into view vise full name which is

a string so that's where the error is coming from we've set a string here and then we're trying to

call a method on that string so that's never going to work so we're in a bit of a problem here we

can't mock it and because we don't own it as in we don't own the form view there's not a lot we can

do there to change it. I don't want to get into this situation where we're trying to wrap that as

well. So I'm going to cheat a little bit here and I'm going to use a different library to get myself

around this problem. So we're going to use the assert library from web mozart and if you aren't

aware web mozart or bernard schussick hopefully I'm pronouncing that right was the main creator of

symphony's form component. So there's a little bit of irony there that we're having to use a different

one of his libraries to get around the problem with another of his libraries, but hey ho

So that all looks like it's gone through okay. So I going to get rid of this should return statement down the bottom here and instead I going to do an assert the same so this is checking that two values are the same and what we want to do is check that after build view has been called the outcome of view bar full name is equal to qwerty

open brackets file close brackets let's try that and that looks good now just to be certain that

we've not just cheated completely here let's try adding another assert and we'll say assert true

on false so we should expect this to fail and it does so that's quite nice we know that our

assertion is actually working as we intend so all we have left to test now is the configure options

method and again we can see that that is not an interface but we're going to try our look all the

same so we'll say it can correctly configure options and again we'll say this configure options

which in this case is going to take a resolver so start off by trying to mock that

and a little bit of truth from me here even though we shouldn't mock what we don't own

typically i start off by trying to and only really adapt if i can't now this may be going against

like best practices and whatnot but honestly it works in my projects and as i say i adapt when it

doesn't so for me it's good enough your opinion may differ and that's okay too and all we want to

do here is check that this set defaults method was called on our resolver so we'll say should

have been called and we will need to make sure that we've got the symphony uploaded file as a

use statement inside our spec let's give this a shot too and that's looking good so this brings

us to a point where we have a working test spec for our existing implementation and now with that

test spec in place we can confidently make changes knowing that if all our tests are passing at the

end we didn't break anything and we're going to get on to changing this uploaded file type in the

very next video