search

sebastianbenz / Jnario

Executable specifications for Java
136 stars 38 forks source link

Step references don't call assert, resulting in false positive results #161

Open Vulcannis opened 9 years ago

Vulcannis commented 9 years ago

When referencing other steps, the condition is evaluated but not asserted. That is, Should.operator_doubleArrow() is called but not wrapped in an assertTrue in code generated for the referencing step. Tested with 1.0 and 1.1.0-SNAPSHOT, the following test passes when it should fail:

Feature: Testing stuff
    Scenario: Scenario 1
        Then "0" should equal "0"
            args.first => args.second
        And "1" should equal "0"
Vulcannis commented 9 years ago

I tried poking around a bit, it seems to be an issue with the processing of =>. DoubleArrowSupport.isDoubleArrow() fails for the And step, as !"=>".equals( "<implicit: org.jnario.lib.Should.operator_doubleArrow(T,T)>" ). Using "should be" instead of "=>" works fine.

riederm commented 7 years ago

The issue here is, that the org.jnario.feature.jvmmodel.StepExpressionProvider copies the "implementation"-AST part from the Step that carries the original implementation. Adapters are not copied (and in fact its not really easy to copy these). So the copied objects cant access the NodeModel. Unfortunately the processing of the "=>" needs the nodeModel: org.eclipse.xtext.xbase.impl.XAbstractFeatureCallImplCustom.getConcreteSyntaxFeatureName()

I don't exactly understand yet why the stuff is cloned, so I'll take a look at it these days. I think also other bugs come from this copy-situation. I recall some debugging sessions in my company where some Jnario AST-elements just seemed to have no node-model.