How do I have both service test and UI test for the same step?

95 views
Skip to first unread message

Luk Lau

unread,
Nov 7, 2012, 11:02:13 AM11/7/12
to specificati...@googlegroups.com
for example:

Given Scenario 1: 

Given user have an saving account (stub with UI call)
And saving account has $100 (stub with UI call)
When saving account is credited with $20 (stub with UI call)
Then saving account total shall be $120 (stub with UI call)

When I have Scenario 2:

Given user have an saving account (i want a stub with Service call)
And saving account has $100 (stub with UI call)
When saving account is debited with $20 (stub with UI call)
Then saving account total shall be $80 (stub with UI call)

Challenge here:
In scenario 2, I want to use the service call to setup the state quickly by calling the service.
But "user have an saving account" has already been mapped to a stub with UI impls....

And writing 2 slightly different steps: having 1 maps to service impl and the other to UI impl
will dilute the integrity of the intention of the feature steps.

What will you do in this scenario?


Thanks in advance

Luc

Chris Bingham

unread,
Nov 8, 2012, 12:04:50 AM11/8/12
to specificati...@googlegroups.com
I've been eyeing up doing just this myself :)

i'm thinking maybe Abstract the actual logic out and use context injection?

https://github.com/techtalk/SpecFlow/wiki/Context-Injection (right at the bottom)

so your steps delegate off to another class to perform the actual work, i.e.

[Binding]
public class SavingsAccountSteps
{
 public SavingsAccountSteps(ISavingsAccountContext context)
 {
  this.context = context;
 }
 [Given("user have a savings account")]
 public void GiveUserSavingsAccount()
 {
  context.GiveUserSavingsAccount();
 }
}

then have two external assemblys (one doing stuff thru the ui and one in memory) with classes that implement you context interface (ISavingsAccontContext)


on the first run of your tests, reference the in-memory context from your config
on the second run, reference your UI context assembly

disclaimer: i've not tried this but i'm fairly sure it should work.



--
You received this message because you are subscribed to the Google Groups "Specification by Example" group.
To view this discussion on the web visit https://groups.google.com/d/msg/specificationbyexample/-/26YTwUUry9YJ.
To post to this group, send email to specificati...@googlegroups.com.
To unsubscribe from this group, send email to specificationbyex...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/specificationbyexample?hl=en.

Chris Bingham

unread,
Nov 8, 2012, 12:08:13 AM11/8/12
to specificati...@googlegroups.com
which actually brings me to a (sorry if this is a hijack) question of my own ...

can you put StepAttributes on interfaces? (i hacked nbehave to do this yonks ago and it worked fairly well iirc)

Lancer Kind

unread,
May 12, 2013, 10:53:49 AM5/12/13
to specificati...@googlegroups.com
This implies that you can only have one step class (binding) map to one GWT. Due to the for mentioned, you need the context class to route different step behavior to the right class (using composition).

The above requires tight integration. I wish loosely coupled teams could contribute different bindings (UI team and a service team) to a Single GWT scenario. With context classes, they need to integrate their code together into a single binding.

Reply all
Reply to author
Forward
0 new messages