[MUSIC]

When you start learning about testing, you very quickly start hearing about

a practice known as test-driven development, or TDD.

It's the practice of writing a test for

a small module or unit of code as if it worked already.

Then write the code until that test passes.

Repeat until you have tests for every unit of code that you've written.

What TDD does is force you to think about what your code looks like

at the unit level.

This doesn't mean that these modules will always be used in the exact

way that you planned.

It's like building with Lego.

Unit testing verifies that each piece is compatible so

that your application can use those pieces when needed.

Let's go build some units from a test driven approach.

We're going to write a simple English to Pig Latin translator.

Pig Latin is a game in which English words are altered

usually by moving the first consonant or

consonant cluster of a word to the end of the word and then adding a y.

So treehouse would become eehousetray.

Let's write the code for this translator in a test driven approach.

In test driven development, we write our test first and

then write the code until our test passes.

Let's add a new file in tests.

We'll name this PigLatinTest.php.

We're going to use PHP unit framework,

TestCase.

And then we'll add the class

PigLatinTest extends TestCase.

We'll add a .clock with the annotation test.

And then we're ready to add our first function.

The main functionality of our converter is to take a single starting

constant word and change it to pig Latin.

So convertSingleStartingConsonantWordToPigLa-

tin.

Now let's walk through how we expect to use our PigLatin converter.

We'll have an English word that we want to convert, and we'll use test.

Then we'll need our expected result.

And this will be esttay.

Next we create a new pigLatin object.

Then we're going to get the result of calling pigLatin->convert.

And passing the word.

Now we're ready for our assertion.

Instead of assertTrue,

we want to make sure that the result equals our expected result.

So we use $this->assertEquals

the $expectedResult and the actual result.

And the third parameter is optional, but allows us to add a custom message.

PigLatin conversion did not work correctly.

Now that we have our first test, we're ready to run our code.

Vendor/bin/phpunit tests/PigLatinTest.php.

Let's fix line 9.

First, it fails because there is not a Pig Latin class.

Let's add a PigLatin class to our source directory.

Class, PigLatin, now let's run our test again.

It's giving us the same error even though we have a class file.

That's because of the way we are autoloading.

If we look in vendor, composer, and our autoload_classmap,

we can see that our email is being included.

But nowhere in here is it adding our Pig Latin.

We need to run Composer update again to grab our Pig Latin file.

You only have to do this when you add files you need in your classmap.

If you're using proper name spacing for

your project, this is a different way of telling Composer where to look for

class files, and you don't need to update Composer each time.

We could also require the specific class we need directly in our test files.

We could require once,

Source, PigLatin.

But we already have our auto-load working, so let's comment this out.

Now let's run our test again.

This time, it tells us that we do not have a convert method.

So let's add that.

The function convert should accept a word, And

then for now we're just going to return the word.

Now let's run the test again.

This time we get a normal failure message,

we were expecting esttay, but instead, we just got test.