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

Job Members¶

Open the Job class file. You’ll see the following properties (among other class members):

1
2
3
4
5

public string Name { get; set; }
public Employer EmployerName { get; set; }
public Location EmployerLocation { get; set; }
public PositionType JobType { get; set; }
public CoreCompetency JobCoreCompetency { get; set; }

Of these, only Name is a string. Sally created classes to represent each of the other properties. These classes—Employer, Location, CoreCompetency, PositionType—have members to hold values and IDs.

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.EmployerName.Value;

Additionally, the ToString() method of the Employer class is set up to return whatever the value field holds. Thus, using one of these objects in another string context like Console.WriteLine will print the data stored in value.

// Prints the name of the employer
Console.WriteLine(job.EmployerName);

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.

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
18

public class Employer {
   public int Id { get; }
   private static int nextId = 1;
   public string Value { get; set; }

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

   public Employer (string value) : this()
   {
      Value = value;
   }

   // Additional methods omitted from this code block
}

1. Line 3 declares the field nextId. Since it is static, its changing value is NOT stored within any Employer object.
2. The first constructor (lines 6 - 10) 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 12 - 15) assigns the value field. It ALSO initializes id for the object by calling the first constructor statement with the : this() syntax. Including : this() in any Employer constructor makes initializing id a default behavior.

The Location Class¶

Open the Location.cs file. Note that the methods for this class are done, as is the constructor for initializing the Id property.

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 change the id and value fields to auto-implemented properties, but NOT nextId.

The PositionType Class¶

Open the class file. This time the constructors 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 GetHashCode() methods. Refer to the final section of the “Classes and Objects, Part 2” chapter if you need a quick review.
3. Assume that two PositionType objects are equal when their id fields match.

Test the Empty Constructor¶

Each Job object should contain a unique ID number, and these should also be sequential integers.

1. In JobTests, define a test called TestSettingJobId.

2. Create two Job objects using the empty constructor. Use Assert.AreEqual, Assert.IsTrue, or Assert.IsFalse to test that the ID values for the two objects are NOT the same and differ by 1.

3. Run the test to verify that your Job() constructor correctly assigns ID numbers.

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

   1. “I need to fix the unit test.”
   2. “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 properties—Id, Name, EmployerName, EmployerLocation, JobType, and JobCoreCompetency.

1. In JobTest, define a test called TestJobConstructorSetsAllFields.
2. Declare and initialize a new Job object with the following data: "Product tester" for Name, "ACME" for EmployerName, "Desert" for JobLocation, "Quality control" for JobType, and "Persistence" for JobCoreCompetency.
3. Use Assert statements to test that the constructor correctly assigns the value of each field.

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 setter for the id field. 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 JobTests, add a new test to check the first requirement (item 1 in the above list), then run that test (it should fail).

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, 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. Continue this test-refactor cycle until all of the behaviors we want for ToString() work. Remember to add only ONE new test at a time.

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.
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. Which custom methods are identical in ALL of the classes?
3. In JobField, declare each of the common class members.
4. Code the constructors.
5. Add in any inherited method overrides.
6. 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.

2. Next, remove any code in Employer that matches code from JobField (e.g. the Id and Value properties and the nextId field are shared).

3. Remove any of the methods that are identical.

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

   7 8 9

   public Employer(string value) : base(value) { }

5. 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.