[MUSIC]

Hey, everyone.

It's Chris again.

Previously, I talked about writing your first test by going over how I like to

create testing scenarios.

Now, that we've learned a little bit about how to go from scenario to working test.

Let's tackle, one of the bigger problems that developers will face.

Writing tests for code that already exists.

Through much of this course I

will be using code samples from the Open CFP Project.

It's an open sourced web application written in PHP that helps

programming conference organizers manage the top submissions that come in.

Much like the cobbler's children in the story of old.

Open CFP does not have enough tests.

Let's see if we can fix that by finding some code that doesn't already have

tests for it.

After running my tests with the code coverage option,

I can identify thing that need some more test loving.

Code coverage simply means, when you run the tests,

identify all the code that got executed during the tests.

Typically, you aim for a high level of code coverage.

Ideally, you want 100% coverage.

But anything 90% and above is quite good.

It still means you have code that you haven't tested though.

In Open CFP, we have an object that represents speakers.

At the time I generated the coverage report, we're at 52.88% coverage.

That's terrible.

Let's pick one method inside the speaker object that has no tests and write one.

We might also have an opportunity to refactor the code in question because it

is difficult to test.

Do not underestimate how often you will have to

do this if you are adding tests to a project that is already under way.

In this one I'm gonna talk a little bit about how you identify what tests to

write for existing code.

Normally, it is nice when you're started on a brand new project that you're able to

write tests for every little bit of code that you write, right from the beginning.

But often that's not the case.

Often times you have tests for

existing code and you'll need to get more coverage for that particular bit of code.

And by coverage I mean, making sure you have enough test that every line of

code inside a particular method is getting tested.

So, I'm gonna show you an object from my Open CFP project, that represents

information about a speaker, and we're gonna look at one method inside there.

And, assuming that we have no tests for

it already, how will we identify exactly the type of test that we need?

So, I'm gonna open this up.

And we're gonna go.

I'm just gonna use Vim here and tell it to find me, where it says function update.

So this is the update method where we're gonna update a speaker record.

As you can see, we start off with here, in the doc block above we're showing,

what parameters we're gonna be passing in.

We have speaker details and then we have the existing details.

The purpose of this bit of code is to say, when I've gone into a person's account and

they're updating their own information, we wanna determine whether or

not we need to update the existing information in the database.

So, you know, this is always the thing that asked me, what am I supposed to test?

I think,there's actually one really simple rule that you need to follow.

Every single conditional statement in a method needs a test.

So, if we are looking at this actual code,

we can identify some bits of code that need attention.

For example, we would need to write a test where,

remove the old photo if a new one has been uploaded, so use unlink.

We are also doing a comparison that says, if any of these items are different,

if anything between the existing record in the system and what the user wants to

update, there's any difference, then we wanna do an update statement.

Also, have a condition thing here that says, if you know,

we're checking to see, do we have an existing record that we need to update?

So, we're doing a SQL query, hitting the database.

We then do a comparison here, conditional statement if we get back a speaker count

and the speaker count is one we're gonna have to do some updates and on and

on we go, we also have here if the speaker count.

If we don't have any speaker information then we need to create a new record so

we're doing an insert.

So that's basically it.

So how many numbers is this?

If we go back and count, I believe the number is seven, so,

this means at a minimum, we would need at least seven different tests.

We wanna make sure that every conditional statement is covered by a line of code.

But however, there is one bit of code that we would need to refactor in

order to write a nice unit test.

It's this little section right here by removing old photo.

As you can see, we're doing an action on the file system.

We're using unlink,

which is a command that PHP can use to actually remove a file.

This is problematic for two reasons.

For number one, during a test you don't wanna actually ever destroy anything

that's in production.

So, you can see that we, we are actually going to physically delete the file.

And secondly, this is a dependency inside the object itself,

inside the method that we need to unlink it.

So, if I were to refactor this bit of code to make it easier to test, I would

take this bit of code that is checking to see if the speaker photo is different.

I would create some method calling delete speaker photo and

then in whatever code is actually calling the update method.

Right after it, we would call some sort of method.

We would probably call it like clean up photos or something.

So, it's very gentle introduction to this,

as you can see the unlinking of the file system is, is bad to doing the test.

If I were to do it there are several tools available to us that would let us

create virtual file systems for testing purposes.

The most common is called, VFS Stream.

I'll put a link in the teacher's notes so you can kinda get an idea of how it works.

Basically, it lets us create a file system that's in memory.

So, instead of writing to the file system,

we're actually writing to a phantom file system that's in memory and

then when the test finishes that little file system goes away.

And then we don't, we don't have to actually touch or

disturb anything in our existing application.

So, to recap my own personal strategy for

figuring out what tests need to be written for existing code.

You just need to look at the code, look at all the conditional statements inside it,

figure every conditional statement is at least one test that you

need to trigger that conditional statement.

And also you need to take a look and

see are there any dependencies inside that you need to move out

from inside the method into its own standalone thing for testing purposes.

We already have some existing tests, so

luckily, we don't have to write tests for everything inside this method.

In our next video, I'm going to show you how I picked one section of the code that

had no testing coverage, created the testing scenario and

converted the scenario into a working test.

See you next time.