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
