java - Redundant methods across several unit tests/classes -

say in main code, you've got this:

myclass.java

public class myclass {     public list<obj1> create(list<obja> list) {         return (new myclasscreator()).create(list);     }     // similar methods other crud operations } 

myclasscreator.java

public class myclasscreator {     obj1maker obj1maker = new obj1maker();      public list<obj1> create(list<obja> list) {         list<obj1> converted = new list<obj1>();         for(obja obja : list)             converted.add(obj1maker.convert(obja));         return converted;     } } 

obj1maker.java

public class obj1maker {     public obj1 convert(obja obja) {         obj1 obj1 = new obj1();         obj1.setprop(formatobjaproperty(obja));         return obj1;     }      private string formatobjaproperty(obja obja) {          // obja prop , manipulation on     } } 

assume unit test obj1maker done, , involves method makeobjamock() mocks complex object a.

my questions:

1. for unit testing myclasscreator, how test create(list<obja> list)? method delegate conversion obja obj1 , runs in loop. conversion tested. if create list of obja , tested each object in list of obj1 back, have copy makeobjamock() myclasscreator's unit test. obviously, duplicate code, is using verify() enough ensure create(list list) works?

2. for unit testing myclass, again, create(list<obja>) method delegates operation myclasscreator. need test full test cases, or should verify myclasscreator's create method called?

3. in unit test obj1maker, checked properties obj1 , obja corresponded each other doing assertequals(obj1.getprop(), formatobjaproperty(obja)). however, means had duplicate code private formatobjaproperty method obj1maker class unit test. how can prevent code repetition in case? don't want make method public/protected can use in unit test. repetition acceptable in case?

thanks, , sorry lengthy questions.

my opinion here. picking methods test hard thing do.

you have think a) whether meeting requirements , b) go wrong when stupid makes changes code in future. (actually, stupid person you. have bad days.)

i say, writing new code verify 2 objects have same data in 2 formats idea. there no reason duplicate code private method , copying code on bad idea. remember verifying requirements. if original string said "6/30/13" , reformatted 1 said "june 30th 2013", hard code check:

assertequals("wrong answer", "june 30th 2013", obj.getprop()); 

add more asserts edge cases , errors. (in example, use "2/30/13" , "2/29/12" , "12/1/14" check illegal date, leap year day , gets "1st" not "1th" perhaps.)

in test on create method, go easy error , verify returned array had same number 1 passed in. 1 passed in have 2 identical elements , different ones. i'd check identical ones came identical , different ones non-identical. why? because know formatter works.

i wouldn't test constructor make sure test ran code in it. it's make sure of code runs in test catch dumb errors null pointers missed.

the balance point looking for.

enough tests, testing enough different things, feel code working.

enough tests, testing obvious things, stupid changes in future found.

not many tests tests take forever run , developers (including you) put off running them because don't want wait or lose train of thought while run.

balance!