Preface

If you've been a software developer for a long time, you have certainly participated in software conferences or developer forums and experienced many interesting conversations. They start out well with one of the developers describing a cool development process that he/she follows, and then another developer strikes with a cutting-edge technology or tool or a mind-boggling enterprise integration pattern that he/she works with. Each speaker attempts to outdo the last speaker. Old timers speak about ancient machines that had to be programmed with punch cards or switches, where they had only few bytes of RAM, or they start describing COBOL as a dynamic language that follows the Model View Presenter pattern. Ask them three questions: "How do you unit test your program?", "Can you alleviate high blood pressure by monitoring your pressure more often?", and "Have you ever maintained your own code?"

I asked the first question to more than 200 developers. Believe me, 80 percent of developers replied, "We pay our testers or we have skilled testers." Five percent said, "Our customers test the software." Now the remaining 15 percent do unit testing and use print statements or write JUnit tests.

It is insane to keep doing things the same way and expect them to improve. Any program is only as good as it is useful; so, before applying complex tools, patterns, or APIs, we should verify whether our software functions or not. We should configure our development environment to provide us quick feedback of what is being developed. Automated JUnit tests help us verify our assumptions continuously. Side effects are detected quickly and this saves time.

As Martin Fowler states Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

We can write obfuscated code to impress our peers, but writing readable code is an art. Readability is a code quality.

Can you treat high blood pressure by monitoring your blood pressure more often? No, you need medication. Similarly, we should analyze our code to improve our code quality. Static code analysis tools suggest corrective actions, which means we should continuously monitor our code quality.

Always code as though the guy who ends up maintaining your code will be a violent psychopath who knows where you live. We work in brand new greenfield projects and also in existing brownfield projects. Greenfield projects always follow test-driven development to deliver maintainable and testable code.

Test-driven development is an evolutionary development approach. It offers test-first development where the production code is written only to satisfy a test. The simple idea of writing a test first reduces the extra effort of writing unit tests after coding. In test-driven development, test doubles and mock objects are extensively used to mock out external dependencies. Mockito is an open source mock unit testing framework for Java. It allows mock object creation, verification, and stubbing.

As Winston Churchill states We make a living by what we get, but we make a life by what we give.

We inherit the legacy code from someone else—it may come from a very old existing project, from other teams who cannot maintain the code, or may be acquired from another company. However, it is our duty to improve the quality.

This book is an advanced-level guide that will help software developers to get complete expertise in unit testing in the JUnit framework using Mockito as the mocking framework. The focus of the book is to provide readers with comprehensive details on how effectively JUnit tests can be written. Build scripts can be customized to automate unit tests, code quality can be monitored using static code analysis tools and code quality dashboards, and tests can be written for the Web and database components. Legacy code can be refactored. Test-driven development and Mockito can be used for software development; JUnit best practices can be followed.

Armed with the knowledge of advanced JUnit concepts, test automation, build scripting tools, the mocking framework, code coverage tools, static code analysis tools, web tier unit testing, database tier unit testing, test-driven development, and refactoring legacy code, you will be pleasantly surprised as how quickly and easily you can write high-quality clean, readable, testable, maintainable, and extensible code. With these kinds of skills in your next software conference, you can impress the participants.