Hi, Jeremy.
In my case, the equivalent code in my domain would be:
@Then("^.*the \"([^\"]*)\" risk register's risks collection should
contain:$")
public void
then_riskregisters_risks_collection_should_contain(@Transform(RiskSpecTransformer.RiskRegister.class)
final RiskRegister riskRegister, final List<RiskDesc> listOfExpecteds) throws
Throwable {
this.nextTransaction();
final SortedSet<Risk> risks = riskRegister.getRisks();
final ArrayList<Risk> risksList = Lists.newArrayList(risks);
assertTableEquals(listOfExpecteds, risksList);
}
Where the "assertTableEquals(xxx)" method is implemented on the
"CukeGlueAbstract" class and compares by name each field on the spec, with the
proper one on the class. Is this what you want to achieve?
Regards,
Oscar
El 27/08/2013, a las 16:37, Jeremy Gurr <[email protected]> escribió:
> I'm playing around with the cucumber support tools in isis (a testing
> framework for behavior driven development, for those who don't know), and
> have created a test that basically looks like this:
>
> Scenario: A new service class is added
> Given these service classes:
> | service class name |
> | Insurance |
> | Product Manufacturer |
> When new service classes are created:
> | service class name |
> | Transportation |
> Then these service classes will exist:
> | service class name |
> | Insurance |
> | Product Manufacturer |
> | Transportation |
>
> The first two steps run fine, and for the third I am trying to run a simple
> existence check on the object using the following code:
>
> @Then("^these service classes will exist:$")
> public void service_classes_will_exist(List<ServiceClass>
> serviceClassesWillExist) throws Throwable {
> for (ServiceClass serviceClass : serviceClassesWillExist) {
> assertThat(serviceClasses.exists(serviceClass), is(true));
> }
> }
>
> It's very convenient that cucumber instantiates my ServiceClass model object
> and automatically plugs in fields according to the feature spec column
> header. This enables me to add new fields simply by adding a column in the
> spec, and adding the corresponding column in my model object. It skips the
> extra hassle of having to update the glue code as well as service methods to
> construct the object.
>
> The "exists" method contains this code:
>
> public boolean exists(ServiceClass serviceClass) {
> final QueryFindByPattern<ServiceClass> query = new
> QueryFindByPattern<ServiceClass>(ServiceClass.class, serviceClass);
> final ServiceClass firstMatch = firstMatch(query);
>
> return firstMatch != null;
> }
>
> I'm just trying to verify that an object exists with fields matching the
> incoming object, some fields of which may be null, meaning that they can be
> any value. The QueryFindByPattern class seemed to be a perfect fit since I'm
> passing around ServiceClass instances anyway. However, running it executes
> code that is not yet implemented:
>
> org.apache.isis.core.commons.exceptions.NotYetImplementedException: This
> method is not implemented yet
> at
> org.apache.isis.objectstore.jdo.datanucleus.persistence.queries.PersistenceQueryFindByPatternProcessor.process(PersistenceQueryFindByPatternProcessor.java:55)
> at
> org.apache.isis.objectstore.jdo.datanucleus.persistence.queries.PersistenceQueryFindByPatternProcessor.process(PersistenceQueryFindByPatternProcessor.java:30)
> at
> org.apache.isis.objectstore.jdo.datanucleus.DataNucleusObjectStore.processPersistenceQuery(DataNucleusObjectStore.java:542)
> at
> org.apache.isis.objectstore.jdo.datanucleus.DataNucleusObjectStore.loadInstancesAndAdapt(DataNucleusObjectStore.java:537)
> ...
>
> So my question is, is there a better way to go about this? My goal is to have
> the field definitions in only two places, the model definition class and the
> feature spec. I'd rather not replicate that info further into the glue,
> utility testing code, and service methods, making test management much more
> difficult. Since I'm using a BDD process, keeping tests very agile is
> important to keeping the project maintainable in the long run. Should I try
> and implement the part that isn't implemented? Should I make my own JDO
> service class that can create the appropriate query object? Should I just
> make a straight SQL call bypassing JDO entirely?
>
> As a next step, I intend to parameterize the "service classes" part of the
> glue code so that the same glue code can be used to test ALL of my model
> entities, not just service classes, greatly reducing the boilerplate code.
>
> Jeremy
>
