Assignment #2: Tech Jobs (Object-Oriented Edition)¶

Job Fields¶

Open the Job class file. You’ll see the following fields (among others):

1
2
3
4
5

private String name;
private Employer employer;
private Location location;
private PositionType positionType;
private CoreCompetency coreCompetency;

Of these, only name is a string. Sally created classes to represent each of the other properties. These classes—Employer, Location, CoreCompetency, PositionType—have value and id fields.

So, for example, if you had a Job instance, you could get the name of the employer this way:

// job is an instance of Job
String employerName = job.getEmployer().getValue();

Additionally, the toString() method of the Employer class is set up to return the value field. Thus, using one of these objects in another string context like System.out.println will print the data stored in value.

// Prints the name of the employer
System.out.println(job.getEmployer);

Why do we go to all of this trouble when we could store this job-related data as strings? There are a couple of reasons.

Running the Autograding Tests¶

Before diving into your tasks, review Assignment #0: Hello, World! for details on running the autograding tests for this assignment. This assignment has many more tests than the previous two, so we’ve organized them into separate files.

Each of the one test files, TestTaskXXXX, contains the tests to grade one of the six tasks outlined in below (there’s no coding work for your first task, so there is no TestTaskOne). Run all of the tests by right-clicking on the org.launchcode.techjobs.oo and selecting Run tests...

You should see a large number of failures along with a small number of passing tests. Your job is to get those failures to pass, while not breaking the few tests that already pass.

When you start on one of the tasks below, begin by running only the tests associated with that task. To do so, right-click on the test file and select Run TestTaskXXXX.

As you work on the components of the given tasks, continually re-run the tests to see the failing tests gradually turn to passing. When all tests within the file pass, you’re ready to move onto the next task.

Your tasks¶

The list below provides a general overview of your assigned tasks. Specific details for each part appear in the following sections, so be sure to read them carefully as you solve each problem.

1. Review Sally’s code in the Employer class to learn how to assign a unique ID.
2. Add getters, setters, and custom methods as needed to the Location, CoreCompetency, and PositionType classes.
3. Complete the Job class using what you learned in steps 1 and 2.
4. Use unit testing to verify the constructors and equals methods for the Job class.
5. Use TDD to design and code a custom toString method for the Job class.
6. Use inheritance to DRY the code within Employer, Location, CoreCompetency, and PositionType.

Assign a Unique ID¶

One neat trick we can use is to automatically assign each new object a unique ID number.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

public class Employer {
   private int id;
   private static int nextId = 1;
   private String value;

   public Employer() {
      id = nextId;
      nextId++;
   }

   public Employer(String aValue) {
      this();
      this.value = aValue;
   }

   // Getters and setters omitted from this view.
}

1. Line 3 declares the variable nextId. Since it is static, its changing value is NOT stored within any Employer object.
2. The first constructor (lines 6 - 9) accepts no arguments and assigns the value of nextId to the id field. It then increments nextId. Thus, every new Employer object will get a different ID number.
3. The second constructor (lines 11 - 14) assigns aValue to the value field. However, it ALSO initializes id for the object by calling the first constructor with the this(); statement. Including this(); in any Employer constructor makes initializing id a default behavior.

The Location Class¶

Open the Location.java file. Note that the getters, setters, and custom methods for this class are done, as is the constructor for initializing the id field.

Sally left you a TODO comment with instructions for coding a second constructor:

1. It should call the first constructor to initialize the id field.
2. It must also initialize the value field for a new Location object.

The CoreCompetency Class¶

Open the class file. In this case, the constructors and custom methods are ready. Sally needs you to complete the somewhat tedious task of writing the getters and setters for the id and value fields, but NOT for nextID.

Fortunately, IntelliJ has a tool to help with this:

1. Right-click in the editor pane and select Generate.

2. Select the Getter and Setter option.

3. Select the value option, then click OK.

   PRESTO! Getters and setters appear.

4. Since the unique value of id is set with the constructors, we only need to add a getter for this field. Select Generate again and use the Getter option for id.

The PositionType Class¶

Open the class file. This time the constructors, getters, and setters are done. Sally’s comments direct you to where you need to add the custom methods.

1. Code a toString method that just returns the value of a PositionType object.
2. Use the Generate option again to add the equals and hashCode methods. Refer to the previous section of this chapter if you need a quick review.
3. Assume that two PositionType objects are equal when their id fields match.

Creating a JUnit Run Configuration¶

Since this project contains two sets of tests used for different purposses—the autograding tests and the JUnit tests you are about to write—we have to set up a run configuration to allow us to run them independently. We’ll show you how to do that now.

At the top right of IntelliJ, select Add Configuration, just left of the green Run button.

If this item doesn’t have the label Add Configuration, then open the associated dropdown and select Edit Configurations.

In the modal that opens, click on the + icon at the top left, and select JUnit.

Fill out the resulting form using the values:

1. Name: JobTest
2. Java version: Java 11
3. Module: techjobs-oo.main
4. Class: org.launchcode.techjobs.oo.test.JobTest (Click on the icon at the right side of this field and select the JobTest class from the modal that opens.)

Then hit Apply and OK.

To run the tests, select the JobTest configuration from the configurations menu and hit the green Run button.

Now you’re ready to start writing some tests!

Test the Empty Constructor¶

Each Job object should have a unique ID that is an integer.

1. In JobTest, define a test called testSettingJobId. Do not forget to annotate it with @Test.

2. Create two Job objects using the empty constructor.

3. Use assertNotEquals to verify that the IDs of the two objects are distinct.

4. Run the test using the run configuration that you created above.

5. If the test doesn’t pass, what should be your first thought?

   1. “Drat! I need to fix the unit test.”
   2. “Drat! I need to fix my Job() constructor code.”

   Warning

   The answer is NOT “a”.

   Your test code might be incorrect, but that should not be your FIRST thought. TDD begins with writing tests for desired behaviors. If the tests fail, that indicates errors in the methods trying to produce the behavior rather than in the tests that define that behavior.

Test the Full Constructor¶

Each Job object should contain six fields—id, name, employer, location, positionType, and coreCompetency. The data types for these fields are int, String, Employer, Location, PositionType, and CoreCompetency, respectively.

1. In JobTest, define a test called testJobConstructorSetsAllFields.

2. Declare and initialize a new Job object with the following data:

   new Job("Product tester", new Employer("ACME"), new Location("Desert"), new PositionType("Quality control"), new CoreCompetency("Persistence"));
   

3. Use assertTrue and assertEquals statements to test that the constructor correctly assigns both the class and value of each field. Your test should have 5 assert statements of each type.

   Tip

   The instanceof keyword can be used to check the class of an object. The result of the comparison is a boolean.

   objectName instanceof ClassName
   

Test the equals Method¶

Two Job objects are considered equal if they have the same id value, even if one or more of the other fields differ. Similarly, the two objects are NOT equal if their id values differ, even if all the other fields are identical.

1. In JobTest, define a test called testJobsForEquality.
2. Generate two Job objects that have identical field values EXCEPT for id. Test that equals returns false.

It might seem logical to follow up the false case by testing to make sure that equals returns true when two objects have the same ID. However, the positive test is irrelevant in this case.

The way you built your Job class, each id field gets assigned a unique value, and the class does not contain a setId method. You also verified that each new object gets a different ID when you tested the constructors. Without modifying the constructors or adding a setter, there is no scenario in which two different jobs will have the same ID number. Thus, we can skip the test for this condition.

Create First Test for toString¶

Before writing your first test, consider how we want the method to behave:

1. When passed a Job object, it should return a string that contains a blank line before and after the job information.

2. The string should contain a label for each field, followed by the data stored in that field. Each field should be on its own line.

   ID:  _______
   Name: _______
   Employer: _______
   Location: _______
   Position Type: _______
   Core Competency: _______
   

3. If a field is empty, the method should add, “Data not available” after the label.

4. (Bonus) If a Job object ONLY contains data for the id field, the method should return, “OOPS! This job does not seem to exist.”

In JobTest, add a new test named testToStringStartsAndEndsWithNewLine to check the first requirement. Be sure to use assertEquals to verify that these characters are correct, and to use the exact formatting demonstrated above.

Woo hoo! Failure is what we want here! Now you get to fix that.

Code toString to Pass the First Test¶

In the Job class, create a toString method that passes the first test. Since the test only checks if the returned string starts and ends with a blank line, make that happen.

Finish the TDD for toString¶

1. Code a new test for the second required behavior, named testToStringContainsCorrectLabelsAndData. Then run the tests to make sure the new one fails.
2. Modify toString to make the new test pass. Also, make sure that your updates still pass all of the old tests.
3. Follow the same TDD process for the third requirement, creating a test named testToStringHandlesEmptyField.

Cool! Your Job class is now complete and operates as desired.

Create a Base Class¶

Let’s move all of the repeated code into a separate class. We will then have Employer, Location, CoreCompetency, and PositionType inherit this common code.

1. Create a new class called JobField in the package org.launchcode.techjobs.oo.
2. Consider the following questions to help you decide what code to put in the JobField class:
   1. What fields do ALL FOUR of the classes have in common?
   2. Which constructors are the same in ALL FOUR classes?
   3. What getters and setters do ALL of the classes share?
   4. Which custom methods are identical in ALL of the classes?
3. In JobField, declare each of the common fields.
4. Code the constructors.
5. Use Generate to create the appropriate getters and setters.
6. Add in the custom methods.
7. Finally, to prevent the creation of a JobField object, make this class abstract.

Extend JobField into Employer¶

Now that you have the common code located in the JobField file, we can modify the other classes to reference this shared code. Let’s begin with Employer.

1. Modify line 5 to extend the JobField class into Employer.

   5 6 7 8 9

   public class Employer extends JobField { //Code not displayed. }

2. Next, remove any code in Employer that matches code from JobField (e.g. the id, value, and nextId fields are shared).

3. Remove any of the getters and setters that are the same.

4. Remove any of the custom methods that are identical.

5. The empty constructor is shared, but not the second. Replace the two constructors with the following:

   7 8 9

   public Employer(String value) { super(value); }

   The extends and super keywords link the JobField and Employer classes.

6. Rerun your unit tests to verify your refactored code.

Finish DRYing Your Code¶

1. Repeat the process above for the Location, CoreCompetency, and PositionType classes.
2. Rerun your unit tests to verify that your classes and methods still work.