Chapter 2. Working with JUnit and Mockito

This chapter covers the unit testing concept, JUnit 4 framework, Eclipse setup, test doubles, and mocking with Mockito.

The following topics are covered in this chapter:

  • JUnit 4 annotations
  • Assertion methods and assertThat
  • The @RunWith annotation
  • Exception handling in JUnit
  • JUnit test suite
  • Overview of Mockito and Mockito APIs
  • Advanced Mockito examples

Learning unit testing

A test is a measurement of performance of something, or an examination of data; for example, a class test is an assessment of our understanding, to determine whether we can go to the next level or not. We deliver software to our customers, so a test in the software context is the validation of a requirement before the software is delivered to a customer. For example, we need to check whether a valid user can log in to a system, or 1,000 concurrent users can access the system.

A unit test is a fundamental test to quickly assess whether the result of a computation can possibly go wrong or not. It is a straightforward check to verify the basis of the computation result.

Generally, Java code is unit tested using print statements or by debugging the application. Neither of these approaches is correct, and combining production code with testing logic is not good practice. Though it doesn't break the production code, it increases code complexity, degrades readability, and creates severe maintenance problems, or the production code may malfunction if anything gets misconfigured. When we add print statements or excessive logging statements in production code for unit testing, they get executed along with the production code and print needless information. In turn, they increase execution time and reduce code readability. Also, excessive logging might bury a genuine issue; for example, we might fail to notice a seriously hung thread message because of excessive logging.

Unit testing is the basis of Test-Driven Development (TDD). In TDD, a failing test is written first, then code is written to satisfy the test, and then the code quality is improved by refactoring the code and applying patterns. So unit tests drive the design. They reduce over engineering, as the code is written only to satisfy a failing test. Automated tests provide a quick regression safety net for refactoring and new features.

Kent Beck invented the Extreme Programming (XP) concept and TDD. He has authored many books and papers.

Generally, we don't mix production code with the test code, so unit tests are kept in the same project, but under a different directory or source folder such that the unit tests for an org.packt.Bar.java Java class should be written in an org.packt.BarTest.java test class. The convention is to end a test class name with Test. Note that the Bar class and BarTest have the same package (org.packt), but they should be organized in the src (/org/foo/Bar.java) and test (/org/foo/BarTest.java) source folders, respectively. Keeping the source code and the unit test code in the same package allows the unit test code to access the source code's protected and default methods and members. This approach is useful while working with the legacy code.

Generally, customers do not need the unit tests as they don't execute them, so during software packaging, the test folder is not bundled with the production code.

Code-driven unit testing frameworks are used to unit test Java code. The following are a few Java unit testing frameworks:

  • SpryTest
  • Jtest
  • JUnit
  • TestNG

The most popular and widely used framework is the JUnit framework. JUnit 4 will be explored in the following section.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.212.124