All language subtitles for 006 Test Driven Development – Part 2_en

There are two parts to test driven development, the first step is to identify a meaningful test cases

and from the requirements, we identified three test cases.

The goal of part two is to write a unit test for each case.

First criticalness name, check out West Java.

We're going to write a unit test for each test case and to write a unit test to write the test annotation.

The first unit test is going to check if the subtotal equal to the sum of each price.

So I'm going to call my test, subtotal is valid.

OK, here comes the interesting part, we're going to make an assertion.

Assert equals means comparing the value that we're expecting with the value that gets produced.

What is the value that we're expecting?

Let me take out my calculator.

I'm going to add all my numbers up.

And we get nineteen point two.

That's the expected value, the value that we're expecting nineteen point two must be equal to the actual

value that gets produced from a function we're going to call.

Let's say Maine gets subtotal.

So at this tells us is now we have to create a function called get subtotal instead of main Java.

Public static double.

Get subtotal.

And Freneau just returned in zero.

Why am I returning zero, remember, the three steps of Testerman development is first you have to write

a test that fails.

Let's run the test.

And it feels.

If you read into the air, it expected nineteen point two, but what we got back was zero.

OK, now step two is to write the simplest code we can think of to make the test pass.

So what I'll do is I'll create a for a loop that runs through the length of the prices array.

Then I'm going to create a temporary variable.

And add the price of each element to the temporary variable.

Then I'll return temp.

And now how do I know if my code is fine?

Well, let's just run a test.

And while it fails, I must have made a mistake, I must have a bug, it was expecting nineteen point

two, but the function returned eighteen.

That's a bug.

And the beauty about unit testing is I can keep testing my logic until it works.

So let's find out what's wrong.

I'm going out of breakpoint here.

And I see if I say temp is equal to zero, it keeps typecasting the double to a whole number and eventually

the test is going to fail because when you remove the decimal places, the answer becomes inaccurate.

So I'm going to fix my code.

Run my unit test.

And we get a checkmark, click on it and beautiful.

I hope you can now see how unit testing helps you avoid bugs.

I genuinely made the mistake of making this an inert variable.

I wasn't paying attention.

And the unit test told me that there is a problem in this unit of my code and it said make sure to fix

it.

And so I did.

Now we're done.

Step two, can we refactor, can the code be made simpler?

Yes, instead of a loop, you can use a stream, but you haven't learned the streams yet.

So for now, given what we know, I can't think of a simpler way to accomplish this.

So that's it.

Now we're going to write a unit test for the second case.

Right, the test annotation.

And this unit test is going to check if tax gets calculated during the check up process is valid, public

void tax is valid.

We can start off by making an assertion.

If I call Maine, get tax.

And passing a subtotal of 30, what's 13 percent of 30?

So the value that we're expecting is three point nine.

So what value is get tax going to produce first al-Qaida function called get tax?

And according to our unit test, it should accept a subtotal.

So for now, just return zero.

Why am I returning zero again, remember that three steps of Testerman development first, right, a

test that fails.

Let's run the test.

And it fails if you read into the error, it tells you the assertion failed, it expected three point

nine, but the result it got was zero.

So now step two is to write the simplest code we can think of to make this test pass.

So what I'll do is I'll return the parameter time zero point one three.

OK, now how do I know if my coat is fine, let's run a test and it fails?

OK, I wasn't expecting that.

Let's see what happens.

OK, and that's the issue with doubles.

When you start multiplying and dividing, you'll get a lot of decimal places.

Sometimes the zeros can keep going forever and then at the end it gets out of whack.

So what I have to do is keep fixing my code until the test works.

In this case, the problem is the infinite zeros.

So what I need to do is convert the price to two decimal places.

This is where you can go and stack overflow and look up how to round a double to decimal places.

I don't like this answer.

I don't like this answer.

OK, we can create a new object of the decimal format class, and in the constructor we can specify

the number of decimal places and then it appears we can use a format function call must do just that.

I'm going to put a new object to the decimal format class.

And inside, I'm going to pass in two decimal places.

And then we can format the tax to be two decimal places.

And it returns a string, OK, that's not good.

But remember, from a string, we can pass a double, so here I can say double Dutch pass double.

And we'll pass a decimal from the following string.

Kate, now I can run my unit test.

And we get a checkmark, click on it and beautiful.

I hope you can see how unit testing helps you avoid bugs.

It literally doesn't let you continue until you fix all of your mistakes.

So we're done.

Step two, can we refactor?

Not really, I can't think of a simpler way to accomplish this, so that's it.

Now we're going to write a unit test for the third case.

Right, the test annotation.

And this unit test is going to check if the total equals subtotal plus tax, I'll call it total is valid.

OK, we can start off by making an assertion.

If I call main get total, let's say.

And passing a subtotal of one hundred and a tax of 13, the value that we're expecting is one hundred

and thirteen.

So what value is that total going to produce?

First, create a function called Get Total.

And according to our unit test, it should accept a subtotal and attacks.

For now, just return zero.

And why am I returning zero again, remember, the three steps of the first step is to write a test

that fails.

Let's run the test.

And it fails if you read into the error, it tells you the assertion failed, expected one 13, but

was zero.

Step two is to write the simplest code we can think of to make this test pass.

So what I'll do is I'll return parameter one plus parameter to.

OK, how do I know if my coat is fine?

Let's run a test.

And it passes beautiful, we're done step two, step three is to refactor the code.

Can I make this code any shorter than it is impossible?

We're done.

This code is modular, which makes it easy to test because every small unit of our app has its own test.

There are no bugs because every test passes.

This code is expressive and it's easy to understand whoever sees this, they can easily understand what's

going on.

And this code is very easy to scale if I ever decide to add something to my code and by accident, I

make a mistake.

The test for that particular unit is going to fail.

It tells me, hey, what, you decided to remove it?

And just like that, we can easily scale and add more code to the application without having to worry

about getting bugs.

To recap, euro code using test driven development and test driven development means writing tests before

writing code.

And there are three steps.

First, write code to make the test fail.

Write the simplest code you can think of to make the test pass and then refactor the code if it's necessary.

We use this technique to write code for a check out process, and the resulting code is highly polished.

Our code is modular, easy to test, immune to bugs.

It's very easy to understand and it's scalable.