Page History

...

PersonName personName = new PersonName("David", "Lee", "Roth");
String kerbName = "dlr";
String emailAddress = kerbName + "@mit.edu";

int pidm = 12212871;
int mitId = 90002312;

Student student = new Student(String.valueOf(pidm), String.valueOf(mitId), kerbName,
                              personName, emailAddress);
Calendar now = Calendar.getInstance();

student.setCitizenship(new Citizenship("US", "United States"));
student.setEthnicity(new StudentEthnicity());
Calendar birthDate = Calendar.getInstance();
birthDate.set(Calendar.YEAR, birthDate.get(Calendar.YEAR) - 20);  // Born 20 years ago
student.setBirthDate(birthDate.getTime());
student.setDeceased(false);
student.setGender(Gender.FEMALE);
student.setStudentHolds(new ArrayList<StudentHold>());
student.setVersion(1l);
student.setCreateBy("testuser");
student.setCreateDate(now.getTime());
student.setModifyBy("testuser2");
student.setModifyDate(now.getTime());

 // Enrollment profile:
Set enrollProfiles = new HashSet();

// ... more code that builds enrollment profile objects...

student.setStudentEnrollProfiles(enrollProfiles);

...

I originally thought that the test builder factory classes would go into the csf-test module, as they are intended to be helper classes for unit tests. However, because the builder classes use the domain classes, this setup would cause circular dependencies - for example, csf-common-legacy would depend on csf-test, and csf-test would depend on csf-common-legacy. Because of this, it seems to make sense to place the builder classes close to the domain objects they are building. So the CoreDataFactory could go into csf-common-legacy in a new package in the domain area: edu.mit.common.domain.builders

A different way of looking at this is that by creating the helper classes, we are just abstracting out duplicate code from the unit test classes themselves. So perhaps the builders do belong in the test hierarchy. They are not strictly unit tests themselves, but by putting them under test, they would only be used when tests were run and would not be deployed as part of an app.

Core Data Factory Javadoc

Here's a screenshot showing the Javadoc for the Core Data Factory class.

Image Added

Does the Core Data Factory Satisfy the Goals?

Here's how I think the factory prototype satisfies the goals:

• Make the framework simple and easy to use

Once you have an instance of CoreDataFactory, getting a stucb Student object is a single method call.

• Keep the interfaces uncluttered

Taking student as an example, there are two build options: one that takes no arguments, one that takes a single termCode argument. We could have created a longer arg list for finer grained customization, but it seems better to keep the interface short and simple. If a unit test needs to tweak the data, it can do that after getting the student object.

• Provide the basics that should be good enough for most tests, but allow the flexibility for unit tests to tweak the data if necessary.