Description

Pragmatic Unit Testing in Java 8 With JUnit steps you through all the important unit testing topics. If you’ve never written a unit test, you’ll see screen shots from Eclipse, IntelliJ IDEA, and NetBeans that will help you get past the hard part—getting set up and started.

Once past the basics, you’ll learn why you want to write unit tests and how to effectively use JUnit. But the meaty part of the book is its collected unit testing wisdom from people who’ve been there, done that on production systems for at least 15 years: veteran author and developer Jeff Langr, building on the wisdom of Pragmatic Programmers Andy Hunt and Dave Thomas. You’ll learn:

• How to craft your unit tests to minimize your effort in maintaining them.
• How to use unit tests to help keep your system clean.
• How to test the tough stuff.
• Memorable mnemonics to help you remember what’s important when writing unit tests.
• How to help your team reap and sustain the benefits of unit testing.

You won’t just learn about unit testing in theory—you’ll work through numerous code examples. When it comes to programming, hands-on is the only way to learn!

Contents and Extracts

Preface

• Unit Testing Foundations
  • Building Your First JUnit Test excerpt
    • Reasons to Write a Unit Test
    • Learning JUnit Basics: Your First Passing Test
    • Arrange, Act, and Assert Your Way to a Test
    • Is the Test Really Testing Anything?
    • After
  • Getting Real with JUnit
    • Understanding What We’re Testing: The Profile Class
    • Determining What Tests We Can Write
    • Covering One Path
    • Tackling a Second Test
    • Initializing Tests with Before Methods
    • How Ya Feelin’ Now?
    • After
  • Digging Deeper into JUnit Assertions
    • Assertions in JUnit
    • Three Schools for Expecting Exceptions
    • After
  • Organizing Your Tests
    • Keeping Tests Consistent with AAA
    • Testing Behavior Versus Testing Methods
    • Relationship Between Test and Production Code
    • The Value of Focused, Single-Purpose Tests
    • Tests as Documentation
    • More on Before and After (Common Initialization and Cleanup)
    • Green Is Good: Keeping Our Tests Relevant
    • After
• Mastering Manic Mnemonics!
  • FIRST Properties of Good Tests
    • FIRST It Helps to Remember That Good Tests Are FIRST
    • [F]IRST: [F]ast!
    • F[I]RST: [I]solate Your Tests
    • FI®ST: Good Tests Should Be®epeatable
    • FIR[S]T: [S]elf-Validating
    • FIRS[T]: [T]imely
    • After
  • What to Test: The Right-BICEP excerpt
    • [Right]-BICEP: Are the Results Right?
    • Right-[B]ICEP: Boundary Conditions
    • Remembering Boundary Conditions with CORRECT
    • Right-B[I]CEP: Checking Inverse Relationships
    • Right-BICEP: Cross-Checking Using Other Means
    • Right-BIC[E]P: Forcing Error Conditions
    • Right-BICE[P]: Performance Characteristics
    • After
  • Boundary Conditions–The CORRECT Way
    • ©ORRECT: ©onformance
    • C[O]RRECT: [O]rdering
    • CORRECT:®ange
    • COR®ECT:®eference
    • CORR[E]CT: [E]xistence
    • CORRE©T: ©ardinality
    • CORREC[T]: [T]ime
    • After
• The Bigger Design Picture
  • Refactoring to Cleaner Code excerpt
    • A Little Bit o’ Refactor
    • Finding Better Homes for Our Methods
    • Automated and Manual Refactorings
    • Taking Refactoring Too Far?
    • After
  • Bigger Design Issues
    • The Profile Class and the SRP
    • Extracting a New Class
    • Command-Query Separation
    • The Cost of Maintaining Unit Tests
    • Other Design Thoughts
    • After
  • Using Mock Objects
    • A Testing Challenge
    • Replacing Troublesome Behavior with Stubs
    • Changing Our Design to Support Testing
    • Adding Smarts to Our Stub: Verifying Parameters
    • Simplifying Testing Using a Mock Tool
    • One Last Simplification: Introducing an Injection Tool
    • What’s Important to Get Right When Using Mocks
    • After
  • Refactoring Tests
    • Searching for an Understanding
    • Test Smell: Unnecessary Test Code
    • Test Smell: Missing Abstractions
    • Test Smell: Irrelevant Information
    • Test Smell: Bloated Construction
    • Test Smell: Multiple Assertions
    • Test Smell: Irrelevant Details in Test
    • Test Smell: Misleading Organization
    • Test Smell: Implicit Meaning
    • Adding a New Test
    • After
• The Bigger Unit Testing Picture
  • Test-Driven Development
    • The Primary Benefit of TDD
    • Starting Simple
    • Adding Another Increment
    • Cleaning Up Our Tests
    • Another Small Increment
    • Supporting Multiple Answers: A Small Design Detour
    • Expanding the Interface
    • Last Tests
    • Tests As Documentation
    • The Rhythm of TDD
    • After
  • Testing Some Tough Stuff
    • Testing Multithreaded Code
    • Testing Databases
    • After
  • Testing on a Project
    • Coming Up to Speed
    • Get on the Same Page With Your Team
    • Convergence With Continuous Integration
    • Code Coverage
    • After
  • Setting UP JUnit in IntelliJ IDEA and NetBeans
    • IntelliJ IDEA
    • NetBeans