JUnit Testing: Lesson

A typical `@Test` method involves **assertions**.

Assertions are found in the `junit.org.Assert` class library. Each "assert" is a way to perform a specific test in JUnit testing.

Below are a couple of common assert methods (note: they all have a return type of `void`):

| Assert Method | Description |
| --- | --- |
| `assertEquals(expected, actual)` | Checks if two values are equal |
| `assertNotEquals(expected, actual)` | Checks if two values are not equal |
| `assertTrue(boolean condition)` | Checks if a condition is `true` |
| `assertFalse(boolean condition)` | Checks if a condition is `false` |
| `assertNotNull(Object object)` | Checks if an object isn’t `null` |
| `assertNull(Object object)` | Checks if an object is `null` |
| `assertArrayEquals(expectedArray, actualArray)` | Checks if two arrays are equal |

When called, each "assert" is considered as a test case by the compiler, and any given assert can either pass or fail. A `@Test` method can only pass if all test cases inside of it pass. If any case fails, the whole test method will be marked red and considered a failed test.

Let’s walk through an example to best display how these asserts can be used.

Suppose we have a class object called `Human`. We assign that object a `name`, represented by a string, and an integer value to represent their `hitpoints` upon creation.

```java
Human sam = new Human("Sam", 100);
```

We want to test whether or not Sam gets properly created and also test a `takeDamage()` method within the `Human` class to ensure any damage taken is being recorded. Because this implies two different tests, let’s create two different test methods:

```java
@Test
public void testHuman() {
  Human sam = new Human("Sam", 100);
  assertEquals(100, sam.getHitpoints());
  assertEquals("Sam", sam.getName());
}

@Test
public void testHumanTakeDamage() {
  Human sam = new Human("Sam", 100);
  assertEquals(100, sam.getHitpoints());
  sam.takeDamage(10);
  assertEquals(90, sam.getHitpoints());
}
```

Take note that `assertEquals()` is overloaded to account for different variable types.

Each assert method is a tool a programmer can use to uniquely test their code. They typically follow the pattern of "expected value first," then find the "actual" value in the second parameter to check against the expected.

There are a few exceptions to this rule. When checking a boolean or an object’s existence, one parameter is used. When checking a decimal value, a third parameter (range) can be included to indicate that a value plus or minus this range is considered passable. For example:

```java
assertEquals(25.5, sam.calculateDamage(), 0.9);
```

This will pass if `sam.calculateDamage()` returns a value anywhere within the range of `24.6` and `26.4`.

@Test Methods and Asserts

a snippet of code switching between red and green

`@Test` will be the bulk of any JUnit testing. Anything that needs to be "checked" and "verified" will likely occur within a method marked with the `@Test` annotation.

A test method looks like this:
```java
@Test
public void test() {
  // Test cases
}
```

The way this method functions is atypical of methods found in traditional Java classes. These `@Test` annotated methods will _always_ run unless otherwise annotated as `@Ignore`, which tells the compiler to skip over that particular method. These test methods also don’t have to be called, as they’re automatically detected and run by the compiler.

Typically, there will be a test method for every class object and class method in the program. For instance, if a method exists called `takeDamage()`, there will often also be a `testTakeDamage()` test method verifying the functionality of that method.

The word **coverage** may arise at some point during a programmer’s testing journey, which in the case of JUnit just means "test coverage." In other words, it asks the question "how much of the code is actually tested?" Or in other _other_ words, "do the test methods touch all of the code?" A good program will have full coverage.

Most Java IDEs will make it easy to detect coverage, often supporting ways to visibly see all the code touched by testing and all the code missed. Eclipse, an example of a Java IDE, does this by tinting the code green or red depending on whether or not a test case hits that area of the program.

The test cases themselves, regardless of the coverage algorithm, will actually follow a similar color pallet when run. JUnit makes it a standard to use the colors **green** and **red** to indicate whether or not a test method passes or fails. A test will go green if it passes, and red otherwise.

Programmers have created a mantra around this JUnit standard: "Red — Green — Refactor!"

Let’s talk about why that mantra is indicative of good test practices and how it’s understood by programmers working with JUnit testing.

@Test-ing, @Test-ing, 1 2 3

Congratulations! You completed the lesson on JUnit testing! 🙌

Key concepts covered in this lesson:
- JUnit testing makes sure we have good test coverage across a program’s code and verifies everything is working as expected.
- How to write `@Test` methods and their incorporations of the `Assert` class library.
- How to write `@Before` methods and why they’re useful.
- How to write `@After` methods and why they’re useful.
- What test suites are and what they’re used for.
- “Red — Green — Refactor!”

Review

"Red — Green — Refactor!"

By the end of this lesson, this mantra should be playing in your mind whenever you think about testing your code.

This mantra emphasizes the "test-first" approach to programming. In the simplest sense, this just means that a program’s tests are written before the code is made.

But how does that work? How can a test be written to test code that doesn’t exist yet?

The answer lies in the mantra.

"Red" is the start of the mantra and the first thing a programmer needs to do in test-first development. In other words, a programmer needs to write a test and make it go red as the first step for testing.

The act of doing this establishes a test to exist first, which is good practice for coverage but also lays the requirements for the code. A skeleton of the method they want to be testing is then created, which often will be set to return `0` (or some other arbitrary value) to ensure the test has something to compare against. This arbitrary value will be different from what the test is "expecting" and make the test go red.

"Green" is the second step of the mantra. Now that we have our red test, we can write code into the skeleton method to make it work. We then run the test again and watch the test method go green.

These two steps help ensure the following things: we have good test coverage, our tests are testing what they should be testing, and the code works as expected.

The last step of the mantra is "Refactor," which is often the last "clean-up" step of any coding. This step cleans up and polishes the code now that its bare minimum processing is tested and functional.

Now, let’s explore what makes these `@Test` methods tick and why this `junit.org.Assert` class library is so important.

@Test-ing, @Test-ing, 1 2 3 Continued

Getting the `@Before`, `@Test`, and `@After` methods all put together and tied up in a neat test class is the basis for JUnit testing. However, there’s one more step a programmer can take to apply one last layer of organization.

Test suites.

A **test suite** is a way to bundle JUnit test classes and run them together. The `@RunWith` and `@Suite` annotations are used to accomplish this, and they look like the following:

```java
@RunWith(Suite.class)
@Suite.SuiteClasses({
  // List of test classes to bundle together
})

public class MyTestSuite {
}
```

The above `MyTestSuite` class doesn’t need anything within the class itself to run. It instead will be called via some sort of "runner" class in the following way:

```java
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
import org.junit.runner.notification.Failure;

public class TestSuiteRunner {
  public static void main(String [] args) {
    Result result = JUnitCore.runClasses(MyTestSuite.class);

    for (Failure failure : result.getFailures()) {
      System.out.println(failure.toString());
    }

    System.out.println(result.wasSuccessful());
  }
}
```

The runner will typically always look the same and can be used to run multiple different test suites depending on which test classes a programmer wants to bundle together. The `Result` and `Failure` imports are ways to gather and print the results of all the test cases run within the bundled test classes.

However, this feels like an overcomplicated way to run all of your tests, right? Ordinarily, test suites aren’t conducive to JUnit testing and aren’t always used or needed. However, there are valid reasons for a test suite to be used.

Consider the following scenario: A programmer builds an environment and fills it with objects for testing. Tests have to be done to make sure those objects made it into the environment without problems, and then more tests are done to manipulate those objects within the environment to make sure they can interact with each other. A final test empties the environment and makes sure everything gets cleaned up.

Without a test suite, multiple test classes that interact with this environment would need to recreate both the environment and the objects within that environment between test classes. This could get time-consuming with enough test classes and a large enough environment for testing.

With a test suite, one environment can be created and all of the test classes can interact with it accordingly. The last test class bundled into the suite can then handle the cleanup.

In retrospect, a test suite is really just another way to apply the `@Before` and `@After` methodology to testing, but on a larger class-based scale. It’s not always useful, but when it is, it’s _really_ useful.

Running With the @Suite-s

The `@Before` annotation can be used to accompany the `@Test` methods. Methods tagged with `@Before` will run before each test method and look like the following:

```java
@Before
public void beforeEachTest() {
  // Something multiple tests use
}
```

They’re typically used if multiple test methods share a similarly created object or set of variables. Placing those inside the `@Before` annotated method ensures those objects are always freshly created and have the same starting attributes upon instantiation. This allows each test to work with those objects and variables without needing to create them inside their test bodies.

If we look at the example we covered in the previous exercise, we created the `Human` named "Sam" twice in the exact same fashion. Now that we know about the `@Before` annotation, we could instead place the creation of `sam` inside of the `@Before` method:

```java
Human sam;

@Before
public void createSam() {
  sam = new Human("Sam", 100);
}

@Test
public void testHuman() {
  assertEquals(100, sam.getHitpoints());
  assertEquals("Sam", sam.getName());
}

@Test
public void testHumanTakeDamage() {
  assertEquals(100, sam.getHitpoints());
  sam.takeDamage(10);
  assertEquals(90, sam.getHitpoints());
}
```

This is different from just making `sam` a class variable, which is also visible by all tests because the `@Before` will be re-run _before_ each test. This means if tests modify the `sam` variable in any way, it ensures `sam` gets reset before the next test runs.

There’s another variant of the `@Before` annotation that will let us create a method that will run one time before _all_ tests instead of multiple times before _each_ test. This is done by using the `@BeforeClass` annotation.

`@Before` and `@BeforeClass` both have their unique uses, making them valuable tools for JUnit testing.

@Before We Go Further

_JUnit_ testing operates in a Test Driven Development setting, or _TDD_, usually utilized specifically in "test-first" programming. Java programming as a whole is often synonymous with TDD due to the incorporation of JUnit.

As you learn more about what JUnit is and how it works, you’ll pick up a particular mantra along the way:

**"Red — Green — Refactor!"**

This is the leading chant for test-first practices, and you’ll be chanting it too before this lesson is over! While you think about what that might mean, let’s talk about JUnit.

JUnit is a [unit testing](https://www.codecademy.com/resources/docs/general/unit-testing?page_ref=catalog) framework for Java that tests the functionality of an application to ensure it runs as expected. The "units" being tested are single entities, like [classes](https://www.codecademy.com/resources/docs/java/classes?page_ref=catalog) and [methods](https://www.codecademy.com/resources/docs/java/methods?page_ref=catalog).

Programmers write JUnit tests for quality reasons, but they also do so to reduce stress and the time spent debugging code. Proper testing practices can not only keep code organized and maintain a solid direction, but it also ensures maintainability in the future and is friendly to a team-based setting.

These "tests" might be hard to wrap your head around at first but think of them as additional classes that are created to "build and test" elements of an application’s Java classes.

For instance, say you have a Java class called `Human` with stored values for `health`, `thirst`, and `hunger` upon instantiation. To make sure a `Human` is properly storing their values, a JUnit test might create a `Human` object with those values filled, then check to see if they were properly stored. It can also manipulate those values and check if those changes are reflected.

In this lesson, we will learn about JUnit 4 testing.


Introduction to JUnit

The `@After` annotation acts just like the `@Before` but will run _after_ each test method. Particularly if this cleanup needs to occur after each test.

```java
@After
public void afterEachTest() {
  // Cleanup
}
```

`@After` is used for cleaning up variables and objects, and freeing memory. If a file needs to be closed, an object needs to be removed, or an environment or array needs to be emptied, this is perfect.

If the cleanup needs to happen only once after all of the tests conclude, much like `@BeforeClass`, an `@AfterClass` annotation exists for this purpose. This will ensure the method runs after all tests within the class have already run.

The @After-math

JUnit testing takes place in a traditional Java [class](https://www.codecademy.com/resources/docs/java/classes?page_ref=catalog), just like the classes written for the application you want to test. The functionality for those tests comes from JUnit classes, most commonly the `Assert` class and annotation classes.

“Annotating” is a general term that refers to ways of marking methods for testing, changing how these methods are compiled, and establishing when they’ll be run by the compiler. The four most essential annotations are `@Before`, `@Test`, `@After`, and `@Ignore`.

The above annotations can be imported in the following ways:

```java
import org.junit.Before;
import org.junit.Test;
import org.junit.After;
import org.junit.Ignore;
```

Additionally, the following line will grab all functionality from the Assert class library, but note that each assert method can be imported individually:

```java
import static org.junit.Assert.*;
```

Let’s cover what all these annotations and classes mean and how they’re used for JUnit testing!
