ATDD, ScalaTest, Cucumber and respecting DRY

In our last post we looked at how it was easy to use ScalaTest for doing acceptance testing. In a post prior to that, we had looked at doing the same with Cucumber. We had also concluded that though acceptance tests could be written in the way described however, there was an issue. Writing the feature files with individual features having multiple scenarios which would just be a repetition with change of values does not seem smart. It violates DRY (Don’t Repeat Yourself)

For instance, it would be clunky to have something like this

Feature: Multiplication 
  In order to avoid making mistakes
  As an accountant
  I want to multiply numbers

 Scenario: Multiply two variables
    Given a variable x with value 3
    And a variable y with value 4
    When I multiply x * y
    Then I get 12
  Scenario: Multiply two variables
    Given a variable x with value 3
    And a variable y with value 3
    When I multiply x * y
    Then I get 9

Ok, it can be done but is wasteful. Cucumber gives us a way to pass multiple values to a scenario. Look at the example below

 Scenario Outline: Multiply two variables
    Given a variable x with value <x_1>
    And a variable y with value <y_1>	
    When I multiply x <op> y
    Then I get <result>
    Examples:
      | x_1 | y_1 | op | result |
      | 20  | 30  | *  | 600    |
      | 30  | 30  | *  | 900    |
      | 40  | 30  | *  | 1200   |
      | 4   | 20  | *  | 80   |

If you notice, what we are doing here, you would realize that we are not changing our mapping code. You can read the mapping code here. We are simply creating a feature file which has like <x_1> , <y_1> etc. Then, we have an Examples: table which gives the values of the variables. The mapping code picks up values and results from here. You would find the complete Scala code for this on the Knoldus Github account.
Ok, so it is easy with Cucumber.

Let us see how we would achieve the same with our trusted ScalaTest. Look at the code below

import org.scalatest.FeatureSpec
import org.scalatest.GivenWhenThen
import scala.collection.mutable.Stack
import org.scalatest.prop.TableDrivenPropertyChecks

class MultiplicationSpecWithTable extends FeatureSpec with GivenWhenThen with TableDrivenPropertyChecks {

  val numbersToMultiply = Table(("Number1", "Number2", "Result"), ("3", "4", "12"), ("5", "6", "30"), ("7", "8", "56"))

  feature("Multiplication") {

    info(" In order to avoid making mistakes")
    info("As an accountant")
    info(" I want to multiply numbers")

    scenario("Multiply two variables") {
      forAll(numbersToMultiply) {
        (x: String, y: String, expectedResult: String) =>
          given("a variable x with value " + x)
          and("a variable y with value " + y)

          when("i multiply " + x +" and " + y)
          val actualResult = x.toInt * y.toInt

          then("i get " + expectedResult)
          assert(actualResult === expectedResult.toInt)
      }
    }
  }
}

The interesting things to note in the code snippet above are the following. We have,

1) Mixed in another trait called TableDrivenPropertyChecks
2) We created a table with values

 val numbersToMultiply = Table(("3", "4", "12"), ("5", "6", "30"), ("7", "8", "56"))

3) We then did an iteration over the table and used all the values therein

 forAll(numbersToMultiply) {
        (x: String, y: String, expectedResult: String) =>

4) We asserted for the actualResult and the expectedResult
5) And of course, we presented the following result to the stakeholders

6) If you noticed that ScalaTest ignores the first Tuple which is the table header ==> (“Number1”, “Number2”, “Result”). Isn’t that cool 🙂

That is all to it. The entire code can again be found on the Knoldus Github account.

Thus, as you would notice, in both the scenarios i.e. Cucumber and ScalaTest it is easy to pass in multiple values to your scenarios. In the next post, we would take a quick look at generating test data for passing to our scenarios. Till then.