Hi, and welcome to the final video on writing test cases.

In this video, we're going to actually putting a lot of the theory from

the last video into our test case, and try to add some common Edge cases

to the text input field for the edit named feature.

We should be looking around the application for

everything that a user can input.

The RSVP app has one that we just tested in the previous video,

this edit name text box that we can see right here.

Now, the acceptance criteria for

this feature never specified how long a name should be,

how many names it can have, or any special characters that are allowed here.

Let's try all those out and add them to our test case.

We're going to add these test steps onto

the original Invitee Edit test that we started in the last video.

Right now the test is very happy path.

We click edit, changed the name, and save it.

But it doesn't really give us a lot of confidence that this feature is going to

work for our other Edge cases.

Let's add a new step right after saving the new name step.

For this step, we simply wanna get back the edit screen.

So click edit button with an expected result of

Text box appears with 'Test Person',

which is the name that we changed it to earlier.

Note that this is also testing the ability to re-edit something that we just saved.

Our first Edge case is users who enter in way too many characters in the name field.

To test this we are simply going to type in as many characters as we can.

But we expect that the app has a hard limit of 150 characters for this field.

So for our next test step, adding in a new one,

let's put Enter more than 100 characters and save.

Let's go back to the RSVP app just to see what that looks like.

We don't really care if someone has one name or multiple names, we just wanna

limit the amount of characters so that it doesn't throw off the display too much.

If a person has one word for their name but many, many characters.

So let's just type in Manymanymanymanymanymanycharacters.

And we just wanna test that it doesn't throw the display off too much.

You can see here that that many characters does expand how much room this card

takes up.

So it'll force the area the box renders in to be much larger than usual.

We really don't want that to negatively affect the app's presentation.

By the way, a really easy way to test how many characters are in your word,

is to open up a notepad application that has a line number and a column counter,

such as Adam.

Or look up a character counter website,

like the one that I'm at right now called CharacterCounterOnline.com.

When you type in the word,

you should see the amount of characters there are as you type them.

It's safe to say that we would want some kinda error to appear if the user enters

in more than 100 characters.

So our expected result that we would wanna see is Textbox is red and

error appears: 'too many characters,

please enter a name less than 100 characters'.

Note that this is not necessarily what we are going to see in the app right now.

Remember that we want this error to happen and we want it to be helpful to the user.

I'm sure you've experienced errors in programs before that simply read error,

with no other context for why that happened.

When possible an error should both tell the user what went wrong and

how to fix it.

We also wanna test that putting in the very maximum amount of characters works

properly.

So let's add another step.

Enter 100 characters with no spaces and save.

With an expected result of Name is saved and the text box,

Stays inside the boundaries of the application.

We're trying to make sure that entering one single long name doesn't break

the appearance to the app, but still saves properly.

So I'm going to enter in a very very long name again.

Long name with a many, many, many characters.

And when I save this box it should take up its own line entirely.

But you'll notice that it still fits.

One other Edge case I can think of that will happen pretty often is that users

will wanna put quotes, or parenthesis, in for someone's nickname.

Or they might wanna trademark someone's name just as a joke.

So for our next step we want to ensure that many special characters are allowed.

So let's go back to the test case, and add in a special character step.

Special characters are just about anything that's not an alpha-numeric character, so

things like asterisks, parentheses, pound signs and dollar signs, or

even more esoteric things like copyright symbol or the omega symbol would count.

The reason I wanna test this is that oftentimes special characters

present awkward challenges to the databases,

HTML links, and even some JavaScript functions if they're not saved properly.

Since we're fairly confident that our users will wanna use these characters,

let's add it in as a step.

So let's add a new step.

And we'll say Enter,

and then just choose some of the keys that are at the top of your keyboard.

I like to enter most of them in, And save.

This is just a string of characters that you can easily find, obviously.

But for fun, let's also add the registered symbol,

which I've added to the teacher's notes at the bottom.

And I'll just add this in right there.

You could also enter it as a special key combination on your

keyboard if your operating system supports it.

Our expected result is simply that the special character save and

display on the site.

So let's add that in.

All special characters, Are saved as the name.

Lastly, there will probably be some cases where users delete the name and

forget to add the new one before saving.

So let's verify that the name field is required when editing the name.

If a user erases everything in the field,

we will want to remind them to enter something.

So for our last step let's write, Edit and

delete all characters from text box, then save.

Our expected result would be, Textbox is red and

error appears: 'You must provide a name'.

Great, note on that last step I added a lot of our previous steps into one.

Tests should generally start very atomically.

But as the steps become more repetitive it's okay to start putting some

simple steps together,

especially after we've established that those actions work in previous steps.

And that does it for building out our first test case, and

adding in some common Edge cases.

We're now testing more than the happy path of editing a username,

we're also testing Edge cases where the user might experience an error.

We also want to make sure that errors are helpful to the user when they

experience them, with some sort of advice on how to fix it.

Edge cases are all about thinking outside the box.

So hopefully these examples will help you think of ways to do that within

the features that you'll be writing tests for.