Is there a better way to do this?

Is there a better way than using Java's switch case to handle this scenario?  

I'm using the Cucumber framework and creating some test cases to verify whether specific links exists on a webpage.  

For starters right now,  I'm verifying if I can find the link, if I can click on the link and after I click on the link, whether the page loads, what the webpage title is, and what the URL is.   In my example code below ( just an example ) each of the switch cases is handling an assert statement which verifies what the page's URL value is.    It gets the job done but I'm just curious if I can do better?

Thank You in advance.  


Example code

public class webpageStepDef { WebDriver driver = UITestBase.getDriver(); Webpage webpage = new Webpage(driver); @And("User clicks on the {word} hyperlink") public void clickSecurityHyperlink(String word) {      webpage.clickclickLink(word);      switch(word) {             case "Security":                      Assert.assertTrue(driver.getCurrentURL().contains(webpage.getSecurityURL()));                     break;             case "Contact":                      Assert.assertTrue(driver.getCurrentURL().contains(webpage.getContactURL()));                     break;              case "Blog":                      Assert.assertTrue(driver.getCurrentURL().contains(webpage.getBlogURL()));                     break;      } } } public class Webpage { @Getter private String contactURL = "/contact-us"; @Getter private String blogURL = "/blog"; @Getter private String securityURL = "/security"; }

This isn't that much of an improvement, but it is a bit nicer to read/maintain (Java17+).
var expectedValue = switch (word) {      case "Security" -> webpage.getSecurityURL();      case "Contact" -> webpage.getContactURL();      case "Blog" -> webpage.getBlogURL();      default -> throw new IllegalArgumentException("Unexpected word: %s".formatted(word)); }; Assert.assertTrue(driver.getCurrentURL().contains(expectedValue));

Thank You so much!  I ALWAYS appreciate the help.  

Any kind of conditional control in a test is a smell. The problem is that it makes the test brittle when more conditions need to be covered. In your case, additional word values will make it necessary to add another case to the switch statement. As the number of words grow, so will the complexity of that test step definition.

Another thing about conditionals in a test case is that there are multiple reasons for the test to fail. Ideally, a failing test should allow you to zero in quickly on a problem in the code. Multiple reasons for failing diminishes the usefulness of a test in finding problems quickly. This is in general. In your case, however, it's not too big of concern because any failure of that test can be generalized as "expected URL not found". But keep the general caution in mind for future reference.

What I would try to do instead is to create a map of (word ‐> URL) and the use the word to look up the expected URL. This way your test itself will have stable code and you only need to add entries to the map whenever a new word and its related URL are introduced.

This alternative approach may seem like "the same difference" but it's really not. The code with switch/case is a test with conditionals whereas the code that uses a map lookup is parameterized and more resilient to changes.

I was reading your OP on my phone earlier and I didn't see all of the code you posted. Now that I've seen it fully, however, I see you're making assertions in a step that is annotated with @And("user clicks on {word} hyperlink"). I wouldn't do that.

The problem is that this step is part of the "Act" portion of the test, not the "Assert" (from Arrange, Act, Assert pattern).

The annotation itself implies your Gherkin specification has statements like:

And User clicks on the Blog hyperlink
And User clicks on the Contact hyperlink
And User clicks on the Security hyperlink

a better formulation won't imply implementation details:

And User navigates to the Blog page
And User navigates to the Contact page
And User navigates to the Security page

A specification should be focused on behavior or intent, not implementation. The words "clicks" and "hyperlink" speak to the implementation details rather than the behavior or intent.

In a step that is annotated with an action like this, I would instead save some aspect of the state that I would be interested in asserting later on in an @Then step.

For example:
private static final String NOT_FOUND = "http://an_error_page_of_some_kind?"; private String newPageUrl; private Map<String, String> pageUrls = Map.of(   "Blog", "http://...whatever",   "Security", "http://...whatever",   "Contact", "http://...whatever", ); @And("user navigates to the {word} page") public void userNavigatesToPage(String word) {   // code here only does things related to "navigate to page"   newPageUrl = pageUrls.getOrDefault(word, NOT_FOUND + word);   //... other stuff that would simulate navigating to the newPageUrl } @Then("the new page has title of {title}") public void newPageHasTitle(String title) {   checkFailedToNavigateToPage();   ...   // make the assertion for the title here   assertEquals(...); } @Then("the new page has URL of {url}") public void newPageHasUrl(String url) {   checkFailedToNavigateToPage();   // make the assertion for the URL here } private void checkFailedToNavigateToPage() {   if (newPageUrl.startsWith(NOT_FOUND)) {      fail("Did not find the expected link - " + newPageUrl);   } }
Caveat: the above is example code only that represents an idea off the top of my head; I haven't tried to actually run it but it outlines the general structure and organization of the step definitions as I would approach it.

Explanation of the NOT_FOUND value: I would set up a page specifically for redirecting errors to. This page would take a parameter that will help you figure out what the problem was. For example, I might establish a route for "/unmappedLink" and have it return a page that had a title (or header or whatever kind of element you prefer) of "Error: unmapped link for word: {word}". In that case, the declaration would be:
private static final String NOT_FOUND = "/unmappedLink?word=";
Be sure to enable this route for testing only and disable in production otherwise you'll inadvertently create a potential backdoor vulnerability.

Junilu Lacar wrote:
This alternative approach may seem like "the same difference" but it's really not. The code with switch/case is a test with conditionals whereas the code that uses a map lookup is parameterized and more resilient to changes.

Put another way, a parameterized test essentially creates a set of separate tests for different scenarios. The test code itself simply becomes the template for the logic. A test with conditionals puts all the eggs in one basket and if any one thing in there breaks it will look like everything broke.

You can also use a data table with word and URL in your test specification (the Gherkin part) -- this allows you to parameterize at the specification level instead of in the step definition as I showed earlier.

Bottom line, if you find yourself writing multiple conditionals in a test or step definition, then think about changing to a data-driven parameterized test instead.

Junilu Lacar wrote:You can also use a data table with word and URL in your test specification (the Gherkin part) -- this allows you to parameterize at the specification level instead of in the step definition as I showed earlier.

Bottom line, if you find yourself writing multiple conditionals in a test or step definition, then think about changing to a data-driven parameterized test instead.

Thank you for all your help and advice. I'm going to try and implement the changes you suggested regarding the data table .  The steps are written by our product owners on a Jira xray test and then we implement the Gherkin , step defs etc.  So I try and follow what the product owners had for the xray tests.

So for one of the tests it's actually like

Scenario:  Verify user should navigate to Security page upon Clicking Security hyperlink
  When  User confirms they see the Security hyperlink
  And  User clicks on the Security hyperlink
  Then User has landed on the Security page


So if I understand correctly and  write it up the way you suggest ,


Scenario:  Verify user should navigate to Security page upon Clicking Security hyperlink
  When  User confirms they see the Security hyperlink
  Then User navigates to the Security page

Is that right?  

I suggest you go to https://school.cucumber.io and watch the training video they have up there. It's free and very informative.

What you're describing is a typical subversion of the BDD process. This happens when teams use the tools and the Gherkin format without understanding how they're supposed to be used and how the process actually works.

In summary, the BDD approach consists of three practices:

1. Discovery - this is where business, development, and test come together to have a "Three Amigos" conversation. They draw up examples of the different scenarios, without using the Gherkin format. There's a book on the Discovery phase written by Seb Rose and Gaspar Nagy. They also wrote other books on each of the other practices I describe here. Nagy and Rose advise against using the Gherkin format during discovery. Focus on gathering specific examples and the behaviors of the system as users interact with it.

2. Formulation - after discovery, the team will have several concrete examples to feed into this step. Developers and testers will get together and formulate the Gherkin specifications. They will use the examples from Discovery to draw up different scenarios. They will then go back to the larger group and review the formulations to verify that they got everything right and that there was nothing missed. They could also bring up new examples they might have thought about during formulation or make suggestions on how to simplify the scenario.  In the video on school.cucumber.io, they show examples of how the formulated specifications can actually be refactored as a result of the review.

3. Automation - this is when developers (and possibly testers) automate the tests by adding step definitions in the form of test code.

This is the overall BDD cycle and it feeds other parts of the development process, specifically the TDD cycle, where developers develop the functionality with the support of the BDD specifications, which basically become the acceptance tests.

How I would write your specifications:

Scenario: User navigates to the Security Page from the Home Page

  Given the user has logged in
  And is viewing the Home page
  And has access to the Security page
  When the user navigates to the Security page
  Then the title on the page should be "Security Settings"


Note again that any mention of "click" and "hyperlink" should be avoided. These are implementation details. You want to avoid implementation details so that the test will still be valid even though the implementation may have changed. For example, somewhere down the road, a decision might be made to use a hamburger menu option instead of a hyperlink.

Again, I encourage you to educate yourself on the proper BDD process by going through the free tutorials on school.cucumber.io

Here's what Nagy and Rose wrote in their "Discovery" book:

Gaspar Nagy and Seb Rose wrote:
BDD is an Agile approach that consists of three practices that have to be addressed in order. The first practice is discovery, a structured, collaborative activity that uses concrete examples to uncover the ambiguities and misunderstandings that traditionally derail software projects.

The second practice is formulation a creative process that turns the concrete examples produced during discovery into business-readable scenarios. The subsequent review of the scenarios delivers the confidence that the team really has understood what the business is asking for.

The third, and final, practice is automation where code is written that turns the scenarios into tests.

Thanks for the suggestion!  I have on my ToDo to take a cucumber course so this helps me out a lot for a suggested course.   I will do that.