Programmers rarely have the opportunity to work with code that they create from scratch. Often, we have to support systems that have been there for several years and were written at the time when programmers were paid for the number of typed lines of code. However, this is not always the case. Nowadays, when there are so many start-up companies emerging, people tend to sacrifice quality for money. It's all about faster delivery of new features. How you write your code is not that important until the application works fine.

This leads to maintaining legacy systems (take a look at Working Effectively with Legacy Code, Martin Feathers, available at http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052, for details on how to work with such systems). Such code monster-like classes are also called god classes. Most likely, their names end with a manager or helper suffix since they do everything and have access to all the possible dependencies in the system. Methods have hundreds of lines and there are no unit tests (not to mention integration or acceptance tests). Sometimes, the scenario we find once we start working on a project is not that bad, but the concept may be alike. Usually, there is no quality control and the project managers require the teams to deliver more. We have to make the code operational for now without having any broader strategic vision of how to run a project.

Working in such an environment may be frustrating and scary in terms of making any changes to the code—without the tests, how can you be sure that you didn't break anything? Well, you can't—that's why this chapter will show you how to deal with some of the most horrific coding practices I've seen in my career.

I'd like to highlight that some of the code presented in the subsequent recipes is written terribly on purpose; if you find a similar snippet in your codebase, you will already know how to refactor it. We are assuming a case in which we work in a system without tests. In this way, we'll try to first write tests for the existing functionality and then remove the bad design while already having some tests.

I'd also like to emphasize that there are whole books written about refactoring (for example, Refactoring: Improving the Design of Existing Code, Martin Fowler with Kent Beck, John Brant, William Opdyke, and Don Roberts, available at http://martinfowler.com/books/refactoring.html), and in this chapter, I'll only touch on the subject. The aim of these recipes is to show you how to use Mockito features and Mockito-based tools to test your code.

We'll start off by dealing with quite a common issue that has an instantiation of an object inside our method. We'll see how to mock it, and refactor it immediately after that. Then, we'll try to refactor classes that do not follow the SOLID principles (please refer to the Introduction section of Chapter 2, Creating Mocks, for more information) in order for them to be fully testable. Next, we will move through terrible features such as basing code on class casts—we'll use Mockito to deal with this and to change this preposterous concept into nice code. We will also test and improve code that operates using unnecessary static method execution. Finally, we will take a closer look at test classes that use too many mocks.