Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add unit tests for ViewAllCommand and ViewCommand classes #111 #131

Merged
merged 44 commits into from
Jan 17, 2017
Merged
Show file tree
Hide file tree
Changes from 18 commits
Commits
Show all changes
44 commits
Select commit Hold shift + click to select a range
20e25f1
add unit test for view command
zzzzwen Dec 29, 2016
017b996
Add header comment
zzzzwen Dec 30, 2016
9d049e3
Add unit test for ViewAll command
zzzzwen Dec 30, 2016
f97c6b1
javadoc change
zzzzwen Dec 30, 2016
e942a7e
Move assertCommandResult method to TestUtil
zzzzwen Dec 30, 2016
42f0c7f
Extract TypicalPersons
zzzzwen Dec 30, 2016
b414b98
Conflict
zzzzwen Dec 30, 2016
7140ae2
Merge branch 'master' into 111-unit-test-view-viewall
zzzzwen Dec 30, 2016
5457976
Conflict resolving
zzzzwen Dec 30, 2016
ffd7b0f
Rework TypicalPersons
zzzzwen Dec 30, 2016
8b3d3a3
code quality
zzzzwen Dec 30, 2016
2486c44
Merge branch 'master' of https://github.com/se-edu/addressbook-level2
zzzzwen Jan 3, 2017
2d1260d
Update TypicalPersons
zzzzwen Jan 3, 2017
73147c3
Code style issues
zzzzwen Jan 3, 2017
915c4d9
Code quality
zzzzwen Jan 3, 2017
acfb6a3
Code Style and combine two test cases
zzzzwen Jan 4, 2017
ea54ab7
Grammar
zzzzwen Jan 4, 2017
3a068e6
Remove use of createList
zzzzwen Jan 4, 2017
2d4cf4f
Code Style
zzzzwen Jan 4, 2017
3048a59
rework getList
zzzzwen Jan 4, 2017
ea22dbf
extract method
zzzzwen Jan 4, 2017
5334baf
reorder message
zzzzwen Jan 4, 2017
defefe1
Code style
zzzzwen Jan 4, 2017
4d30dde
Code style
zzzzwen Jan 4, 2017
d64b9f4
Add one test case
zzzzwen Jan 4, 2017
261fcab
comment change
zzzzwen Jan 4, 2017
fe3fa09
extract local variable
zzzzwen Jan 4, 2017
b01b1e6
Remove list methods in TypicalPersons
zzzzwen Jan 4, 2017
39ad9a7
Remove unused import
zzzzwen Jan 4, 2017
d6a6987
javadoc and code style changes
zzzzwen Jan 4, 2017
d2e9c4d
code style change
zzzzwen Jan 5, 2017
449af76
code style changes
zzzzwen Jan 5, 2017
5fcc198
code style change
zzzzwen Jan 5, 2017
f565130
remove trailing whitespaces
zzzzwen Jan 5, 2017
f6c2d90
Code style
zzzzwen Jan 6, 2017
f584b82
code style
zzzzwen Jan 6, 2017
2a11bd5
Combine to generic methods
zzzzwen Jan 8, 2017
beef8ab
Code style changes
zzzzwen Jan 9, 2017
c3af8e8
code style changes
zzzzwen Jan 9, 2017
9c60233
Code style changes
zzzzwen Jan 9, 2017
b9db7e5
code style changes
zzzzwen Jan 13, 2017
5b654c4
Code style changes
zzzzwen Jan 15, 2017
b4aba03
code style changes
zzzzwen Jan 15, 2017
eb7f500
Code style changes
zzzzwen Jan 15, 2017
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions test/java/seedu/addressbook/commands/ViewAllCommandTest.java
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
package seedu.addressbook.commands;

public class ViewAllCommandTest {
// ViewAll command is tested together with View command
// This is because they function similarly but View command hides private information
// They are tested with same test data input
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget fullstops.

}
152 changes: 152 additions & 0 deletions test/java/seedu/addressbook/commands/ViewCommandTest.java
Original file line number Diff line number Diff line change
@@ -0,0 +1,152 @@
package seedu.addressbook.commands;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

import org.junit.Before;
import org.junit.Test;

import seedu.addressbook.common.Messages;
import seedu.addressbook.data.AddressBook;
import seedu.addressbook.data.person.Address;
import seedu.addressbook.data.person.Email;
import seedu.addressbook.data.person.Name;
import seedu.addressbook.data.person.Person;
import seedu.addressbook.data.person.Phone;
import seedu.addressbook.data.person.ReadOnlyPerson;
import seedu.addressbook.data.tag.UniqueTagList;
import seedu.addressbook.util.TestUtil;
import seedu.addressbook.util.TypicalPersons;

import static seedu.addressbook.util.TestUtil.assertCommandResult;

public class ViewCommandTest {
private AddressBook addressBook;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmph, we can't use TestUtil.createAddressBook() here because it throws a checked exception. However, if we step back a little, we see that TestUtil.createAddressBook() should not be passing on the DuplicatePersonException because it's only used for test data. (i.e. the same reason why TypicalPersons just asserts false if it encounters an IllegalValueException.)

So, I think you should just add this in to your PR:

diff --git a/test/java/seedu/addressbook/util/TestUtil.java b/test/java/seedu/addressbook/util/TestUtil.java
index 8f4eaf8..a1f0836 100644
--- a/test/java/seedu/addressbook/util/TestUtil.java
+++ b/test/java/seedu/addressbook/util/TestUtil.java
@@ -26,13 +26,16 @@ import seedu.addressbook.data.tag.UniqueTagList;
 public class TestUtil {
     /**
      * Creates an address book containing the given persons.
-     * @throws DuplicatePersonException if two or more given persons are the same
      */
-    public static AddressBook createAddressBook(Person... persons) throws DuplicatePersonException {
+    public static AddressBook createAddressBook(Person... persons) {
         AddressBook addressBook = new AddressBook();
 
         for (Person person : persons) {
-            addressBook.addPerson(person);
+            try {
+                addressBook.addPerson(person);
+            } catch (DuplicatePersonException e) {
+                throw new AssertionError(e);
+            }
         }
 
         return addressBook;

No point letting the quality of your PR suffer just because the code base just happens to be like this already.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, maybe name this typicalAddressBook to signal that it is filled with all the TypicalPersons.

private AddressBook emptyAddressBook;
private List<ReadOnlyPerson> emptyDisplayList = new ArrayList<ReadOnlyPerson>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collections.emptyList() would be more descriptive.

private List<ReadOnlyPerson> listWithAll;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be useful to name this lists so that first-time readers will know what they will be used for.

e.g. displayListWithAllTypicalPersons.

private List<ReadOnlyPerson> listWithSome;

@Before
public void setUp() throws Exception {
emptyAddressBook = TestUtil.createAddressBook();

TypicalPersons td = new TypicalPersons();
addressBook = td.getTypicalAddressBook();
listWithAll = td.getListWithAllPersons();
listWithSome = td.getListWithSomePersons();
}

@Test
public void viewCommand_invalidIndex_returnsInvalidIndexMessage() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damithc Do you prefer the naming to be execute_invalidIndex... or viewCommand_invalidIndex...?

I see the viewCommand_... naming was introduced by #118 (my fault, I should have noticed it), which is probably at odds with the project's naming convention.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you prefer the naming to be execute_invalidIndex... or viewCommand_invalidIndex...?

execute follows the naming convention strictly (i.e. an exact match to the method being tested), so just use that one?

// empty addressbook
assertViewErrorInvalidIndex(emptyAddressBook, emptyDisplayList, 1);

// non-empty addressbook
assertViewErrorInvalidIndex(addressBook, listWithAll, -1);
assertViewErrorInvalidIndex(addressBook, listWithAll, 0);
assertViewErrorInvalidIndex(addressBook, listWithAll, listWithAll.size() + 1);
}

@Test
public void viewCommand_personNotInAddressBook_returnsPersonNotInAddressBookMessage() throws Exception {
// generate person not in addressbook, add to displayList
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More descriptive: generate list with person not in addressbook.

Person someone = new Person(new Name("me"),
new Phone("123", true),
new Email("[email protected]", true),
new Address("nus", false),
new UniqueTagList(Collections.emptySet()));
listWithAll.add(someone);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This goes against how listWithAll is used in other tests (where listWithAll is filled with all the typical persons).

I think you should just define a local variable for this.


// empty addressbook
assertViewErrorPersonNotInAddressBook(emptyAddressBook, listWithAll, 1);

// non-empty addressbook
assertViewErrorPersonNotInAddressBook(addressBook, listWithAll, listWithAll.size());
}

@Test
public void viewCommand_validIndex_returnsPersonDetails() {
// person with no private information
assertViewSuccess(addressBook, listWithAll, 1);

// person with some private information
assertViewSuccess(addressBook, listWithAll, 2);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need a person with all info private, to confirm that 'privacy' works for each relevant field.

Copy link
Contributor Author

@zzzzwen zzzzwen Jan 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@damithc In TypicalPersons I have a person called dan, all the information which has the private/public option for him is private.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant such a person must be included as one of the test cases in this method. Your comment in line 74 says some private information so I guess that's not dan.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I get it


// addressbook has more people than displayList
assertViewSuccess(addressBook, listWithSome, 1);
}

/**
* Creates a new View command.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ViewCommand

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this comment doesn't add much value. Can be removed.

*/
private Command generateViewCommand(AddressBook addressBook, List<ReadOnlyPerson> displayList, int index) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why displayList? Isn't this naming inconsistent with what Command already uses? i.e. relevantPersons?

If you prefer the name displayList, then you should change all instances of relevantPersons to displayList as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, index is also inconsistent with the naming which ViewCommand or Command uses. i.e. targetIndex.

ViewCommand command = new ViewCommand(index);
command.setData(addressBook, displayList);

return command;
}

/**
* Creates a new ViewAll command.
*/
private Command generateViewAllCommand(AddressBook addressBook, List<ReadOnlyPerson> displayList, int index) {
Command command = new ViewAllCommand(index);
command.setData(addressBook, displayList);

return command;
}

/**
* Asserts that the details of the person at specific index can be successfully retrieved
* and displayed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asserts that both a ViewCommand and a ViewAllCommand can retrieve from the {@code addressBook} details of the person at the given {@code index} in the given {@code list}.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also add
@param index one-indexed position of the target person in the list

*/
private void assertViewSuccess(AddressBook addressBook, List<ReadOnlyPerson> list, int index) {
String expectedMessage = String.format(ViewCommand.MESSAGE_VIEW_PERSON_DETAILS,
list.get(index - 1).getAsTextHidePrivate());
assertViewCommandBehaviour(addressBook, list, expectedMessage, index);

expectedMessage = String.format(ViewCommand.MESSAGE_VIEW_PERSON_DETAILS,
list.get(index - 1).getAsTextShowAll());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Further to my previous comment about index-1, in fact list.get(index - 1) can be assigned to a local variable.
ReadOnlyPerson personBeingViewed = list.get(index-1); // -1 because index is one-indexed

assertViewAllCommandBehaviour(addressBook, list, expectedMessage, index);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

index - 1 appears twice. Assign to local variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that a new local variable, eg, pos = index - 1 doesn't add much value since index-1 just refer to the position in the list and won't be changed. Is it necessary to extract to a local variable?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By local, I meant inside the method. Reasons,

  1. It's not good when a calculation is duplicated.
  2. its meaning is not immediately clear.

Something like this will help clear both problems.

int internalIndex = index - 1; // because index is one-indexed

}

/**
* Asserts that the details of person at specific index cannot be retrieved due to
* invalid index.
*/
private void assertViewErrorInvalidIndex(AddressBook addressBook, List<ReadOnlyPerson> list, int index) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this really need its own method?

Yes, I know the alternative is repeating Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX in viewCommand_invalidIndex_returnsInvalidIndexMessage(), but then again with this method you still need to repeat assertViewErrorInvalidIndex anyway, which probably means this method doesn't add much value.

If the reason is because Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX is too long, then you can assign in to a variable with a shorter name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If inline this method and put Message into the test case, does it really make sense or help improve readability?

eg. assertViewErrorPersonNotInAddressBook(emptyAddressBook, listWithAll, 1) -> assertCommandError(emptyAddressBook, listWithAll, 1, Message.PERSON_NOT_IN_ADDRESSBOOK)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assertCommandError does not imply what expected error is and can we assume that reader can infer from the parameter about the expected error? In this case, assertViewErrorInvalidIndex is clearer for me

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zzzzwen

assertCommandError does not imply what expected error is and can we assume that reader can infer from the parameter about the expected error

Doesn't your test name already say _returnsInvalidIndexMessage?

In this case, assertViewErrorInvalidIndex is clearer for me

OK then.

String expectedMessage = Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX;

assertViewCommandBehaviour(addressBook, list, expectedMessage, index);
assertViewAllCommandBehaviour(addressBook, list, expectedMessage, index);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be simplified as this (after extracting common part of this and next method)?
assertCommandError(addressBook, list, index, Messages.MESSAGE_INVALID_PERSON_DISPLAYED_INDEX)

}

/**
* Asserts that the details of person at specific index cannot be retrieved due to
* person not existing in the addressbook.
*/
private void assertViewErrorPersonNotInAddressBook(AddressBook addressBook, List<ReadOnlyPerson> list, int index) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this really need its own method? Same reasoning as assertViewErrorInvalidIndex.

String expectedMessage = Messages.MESSAGE_PERSON_NOT_IN_ADDRESSBOOK;

assertViewCommandBehaviour(addressBook, list, expectedMessage, index);
assertViewAllCommandBehaviour(addressBook, list, expectedMessage, index);
}

/**
* Asserts that the View command gives correct feedback information
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct --> given

*/
private void assertViewCommandBehaviour(AddressBook addressBook, List<ReadOnlyPerson> list, String message, int index) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reorder parameters so that the three input values come first?
message -> expectedMessage

Command command = generateViewCommand(addressBook, list, index);
assertCommandResult(command, message, addressBook, TestUtil.clone(addressBook));
}

/**
* Asserts that the ViewAll command gives correct feedback information
*/
private void assertViewAllCommandBehaviour(AddressBook addressBook, List<ReadOnlyPerson> list, String message, int index) {
Command command = generateViewAllCommand(addressBook, list, index);
assertCommandResult(command, message, addressBook, TestUtil.clone(addressBook));
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this class is almost the same as the other test class, we can text both commands in one of the class and make the other class empty with just a comment to explain why it is empty.

16 changes: 16 additions & 0 deletions test/java/seedu/addressbook/util/TestUtil.java
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@
import java.util.ArrayList;
import java.util.List;

import seedu.addressbook.commands.Command;
import seedu.addressbook.commands.CommandResult;
import seedu.addressbook.data.AddressBook;
import seedu.addressbook.data.exception.IllegalValueException;
import seedu.addressbook.data.person.Address;
Expand Down Expand Up @@ -75,4 +77,18 @@ public static void assertTextFilesEqual(Path path1, Path path2) throws IOExcepti
List<String> list2 = Files.readAllLines(path2, Charset.defaultCharset());
assertEquals(String.join("\n", list1), String.join("\n", list2));
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary change.

/**
* Executes the command, and asserts the result message is as expected.
*/
public static void assertCommandResult(Command command, String expectedMessage, AddressBook addressBook,
AddressBook expectedAddressBook) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, can reorder parameters so that input comes first and expected values come next.

CommandResult result = command.execute();

// asserts the result message is correct as expected
assertEquals(expectedMessage, result.feedbackToUser);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be comparing the CommandResult instead, rather than just one field of it?

For example, we may wish to check that CommandResult.getRelevantPersons() returns Optional.empty() or a list that we expect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be comparing the CommandResult instead, rather than just one field of it?

Yes, that's actually better. I don't mind leaving it as a TODO though.


// TODO: overwrite equals method in AddressBook and replace with equals method below
assertEquals(addressBook.getAllPersons(), expectedAddressBook.getAllPersons());
}
}
32 changes: 26 additions & 6 deletions test/java/seedu/addressbook/util/TypicalPersons.java
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
package seedu.addressbook.util;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra space

import java.util.ArrayList;
import java.util.List;

import seedu.addressbook.data.AddressBook;
import seedu.addressbook.data.exception.IllegalValueException;
Expand All @@ -7,23 +10,27 @@
import seedu.addressbook.data.person.Name;
import seedu.addressbook.data.person.Person;
import seedu.addressbook.data.person.Phone;
import seedu.addressbook.data.person.ReadOnlyPerson;
import seedu.addressbook.data.tag.Tag;
import seedu.addressbook.data.tag.UniqueTagList;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove extra space?

/**
* Class to generate typical test persons
*/
public class TypicalPersons {

public Person amy, bill, candy;
public Person amy, bill, candy, dan;

public TypicalPersons() {
try {
amy = new Person(new Name("Amy Buck"), new Phone("91119111", false), new Email("[email protected]", false),
new Address("1 Clementi Road", false), new UniqueTagList());
bill = new Person(new Name("Bill Clint"), new Phone("92229222", false), new Email("[email protected]", false),
new Address("2 Clementi Road", false), new UniqueTagList());
candy = new Person(new Name("Candy Destiny"), new Phone("93339333", false),
new Email("[email protected]", false), new Address("3 Clementi Road", false), new UniqueTagList());
new Address("2 Clementi Road", true), new UniqueTagList());
candy = new Person(new Name("Candy Destiny"), new Phone("93339333", true),
new Email("[email protected]", false), new Address("3 Clementi Road", true), new UniqueTagList());
dan = new Person(new Name("Dan Smith"), new Phone("1234556", true), new Email("[email protected]", true),
new Address("NUS", true), new UniqueTagList(new Tag("Test")));
} catch (IllegalValueException e) {
e.printStackTrace();
assert false : "not possible";
Expand All @@ -41,7 +48,7 @@ private void loadAddressBookWithSampleData(AddressBook ab) {
}

public Person[] getTypicalPersons() {
return new Person[]{amy, bill, candy};
return new Person[]{amy, bill, candy, dan};
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave at least one blank line between the last method and the closing brace of the class.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why this is shown as a diff. Most of it looks identical.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, this is because there is an extra whitespace for each line, sorry

public AddressBook getTypicalAddressBook() {
Expand All @@ -50,4 +57,17 @@ public AddressBook getTypicalAddressBook() {
return ab;
}

public List<ReadOnlyPerson> getListWithAllPersons() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getAllPersons()? the List is implied by the return type

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, not sure if you need this method. Can you use getTypicalPersons() instead, and convert it to a list using Arrays.asList()?

List<ReadOnlyPerson> list = new ArrayList<ReadOnlyPerson>();
for (Person p : getTypicalPersons()) {
list.add(new Person(p));
}
return list;
}

public List<ReadOnlyPerson> getListWithSomePersons() {
List<ReadOnlyPerson> list = getListWithAllPersons();
list.remove(0); //remove a person in the list
return list;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is very specific to your test class and therefore not a good abstraction. Try something like this instead:
public List<ReadOnlyPerson> getList(ReadOnlyPerson... personsToInclude);

Can be used like this:
getList(td.amy, td.candy);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noted

}