Explore writing unit tests for Java applications using JUnit, delve into JUnit organization, assertions, quality practices, design relevance, refactoring, and using mock objects for dependencies.

Pragmatic Unit Testing in Java 8 with Junit by The Pragmatic Programmer.png

junit.tar.gz

java

test2

test4 - Our first passing test

test6

test14

test16-branch-persistence

AssertTest-13

test15

test15-profile

test15-ProfilePoolTest

test16-BearingTest

test16-RectangleTest

test16-SparseTest

test16-TransmissionTest

test16-ProfileTest

test20m-ProfileTest

test21-Profile

big1-Profile

big1-MatchSet

big4-MatchSetTest

big4-MatchSet

big6

mock-2-AddressRetrieverTest

mock-4-AddressRetrieverTest

mock-5-AddressRetrieverTest

test1-SearchTest

test3-SearchTest

tdd-1-ProfileTest.java 

tdd-2-ProfileTest.java

tdd-3-ProfileTest.java

tdd-4-Profile.java

tdd-5-ProfileTest.java

tdd-9-ProfileTest.java

tdd-10-ProfileTest.java

tdd-10-AnswerTest.java

tdd-11-ProfileTest.java

tdd-12-ProfileTest.java

tdd-14-ProfileTest.java

tdd-15-ProfileTest.java

thread-2-ProfileMatcherTest

thread-3-ProfileMatcherTest

thread-4-ProfileMatcherTest

test16-branch-persistence-redesign-QCTest

AssertHamcrest-13

test16-branch-persistence-redesign-StatCompilerTest

test16-ProfilePoolTest

test15-ProfilePoolTest-copy 16

test3-SearchTest-ContainsMatches

tdd-11-ProfileTest.java-Supporting Multiple Answers

thread-2-ProfileMatcherTest-Testing Multithreaded Code

test2-Our First passing test

test4 - AAA your way to a test

test2-final-intro-junit

In this course, you will learn how to write a unit test for Java applications using JUnit. You'll start by covering unit-testing foundations, which provide you with a starter set of information about writing basic tests in JUnit. You’ll learn about JUnit organization and assertions, and you’ll pick up a few core quality practices for unit testing such as the Right BICEP and the CORRECT way. 

Towards the end, the bigger design picture focuses on the relevance of design to unit testing and vice versa. You’ll refactor your tests, and you’ll learn how to use mock objects to deal with trouble-some dependencies.

Pragmatic Unit Testing in Java 8 with JUnit

The change to the interface with `Profile` broke a number of tests in `ProfileTest`. We need to invest some effort to fix the tests, which highlights one of the costs of using unit tests in the first place; they need to be maintained regularly. 

# Refactoring
>Refactoring is supposed to be an activity where we change the implementation of the code without changing its behavior. 

Our tests are supposed to be a reflection of the program’s behavior. However, the reality is that we are changing the behavior of our classes in terms of how we expose that behavior through the classes’ interfaces.

We accept the cost of fixing broken tests because their value can be far greater than the effort we put into them.

There is certainly some benefit of being able to make changes without the worry of breaking other codes, especially since the cost of maintaining our tests isn’t always trivial. We truly recognize its expense when we encounter scenarios like the one we are in now, where we’ve broken a number of tests all at once.

As we move forward, think about the magnitude of failing tests as a negative design indicator. The more tests that break simultaneously, the more likely we have a design issue.

# How to protect yourself?
We need to follow a few instructions to protect our code from failing miserably.

## Problem with code duplication 
Duplication of code is one of the most common design problems. From the stance of the tests themselves, duplication across tests creates two problems:
1. It makes the tests harder to follow. If we expend three lines of code to create and populate an Answer object, that is three lines that a reader must step through and understand. Distilling them to a single concept, such as a helper method named `createMatchingAnswer()`, imparts immediate understanding to the reader.

2. Extracting duplicate occurrences of small bits of code to a single method minimizes the impact when those small bits must change. Better to make a change in a single place than in numerous tests scattered across our source base.

## Violation of the SRP
The need for several or even dozens of lines of code to set up unit tests is another indicator that we have problems with the design of our system. Violation of the SRP generally results in larger classes, which usually lead to more dependencies on other classes, which in turn demands more effort to set up our tests. 

>Find a way to _split_ your larger classes!

## Testing private methods
The compulsion to test private methods is another hint that our classes are too large. 

>More often than not, a spate of private methods suggests that the private behavior is better moved to a new class where it can become public behavior.

If unit testing seems hard, take the hint. Find ways to make unit testing easier by improving your design. This will decrease (but never eliminate) the cost of maintaining tests.

> Unit test maintenance costs increase as our system’s design/code quality decreases. 

# Fixing our broken tests 
The current tests in `ProfileTest` are mostly focused on managing what is now `MatchSet` objects. Extract these tests to the new `MatchSetTest` test class and make the changes necessary to get the test code compiled and passing. Specifically, we must pass a hash of question-text-to-Answer-object to create a `MatchSet` object. Add a utility method to simplify creating `MatchSet` objects and another to simplify adding `Answer` objects to a `MatchSet`. 

Here’s what a couple of the tests look like in their new home:

Learn the cost of maintaining Unit tests.

Test Maintenance Cost

Before We Begin

JUnit Test Foundations

Digging Deeper into JUnit Assertions

Organizing Your Tests

Mastering Manic Mnemonics!

What to Test: The Right-BICEP

Boundary Conditions: The CORRECT Way

The Bigger Design Picture

Bigger Design Issues

Using Mock Objects

Refactoring Tests

The Bigger Unit-Testing Picture

Testing Some Tough Stuff

Testing on a Project

Wrapping Up

Appendix - Setting up JUnit

Test Maintenance Cost

Refactoring