1
00:00:00,180 --> 00:00:01,950
The solution is going to cover part four.

2
00:00:02,080 --> 00:00:05,610
We're going to come back to this test case, but the next one tells us to make sure we calculate the

3
00:00:05,610 --> 00:00:06,689
correct subtotal.

4
00:00:08,710 --> 00:00:11,260
So I'm going to write a unit test named subtotal as valid.

5
00:00:26,970 --> 00:00:28,800
Each item in the cart is one ninety nine.

6
00:00:30,060 --> 00:00:34,050
So our unit test is going to assert the price we're expecting 398.

7
00:00:40,430 --> 00:00:44,180
Is equal to the price that gets returned by cart, get subtotal.

8
00:00:49,290 --> 00:00:52,300
And now inside Córdova write code to make the test fail.

9
00:00:52,560 --> 00:00:55,980
I'll define a function that returns a double named get subtotal.

10
00:01:01,060 --> 00:01:02,950
And for now, we'll return a random number.

11
00:01:09,640 --> 00:01:13,090
Our test fails, that's fine, let's write code to make it pass.

12
00:01:17,280 --> 00:01:21,450
Inside, get subtotal, I'm going to add a temporary double subtotal variable.

13
00:01:28,480 --> 00:01:31,300
And then create a loop that runs through the size of the array list.

14
00:01:39,750 --> 00:01:43,830
And during each run, I'm going to add the price of each item to the subtotal.

15
00:01:53,640 --> 00:01:55,260
And then return the subtotal.

16
00:02:05,720 --> 00:02:08,960
If we run our test now, it works, the assertion passes.

17
00:02:10,520 --> 00:02:17,000
But can get subtotal be any simpler, yes, loops are messy, you should always favor running the Israelis

18
00:02:17,000 --> 00:02:18,740
through a pipeline of functions.

19
00:02:33,270 --> 00:02:38,970
You learned about the intermediate operation map map updates every element in the sequence.

20
00:02:40,670 --> 00:02:46,540
But map to double, expect you to update every element in the sequence with a double value just like

21
00:02:46,550 --> 00:02:51,650
map and expect to lambda expression, the Lambda receives each element in the sequence as a parameter.

22
00:02:57,080 --> 00:02:59,420
And for each element, we're going to return the price.

23
00:03:05,200 --> 00:03:08,580
So at this point in the pipeline, our stream is full of double values.

24
00:03:08,620 --> 00:03:14,050
More specifically, we have a double stream and every double stream is capable of calling the terminal

25
00:03:14,050 --> 00:03:15,220
operations some.

26
00:03:15,820 --> 00:03:20,790
Some is a terminal operation because it ends the pipeline and it returns the final results.

27
00:03:21,160 --> 00:03:24,920
In this case, it's going to return the sum of every price in the double stream.

28
00:03:25,750 --> 00:03:27,670
And to me, this looks a lot better than before.

29
00:03:27,850 --> 00:03:33,520
And as always, as you refactor run, the unit has to make sure there aren't any bugs and there aren't

30
00:03:33,520 --> 00:03:33,760
any.

31
00:03:36,230 --> 00:03:41,390
Now we ask ourselves the same question, can the code be refactored and the answer is yes.

32
00:03:41,720 --> 00:03:46,850
If your expression is only a single line, then you can remove the curly brackets as well as the return

33
00:03:46,850 --> 00:03:47,390
keyword.

34
00:03:47,630 --> 00:03:52,280
And Jeff is going to know you intend on returning each double because not to double expects it.

35
00:03:54,420 --> 00:03:57,600
Again, working with lambda expressions really simplifies your code.

36
00:04:00,730 --> 00:04:05,890
We on the unit test and beautiful once again, can the code be refactored?

37
00:04:06,130 --> 00:04:07,150
Nope, we're done.