Original subtitles

If you write your tests first, then you'll be forced to write code that is easy to test.

So the first step of test driven development is to identify a meaningful test cases from the requirements

when the story adds a movie to its collection.

We need to check if the story contains the movie that was just added.

Testified.

The store contains the movie after its added.

If that test succeeds, then we know that our code works.

The second thing we need to check for is if a movie gets removed after we sell it.

Test if the movie gets removed.

After being sold.

And now in the event that someone tries to buy a movie that was already rented, we need to make sure

the application throws an illegal state exception test for an illegal STD exception for selling a rented

movie.

The other two test cases should be fairly intuitive if someone rents a movie, we need to check if that

movie becomes rented, test if the movie becomes rented.

Otherwise, if someone returns a movie, we need to write a test that ensures the movie is available

again.

Test if the movie is available again.

If all of the tests we write pass, we can rest assured that our code doesn't have any bugs.

Now, you might be wondering why did I code the constructor getters and setters without unit testing

them first?

That's because they're always doing the same thing and testing them is meaningless.

They don't offer meaningful logic.

OK, that's all for part one, we've identified every meaningful test case and now we can start unit

testing.