We do have a lot of testing code now. More test code than production code, in fact. It's time for us to learn how to make test code more readable and maintainable. Let's start by removing repeated code.

And what about this famous "one assert per test" rule? I will tell you why I disagree with it, and how to make our assertions better.

Giving names is one of the most important thing when writing a test. We will discuss about how to give a test a name. It's easier than you think.

Time to go to the next level. Let's start by testing a more complicated class with different conditions and private methods. How do we do it?

Uhhh, now we have a very complicated private method. Should we test it isolated from the public method? Should we not? Let's talk about it.

Creating scenarios is, for sure, the hardest part when writing the test. Let's learn that "test data builders" are. They will save our time when dealing with more complicated scenarios.

Can we start the test ... by the test? Let's learn about Test-Driven Development, and see why this is a very popular practice among developers.

Should I go faster? Should I go slower? Let's discuss about taking "baby steps" during your implementation. Do they help? Should I do it all the time?

Now, let's see how we can convince our managers that we are not losing time when we are writing automated tests. I will show you some very good arguments. After that, even your boss will tell you to write tests.

It is your time to practice.

Again, going to the next level. How can we test classes that depend upon another classes? What if I depend upon a DAO, that access my database? Easy... Let's simulate them using mock objects.

What if I use a crazy API in my code? I can't mock it. Hmm, yes, you can. All you have to do is to write a little bit more code. I will show you.

It's your time to practice.

Let's review everything the talked about and see how much we learned when we started to study automated software testing.