Lab Coding Exercise: Unit Testing

In this part of the lab, work together in your Cell Society teams to practice writing tests. As you program larger, more complex, projects it is vitally important that you have confidence the most basic aspects of your code works correctly by automatically testing it — meaning the tests can be run as often as needed to test the entire program, not just the most recent code. JUnit, the most common automated framework for Java, focuses on testing individual methods and has inspired similar frameworks in every other modern language.

Resources

• Using JUnit within IntelliJ
• Available JUnit assert statements

Specifications

As a team, brainstorm tests for the NanoBroswerModel class in the example_browser project using the ZOMBIES acronym to help remind you to consider these questions when coming up with useful test scenarios:

1. What would be the most simple data you could make to test the program does something reasonable?
2. What "special cases" does the program check for (or not)?
3. What "categories" does program behavior naturally fall into? What data shows the boundaries of those categories?
4. What "bad" data values you can think of and what checks would you add to the code to make it more robust from failure or a nonsensical answer?

Resist the urge to simply create a lot of "random" tests (i.e., the shotgun approach) and focus on making each test as useful as possible (i.e., the sniper approach).

Individually, fork the example_browser repository and write the tests you came up with as a team. Each test should be:

• annotated with @Test
• written in separate methods, that follow these naming standards to show what you are intending to test
• commented as needed to show how the chosen input values relate to the test's goal
• simple enough that you know the expected output values for each test before you run the code

If a test uncovers a bug (i.e., you verify the test should be correct, but it fails by showing red):

1. Comment out the buggy code
2. Write a comment telling the cause of the error
3. Write the correct code that fixes the error
4. Run all the tests to verify they all continue to pass (i.e., that your fix did not cause any new bugs)

When you are done, check which lines of code are not executed by your tests, and brainstorm new tests for those lines.

Submitting your Work

At the end of lab, use Gitlab's Merge Request from your forked repository's main branch back to the original organization repository's main branch to submit your team's tested code.

You only need to create one Merge Request, no matter how many commits you make, and you do not worry about potential conflicts since your request will not be approved (it is just an easy way for us to see changes you made).

Make sure the Title of your Merge Request is of the form "lab_unittest - everyone's NetIDs".