What you are to do: {Watch the video for a screen cast walk through of these instructions:}
Access your own GitHub Account: Clone my Starter code repository:
Add methods for subtract, multiply, divide and create and run test cases for them.
Note: for Final Exam: You will get a question about state tables. State tables are used in connection with JUNIT testing. See PPTX workbook for more details on this.
About State Tables:
•We need to write our methods to easily comply with the testing requirements that we specified in our state table.
•Methods must have well-defined input expectations and create returns that are clear and unambiguous.
•If we do not have this in place there is no possible way we can write code test to test our methods.
Create a Word Document: named as studentName_StudentID.docx
Into that document: Put the URL of your GitHUB REPO and a screen shot showing your Bar Green and your Code Clean:
The concept of "Keep the Bar GREEN to Keep the Code Clean" is a mantra often repeated in Test-Driven Development (TDD) circles, and it's deeply associated with JUnit given its prominent visual feedback mechanism. Let's break down the essence of this phrase.
1. Keep the Bar GREEN
In JUnit, after you run your tests, you're presented with a visual bar. This bar turns green if all tests pass successfully and red if any test fails.
The idea of keeping the bar green is an emphasis on always ensuring that, after making any changes or additions to the codebase, all existing tests still pass without any failures. This is pivotal in:
Immediate Feedback: The green bar offers instant confirmation that the system is functioning as expected.
Confidence: A green bar indicates that recent changes haven't inadvertently introduced any regressions or broken existing functionality.
2. Keep the Code Clean
"Clean code" is a code that is:
Readable: Other developers can understand and modify it.
Maintainable: It's structured so future changes can be made with minimal risk.
Robust: It behaves reliably under a range of conditions.
Efficient: It doesn't waste computational resources.
By ensuring that the bar remains green, developers are encouraged to:
Refactor Regularly: After adding a feature and getting the bar to turn green, developers are encouraged to refactor the code to make it cleaner, with the confidence that they haven't broken anything (as validated by the green bar).
Avoid "Code Rot": As the codebase grows and evolves, without tests, there's a tendency for the code to degrade or become "rotten." Regular testing discourages this, as developers can make sure that changes don't introduce new bugs.
Connecting Both Concepts:
In a TDD approach, the cycle is often described as "Red-Green-Refactor."
Red: Write a failing test first (seeing a red bar).
Green: Write just enough code to make the test pass (turning the bar green).
Refactor: Clean up the code while ensuring the bar stays green.
The concept of "Keep the Bar GREEN to Keep the Code Clean" emphasizes the importance of continuous testing as a way to maintain code quality. By having a suite of tests that always pass (green bar), developers can confidently refactor, optimize, and expand the codebase, ensuring that the code remains clean, efficient, and free from regressions.
Step 1: Introduction to JUnit
JUnit is a unit testing framework designed for the Java programming language. Its primary purpose is to ensure that individual units of source code (like methods) function as intended.
Step 2: Setting Up Eclipse
Before you begin, you'll need to have Eclipse IDE installed. If you haven't done this, download and install the Eclipse IDE for Java Developers from the official Eclipse website.
Step 3: Create a New Java Project
Open Eclipse.
Go to File > New > Java Project.
Name the project "JUnitPractice" and click "Finish."
Step 4: Downloading JUnit JAR
Navigate to the JUnit's official GitHub page or Maven Central Repository to download the latest version of the junit.jar file.
Save the .jar file to a known location on your computer.
Step 5: Adding the JUnit jar file to your Project’s Class Path
In Eclipse, right-click on the "JUnitPractice" project in the Project Explorer.
Go to Build Path > Configure Build Path.
Under the "Libraries" tab, click Add External JARs.
Navigate to where you saved junit.jar and select it. Click "Open" and then "Apply and Close."
Step 6: Setting Up Test Directory
In the Project Explorer, right-click on the "JUnitPractice" project.
Go to New > Source Folder.
Name it "test" and click "Finish."
Exercise 1: Testing Addition of Numbers
1. Inside your "test" directory, right-click and create a new class named AdditionTest.
2. In the opened editor, type out the following:
importorg.junit.Test;
importstaticorg.junit.Assert.assertEquals;
publicclassAdditionTest{
@Test
publicvoidtestAddition(){
int result =add(5,3);
assertEquals(8, result);
}
publicintadd(int a,int b){
return a + b;
}
}
3. To run the test, right-click on the file in the editor or Project Explorer and select "Run As > JUnit Test."
4. Eclipse will show a green bar in the JUnit view if the test passes. If there's an error in the add method or the test fails for any reason, you'll see a red bar.
Exercise 2: Parsing Substrings (optional)
1. In the "test" directory, right-click and create a new class named SubstringTest.
2. In the opened editor, input:
javaCopy code
import org.junit.Test;
import static org.junit.Assert.assertEquals;
public class SubstringTest {
@Test
public void testSubstring() {
String result = getSubstring("HelloWorld", 0, 5);
assertEquals("Hello", result);
}
public String getSubstring(String input, int start, int end) {
return input.substring(start, end);
}
}
3. Run the test similarly by right-clicking and choosing "Run As > JUnit Test."
Exercise 3: Marshalling Objects in and out of ArrayList (optional)
Using ArrayLists is fundamental in Java, as they provide resizable arrays. Here, students will learn to marshal (add) and unmarshal (remove) objects from an ArrayList and validate using JUnit.
1. In your "test" directory, right-click and create a new class named ArrayListTest.
2. In the opened editor, type out the following:
javaCopy code
import org.junit.Test;
import java.util.ArrayList;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
public class ArrayListTest {
@Test
public void testMarshalling() {
ArrayList<String> list = new ArrayList<>();
marshal(list, "Java");
assertEquals(1, list.size());
assertEquals("Java", list.get(0));
}
@Test
public void testUnmarshalling() {
ArrayList<String> list = new ArrayList<>();
list.add("JUnit");
unmarshal(list, "JUnit");
assertTrue(list.isEmpty());
}
public void marshal(ArrayList<String> list, String item) {
list.add(item);
}
public void unmarshal(ArrayList<String> list, String item) {
list.remove(item);
}
}
3. To run the tests, right-click on the file in the editor or in the Project Explorer and select "Run As > JUnit Test."
Eclipse will display results for each test. A green tick indicates a successful test, while a red cross denotes a failed one.
Step 7: Understanding the Results: Keep the Bar GREEN to Keep the Code Clean.
After running the JUnit tests, Eclipse will provide a detailed result in the JUnit panel.
Green Bar: Indicates all tests passed without any failures or errors.
Red Bar: Indicates one or more tests failed.
Note: Failing tests are not necessarily bad at first. They provide valuable feedback about the code's behavior and can guide improvements. In fact, in Test-Driven Development (TDD), it's common to see a test fail first before making it pass by adjusting the actual code.
Step 8: Making Changes and Rerunning Tests
As you modify the source code or enhance the application's functionalities, always re-run the tests to ensure existing features remain intact.
Adjust the source methods or add new ones.
Adjust the test methods as necessary or add new test cases.
Right-click on the test class and select "Run As > JUnit Test" again to validate changes.
This concludes the second epoch of our JUnit methodology setup and application using Eclipse. The students have now gained a foundational understanding of adding simple tests, interpreting results, and the value of iterative testing in development. When you're ready, let me know if you'd like more advanced exercises or any other assistance.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (