EXERCISE #3 TEST CASES

Developing Test Cases and Using Version Control

By Sandino Vargas-Pérez

In this exercise, your group will collaboratively implement an InputValidator class in Java that validates various types of user input related to the Art Catalog System (e.g., user registration fields, artwork submission fields).

Exercise Description:

Using a Test-Driven Development (TDD) approach and JUnit, your team will start by writing failing test cases, then write just enough code to make each test pass. Your team will use Git for version control, collaborating through branches, commits, and pull requests (or merges) to integrate your work into the main branch.

Each team will have a starter Git repository with a basic file structure. You will work in a "feature branch" off the main branch, test and code collaboratively, and merge your completed and tested InputValidator class and its corresponding InputValidatorTest class back into main.

Learning Outcomes:

By the end of this exercise, your team should:

• Apply the principles of Test-Driven Development in Java using JUnit.
• Design and implement reusable input validation logic.
• Write and run comprehensive unit tests.
• Understand and practice clean coding and refactoring.
• Use Git for version control: branching, committing, and merging.
• Practice collaborative development in a small team environment.
• Communicate using pull requests or peer review before merging code.
• Coordinate roles (e.g., tester, reviewer, coder) using Agile-inspired teamwork.

---

Stage 0: Preparing the Repository

When you work developing software as a team, you need some form of version control to keep track of changes in your code base. The fictional company developing Nube's Art Catalog system has a repository and you are ready to work developing the features for it. For Stage 0, you will have to create your own repository and collaborate as a team.

To Do:

A team member will create a repository on github.com (select a name for the repo that identifies it as an exercise for this class). Once the repository is created, add the files contained in ce3_startup_files.zip. These are going to be your start up files:

• InputValidatorTest.java: Your team will use this file to write the tests for all the input validation needed.
• InputValidator.java: Your team will create the methods that will validate the content of the inputs from the Art Catalog.
• README.md: An empty markdown file, where your team will write documentation about how to use the tests, and a team reflection.

After the repository is created and the startup files are added, invite the rest of the team members as collaborators. Here is how you can achieve that→.

Members of the teams will accept the invitation to collaborate and clone the repository to their machines.

Outcomes:

This first setup activity will get the team ready to work on Stage 1. Here are some resources that can be helpful for your team:

• Git Cheat Sheet.
• Git: Collaborating Workflow (same page will have more Git tutorials).

---

Stage 1: Requirements and User Story

It has been decided that the client's application will be web-based and your team has decided to work with Java and JSP (JavaServer Pages) which is a server side technology to create dynamic java web applications.

After an exhaustive analysis, the UI team has identified many of the inputs the system will have inside forms and search fields, and came up with a list of fields that needed to be validated:

Your team then checks the backlog of your project and gets assigned the following user story:

Your team will derive the functional requirements (based on the table above) for this user story and get to work.

To Do:

Your team should start writing down the different test cases that can be performed on each of the input fields. For example, the to validate the name field, your team can develop test to validate that a name contains only letters, can contain spaces, is at least 2 characters long, and it is non-empty. These are 4 test cases for this field, you can, of course, develop more.

Outcomes:

This activity will help your team get ready to write tests for the validator class in the next stage (Stage 3). You can also divide and assign tests to each of the members of the team, so that you can avoid conflicts when merging to the repository in GitHub.

---

Stage 2: TDD

The following is the recommended workflow for this exercise to easy-up your entry into TDD:

• After cloning the repository, create a branch named something like feature-[yourname]-validator.
• Modify the class InputValidatorTest.java using JUnit, to create all the tests assigned to you.
• Write failing test cases [RED] for one validator at a time (e.g., isValidEmail). Remember the cycles of TDD: RED → GREEN → REFACTOR
• Commit your test cases regularly.

---

• Write minimal code to make the test pass [GREEN].
• Refactor when needed.
• Keep test coverage high: make sure that most or all of your code is exercised (tested) by automated tests. Ideally, every method, or condition should have (at least) one test that confirms it behaves correctly.
• Push your branch to GitHub and open pull requests. Make sure to communicate with your teammates when you are pushing to the GitHub repository to avoid difficult merging conflicts.
• Review each other's work, suggest improvements, and merge when tests pass.

---

Deliverables

Your team needs to prepare the README.md file with the following

• Names of team members.
• Brief description of what the classes you created are doing.
• A "How To Use" section where your team explain how to use the Validator class and the tester.
• A "Reflection" section where your team talks about the experience. You can use these questions to start:
  • How did writing tests first help (or slow down) your development?
  • Did your team face any conflicts when merging or reviewing code?
  • How would you expand or refactor your validator for future use?

I will clone your repository and check both the InputValidatorTest.java and InputValidator.java for appropriate implementation, code comments, and documentation. I will also check your commit messages, so make sure you write appropriate ones.

Prepare a URL to the repository in GitHub and submit to Kit.

---

Submission to Kit

Once your files are up-to-date in the GitHub repository, One member of the team will submit the repository link to Kit and invite the other team members to "collaborate":

1. The team member copies the URL of the repository and submits to Kit.
2. Once the link is successfully uploaded, the team member clicks the I Worked With Someone Else option and "Invite" the rest of the team members.
3. The rest of the Team member accepts the invitation.

---

Evaluation

Exercise #3 is worth 10 points. The following rubrics describe the criteria I will use to evaluate your team's work:

• Git Workflow and Collaboration [1.5 point]
  • Evidence of team successfully cloning, mergin and working with the repo. 0.5 pts.
  • Clear commit history with meaningful messages. 0.5 pts.
  • Clear instructions and docuementation in the README.md file (which loads when the repository is visited). 0.5 pts.
• Java Coding Style and Documentation [2 point]
  • Class and methods follow Java naming conventions. 0.5 pts.
  • Proper indentation, spacing, structure. 0.5 pts.
  • Includes class-level Javadoc and inline comments where appropriate. 1 pt.
• Unit Test Coverage [4.5 points]
  • Includes test cases for all validation methods (name, email, phone, DOB, postal, password, title, etc). 2 pts.
  • Tests cover valid, invalid, and other edge cases. 1.5 pts.
  • InputValidatorTest.java conatins all the data needed to invoke (and test) all the methods in InputValidator.java. 1 pt.
• Compilation and Execution [1 points]
  • Code compiles and runs without errors. 0.5 pts.
  • Test suite passes successfully with JUnit. 0.5 pts.
• Conclusion and Reflection (README.md Quality) [1 point]
  • Clearly explains how to compile and run the project and tests. Inlcudes all the items asked for in the "Deliverables" section. 1 pt.