Original subtitles

In this video, we'll do the remaining tasks for the bank class now, task five of us to make the add

transaction method private.

The reason we're doing this is because we don't want to be able to add transactions from outside of

this class.

It's the bank that can add successful transactions or ignore failed transactions, so make sure this

is private because the caller shouldn't have access to this method.

All right.

And now going back to requirements that text, there are still some pieces of behavior that we need

to unit test over here.

Depending on the account, some transactions may be denied.

We're going to write to unit tests for this.

We're going to check and see if the bank keeps a record of successful transactions and if it ignores

failed transactions.

And the last thing we want to unit test is if the bank can effectively deduct taxes from taxable accounts.

In other words, from checking accounts because those are the only ones that we made taxable.

All right.

So we'll start writing some unit tests inside, test, create a new file.

We'll call it bank tests the Java.

And before we do anything, I think I left you the initial set up on learning the part, so I'll go

to that right now.

We'll copy this code.

Over to here.

Part the bank class.

In part, the before annotation.

Import the checking class.

And that's all we've got to imports, all right now, we're going to create a unit test at test.

Named successful transaction, so we'll say public void successful.

Transactions.

And inside of this method, we're going to make two transactions a deposit.

Deposits always work because that's how we designed them, as well as a withdrawal, the withdrawal

we're going to make sure is successful.

So we'll copy the code over from learning the parts.

We don't have to do it from scratch.

Desktop bank, oh, yeah.

These don't exist yet, that's fine, we'll have to import transaction.

Import equals.

So this basically confirms the bank has two transactions after a successful withdrawal and deposit.

Now the bank class doesn't have a withdraw transaction or a deposit transaction, so we'll go back to

Bank Java.

You create a public void method called withdraw.

Transaction.

They received a transaction object transaction.

The idea inside this transaction indicates the account where the transaction is going to take place.

So what we're going to do is get the accounts that matches this Transaction ID transaction get ID.

And based on whatever account that we get, we're going to withdraw.

Whatever amount is listed inside the transaction.

Now, remember, that would draw returns a Boolean.

So we're going to check if the withdraw method returns true if it succeeds.

In this case, we're going to add the transaction to the list.

Opie now understand why this is private.

That's because it's only the bank that should have the capability of adding or ignoring transactions.

This method should not be accessible outside this class.

We should still have an error over here, that's because we need to make a deposit transaction method.

So here I'll make another public void method called deposit transaction.

But expects a transaction object.

Once again, we're going to get the accounts.

Where this transaction needs to take place, so we're going to get the account that matches this transaction

ID.

And then from that account, we'll make the deposit transaction Typekit amount.

And no need for an if statement here, because we designed deposits to always work.

They don't even return a Boolean.

And now we'll just say a transaction transaction.

So going back to our test class, if we rerun the unit test.

We get a failure.

The method transaction from the type bank is not visible.

Oh, and that's fine.

Inside the main class.

We're still trying to call our transaction, but remember that we made everything private so you can

just remove all of this.

We don't need it anymore.

That was just for the last video.

OK, we'll proceed.

And the test should work perfect.

OK, going back to requirements not taxed.

Remember that this requirement applies to unit tests.

Now we want to check if failed transactions are denied.

So instead of bank test that Java, we're going to create another unit test test.

Public void.

I'm going to call the unit test failed transactions.

And failed, you know, what will make this singular?

And inside a failed transaction, we're going to make a withdrawal that is designed not to work, a

withdrawal that returns false.

I should already have something set up for you to learn the parts.

I do not.

Well, that's surprising.

So what I'll do is I'll just say this bank that would draw.

I'm going to create a new transaction.

Type would draw.

We can give this any time stamp, it doesn't matter.

The transaction is going to take place inside of this checking account, so we'll copy the idea of this

checking account over here.

And I'm going to make a transaction of a million dollars that shouldn't work.

And now, if you run this test, I believe it should already work because we've already set up the statement.

And perfect.

Before we continue, I'm going to go inside Bank Dot Java, and I want to make these two methods private.

I don't want them being accessed from anywhere except the bank class.

And then what I'm going to do is create a public method.

Public void called execute transaction.

They receives a transaction object.

And depending on what that transaction is, so we'll say switch transaction.

Get type.

If the transaction ends up being of type would draw, then we're going to call it withdraw transaction.

And if it happens to be a tape deposit.

Then we'll call deposit transaction.

OK.

And now if you go back the bank tasked Java, I can just say this that bank execute transaction.

Copy that over.

Can you rerun all of our tests?

We made a mistake expected to, but was three up.

I made a very silly mistake.

Never forget the break your word when you're using a switch.

We're running our tests.

See, that's why our unit tests are so useful, because they'll catch your bug just like that.

OK, that's two out of three unit tests that were done, the final piece of behavior we need to test

is the bank deducting taxes from taxable accounts.

So what I'm going to do is go back to bank tests and I'll create a unit test test.

Public void and the unit test is going to be called tax deduction.

And here what I'm going to do is only execute a single transaction for one account.

So we'll go back here and that transaction is the following.

Here we're making a single transaction of $4000 to a checking account, and the taxable income, I believe,

was 3000.

So our account should definitely get taxed.

Going back here.

The unit test is calling a deduct taxes method, and somehow this is going to deduct taxes from every

single checking account inside of the bank object.

And for this particular account?

The remaining balance after they've been taxed should be the following.

So what we're going to do is write code to make the test pass.

Go over here and I'll create a public method void, deduct taxes.

And I'm going to create a for each loop that runs through every single account in the accounts array

list.

And how do I check if an account is taxable or not?

How do I check if something implements the taxable interface?

Well, there is a very cool syntax that we can use.

I left it for you on there in the parts we can check if taxable doc class that is assignable from account,

get class.

Basically, we're checking if this particular account implements the taxable interface.

Then you can typecast our account to taxable taxable, taxable is equal to or typecast it.

And here what we're going to do is tax the account, we know that taxable objects should implement a

tax method.

So back here, we'll say.

Taxable.

Don't tax the tax method, expect an income, so we'll get the income for this taxable accounts.

OK, now how do we get the income of our accounts?

I'm going to create a private.

Double method called Get Income Notice that I'm making this method private because I only want to access

it inside this class, I don't want the caller to have access to this method.

It'll take one argument or one parameter, I should say.

Taxable accounts.

And inside what I'm going to do is get every single transaction that belongs to this account.

So I'll say transaction transactions is equal to get transactions for this particular account account

dot.

Should be get I.D..

However, the taxable interface doesn't have a get ID method or anything, except this one method over

here.

So what we need to do is typecast as the checking.

Put a bracket around both.

And I think we need to impart this.

And now we're good.

All right, and so this basically gets every single transaction for this account.

What we could do is create a for a loop that runs through every single transaction and take the sum.

But if you can use a stream, you should use a stream.

So what I'll do is return or raise dot stream.

We'll create a stream of elements out of the transactions array.

And then we're going to map the area to double.

So we're basically going to map every single element in the transactions array to a double value will

map every single transaction.

To a double value, so you could just say.

Transaction get amount.

But that would be a mistake.

Think about it.

What if the transaction is off type withdraw, then the amount we return should be a negative, not

positive.

So for once, instead of just having this one liner, we're going to have an entire block of code where

we compare the transaction type.

Against two possible cases.

Case would draw.

We want to return negative transaction, get amount.

And Case Dep., we want to return transaction.

Don't get him out.

Default returns zero.

OK.

And so at this point, our stream of transaction elements is going to be mapped to a stream of double

values.

So here we'll just take the sum of every single element and return that.

This terminal operation is going to return the sum of every single element in the stream, and now we

should be good.

We'll go back to bank test each Java run the unit test.

Perfect.

Now we're going to confirm that all of our tests pass.

And they do.

This gives me comfort that all of the meaningful logic we implemented doesn't have any bugs and that

can continue.

See you in part eight.