how to create a complex object from a Cucumber table?

Question

I do not know how to read table from .feature and populate correctly

| payInstruction.custodian | and | payInstruction.acctnum |

like the internal class.

I have a table:

  | confirmationId | totalNominal | payInstruction.custodian | payInstruction.acctnum |
  | 1              | 100.1321     | yyy                      | yyy                    |
  | 2              | 100.1351     | zzz                      | zzz                    |

and I have class template which has the next structure:

class Confirmation {
String confirmationId;
double totalNominal;
PayInstruction payInstruction;

}

class PayInstruction  {
String custodian;
String acctnum;
}

auto converting table to List<Confirmation> has error because cannot recognize payInstruction.acctnum and pay payInstruction.custodian

any help ?

Answer 1

I know the question is a bit old, but Google did drive me here and could do so with others in the future.

.feature adaptations according to the question :

Given some confirmations:
| confirmationId | totalNominal |
| 1              | 100.1321     |
| 2              | 100.1351     |
And some pay instructions:
| confirmationId | custodian | acctnum |
| 1              | yyy       | yyy     |
| 2              | zzz       | zzz     |

Steps implementation :

Map<Integer, Confirmation> confirmations;

@Given('^some confirmations:$)
public void someConfirmations(List<Confirmation> confirmations) {
  this.confirmations = confirmations.stream().collect(Collectors.toMap(Confirmation::getConfirmationId, Function.identity()));
}

@And('^some pay instructions:$)
public void somePayInstructions(List<PayInstructionTestObject> payInstructions) {
  payInstructions.forEach(pi -> 
    this.confirmations.get(pi.getConfirmationId()).addPayInstruction(pi.toPayInstruction())
  );
}

The trick is to create a sub class of PayInstruction in test folder which holds a confirmation id as correlation identifier to retrieve the correct confirmation. The toPayInstruction method serves as converter to get rid of the test object.

Hope the Java and feature code is almost compiling, I'm writing this without effectively making it run. Slight adaptations might be necessary to make it run.

The original business model was untouched by the solution, not breaking / tweaking it for testing.

Answer 2

My approach would be to supply the constructor for Confirmation with four primitives and then create the PayInstruction in the constructor of Confirmation.