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

Our new code represents a small change to the design of the system. Before, the `Http` instance was created by the `retrieve()` method as a private detail of the `AddressRetriever` class. Now, any client that interacts with `AddressRetriever` is responsible for creating and passing in an appropriate `Http` instance. Perhaps something like: 

```
AddressRetriever retriever = new AddressRetriever(new HttpImpl());
```

No, because it’s most important to demonstrate, in a simple fashion, that the system behaves the way you expect. Also, you have a better **design**: the dependency on `Http` is now declared in the clearest way possible, and moving the dependency to the interface loosens the coupling a bit.


No, because it’s most important to demonstrate, in a simple fashion, that the system behaves the way you expect. Also, you have a better design: the dependency on <code>Http</code> is now declared in the clearest way possible, and moving the dependency to the interface loosens the coupling a bit.

Is changing your system’s design just to write a test a bad thing?

Is changing your system’s design just to write a test a bad thing?

## Ways to inject `stubs`
We’re not limited to constructor injection. There are many other ways to inject stubs:
* Some require no changes to the interface of our class. 
* We can use setters instead of constructors.
* We can override factory methods. 
* We can introduce abstract factories.
* We can even use tools such as Google Guice or Spring that do the injection for us. 

## Adding smarts to our `Stub`: verifying parameters 
Our `Http` stub always returns the same hardcoded JSON string, regardless of the latitude and longitude passed to its `get()` method. That’s a small hole in testing. If the `AddressRetriever` doesn’t pass the parameters correctly, we have a defect. 

> ### A Conversation
>
>“How hard can it be to pass a couple of arguments correctly to a function?” asks Pat. “Do we really need to test that?” 
>
>Dale responds, “You’re forgetting when we shipped code the other week where someone inadvertently swapped the order of the latitude and longitude in another part of the system. We wasted a couple of hours on that defect.”
 

Another way to think about what we’re doing is that we’re not exercising the real behavior of `HttpImpl`, but we know that other tests exist for it. We’re exercising the rest of the code in `retrieve()` based on a return value that `HttpImpl` might cough up. The only thing left to cover is to verify that the code in `retrieve()` correctly interacts with the `HttpImpl` code.

>Add a guard class to the stub that verifies the `URL` passed to the `Http` method `get()`. If it doesn’t contain the expected parameter string, explicitly fail the test at that point:

# Ways to inject `stubs`
We’re not limited to constructor injection. There are many other ways to inject stubs:
* Some require no changes to the interface of our class. 
* We can use setters instead of constructors.
* We can override factory methods. 
* We can introduce abstract factories.
* We can even use tools such as Google Guice or Spring that do the injection for us. 

# Adding smarts to our `Stub`: verifying parameters 
Our `Http` stub always returns the same hardcoded JSON string, regardless of the latitude and longitude passed to its `get()` method. That’s a small hole in testing. If the `AddressRetriever` doesn’t pass the parameters correctly, we have a defect. 

> ### A Conversation
>
>“How hard can it be to pass a couple of arguments correctly to a function?” asks Pat. “Do we really need to test that?” 
>
>Dale responds, “You’re forgetting when we shipped code the other week where someone inadvertently swapped the order of the latitude and longitude in another part of the system. We wasted a couple of hours on that defect.”
 

Another way to think about what we’re doing is that we’re not exercising the real behavior of `HttpImpl`, but we know that other tests exist for it. We’re exercising the rest of the code in `retrieve()` based on a return value that `HttpImpl` might cough up. The only thing left to cover is to verify that the code in `retrieve()` correctly interacts with the `HttpImpl` code.

>Add a guard class to the stub that verifies the `URL` passed to the `Http` method `get()`. If it doesn’t contain the expected parameter string, explicitly fail the test at that point:

Learn how we can change the system's design to support JUnit testing.

Changing Our Design to Support Testing

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

Changing Our Design to Support Testing

Ways to inject `stubs`

Changing Our Design to Support Testing

Ways to inject stubs

Ways to inject `stubs`