What to test with Cucumber: front-end, back-end or both?

[Naresh Bhatia]

Given a scenario like this, how does one decide if Cucumber should drive the front-end, back-end or both:

Given that I am a staffing coordinator

When I bring up my open project needs

I should see only the needs that are assigned to me

Given the expressive nature of Gherkin, I can see that both front-end and back-end developers might want to leverage it to test their own pieces, separately and together! But what do people generally do?

• Who are the acceptance tests for? The business user? If so, would they even care that the back-end is able to do this?
  
• Should both front-end and back-end guys developers use the same scenarios to test their parts separately. That could be a lot of effort. The back-end implementation has to perhaps drive a RESTful API and check the HTTP responses. The front-end test, on the other hand, has to use a tool like Selenium to drive the front-end. Very different tooling and different type of effort.
• How do you handle the differences in focus? While the back-end developer is simply interested in returning the results (in this case open needs assigned to the staffing coordinator), the front-end developer may need to focus on highlighting the better matches, which may be a purely front-end requirement. Of course, there has to be a separate test for that, but the back-end developer would have no interest in it.

Thanks in advance for your time and thoughts.

Naresh

[Selenium Framework]

I have couple of thoughts on this and these are NOT answers, but my own struggles and what worked for me.

1) All those testing jargon we hear (the list is bigger than the link you shared) - It really depends on the scope of how much we want to test to feel assured and confident to release code to production. The scope "can" be infinite at times, however we are always pressed by time and deadlines, so we have to choose "what is most valuable testing"

2) And the most valuable testing is generally the ones that "matter to customer" (Of course back tracking and getting into details would eventually lead us all kinds of testing again) --- However in many firms there is far too much emphasis on testing for the "sake of testing" , rather than focusing on testing the "acceptance criteria"

3) So Cucumber helps all the roles/team members to focus energies on aligning with "what is most important" -- So as long as we stick to the team (3 amigos) agreeing on "what" to test in the cycles/sprints we have --- We derived a lot of benefit out of Cucumber

4) On the other hand, if we go into too much on the "how" part  (which tools , what languages, what patterns etc.) -- aka. software design, best practices and so on -- we might be losing the benefits of what Cucumber is supposed to do -- Hence the testing pyramid (Search for Matthew Wynne talks on how Cucumber should can touch all the layers in the testing pyramid)

5) Cucumber is a collaborative tool/framework -- NOT an awesome killer technology/tool/library that helps us do all kinds of testing (verification/validation etc) -- So we should look at Cucumber as helping us bring together different stakeholders on same page [Business Analysts, product owners, developers, testers et al.]. The instant we start seeing Cucumber as a ubiquitous technology than solves all inter-operability issues among all stacks [Java, Js, C#, Ruby..zillion others] ,we might be missing the real purpose.

Coming back to specifics to your question..

Cucumber was only the front layer -- the back n-layers of code that I have used and that touches various aspects of application are -- GUI using selenium, API's using rest&soap clients, message queues using apache mq for eg, mainframes using clients like terminal emulators, databases using whatever client libraries were provided by the libraries that existed in those stacks (Java, Ruby, C#, Js ....)

So we had two major purposes that Cucumber helped.

• A common page for product owners, ba's and developers/programmers by describing acceptance criteria --- Business facing scenarios (Working pretty well)
  
• Technical facing scenarios -- All those actual code behind's that only programmers can decipher (apis, mq's...)

We are dealing with figuring out ways to reduce complexity on the technical facing scenarios -- as they constantly evolve and it gets really difficult to have "declarative" style of Cucumber on these technical facing scenarios -- though we are trying to keep it simple and push the "how" complexities as low as possible down the stack [in the layers behind Cucumber]

Personally, I did NOT find a huge value add by using Cucumber to drive the unit tests, because only the developers in the team knew how those worked , product owners or testers hardly cared about those tests, so asking them to collaborate on this was probably not working for us especially when we had more pressing and valuable things like acceptance tests - though we initially started using Cucumber to touch all layers in the application. 

Overall, though we started boiling the ocean (aka. application layers) using Cucumber everywhere we can -- We are starting to realize that we need to address the Testing pyramid (http://www.seleniumframework.com/decision-models/choose-automation-solution-2/) by writing good tests at each layer. Those tests "if" mattered to all the 3 amigos, then use Cucumber, if they do NOT matter (for whatever reasons - time, money, skills, culture) , we are letting the experts (mostly developers) choose whatever works.

At this point in time, we write acceptance tests (the ones that matter to business stake holders, product owners) in Cucumber , the rest of tests that involve more technical details -- we are sticking to tools that the team had skills in or what they agreed upon after internal debates and discussions.

My 2 cents.

cheers,

www.seleniumframework.com

[Naresh Bhatia]

@seleniumframework, thanks so much for a detailed reply. This is exactly the kind of practical advice that I was looking for.

Other opinions/experiences welcome!

Thanks again,

Naresh

[80Vikram]

Hey Naresh,

I'm as well having same query as yours.

Can you please share your experiences from last 1 yr , how you could fit Cucumber in Test Pyramid & challenges , learning out of it ?

I would like to follow Test Pyramid approach strictly; as I really feel the pain of Ice Cream cone approach ( having most of regression cases automated at UI level )

Thanks in advance.

Regards,
Vikram