Project automated testing using Gherkin syntax

ideas
1

There is no automated testing infrastructure now in place for the final ORIGAM projects. If the project is complex the regression testing must be done by hand or by using an external automated testing infrastructure.

In order to achieve this we could integrate https://specflow.org as this provides C# interfaces for the testing infrastructure.

Example of a Gherkin syntax:

Feature: Screen1
 
Filling data to a Screen1
 
@mytag
Scenario: Fill in a row
Given I open the screen Screen1
And I have added a record into Section1
And I have entered <First> into the field First
And I have entered <Second> into the field Second
And I have confirmed the record
 
When I press Save
Then the Third field should be <Result>
And the screen should not be dirty
Examples:
| First | Second | Result |
| 50    | 70     | 120    |
| 30    | 40     | 70     |
| 60    | 30     | 90     |

What we want is to hand over the creation of the test scripts to the customer as the test scripts would work with real-world test cases from the customer’s point of view.

The tester should:

  • write test scripts and store them in a git repository (probably the project’s repo), probably using Visual Studio with syntax highlighting
  • run docker that would compile the scripts, build a final test ORIGAM docker image, etc.
  • execute the final docker image
  • run the tests (preferably on a self included database but possibly on the customer’s test database)
  • look at the results

So the tester should be have the development/test environment installed but they would only basically need to know how to start the tests.

What we need to provide:

  • Gherkin interfaces, e.g. Given I open the screen X
  • Infrastructure for compiling and running the tests
  • Possibly custom C# Gherkin interfaces for the customer that would simplify some of the scenarios (e.g. Given I have an invoice no. 12345 where that would e.g. lookup an Id of an invoice from a specific invoice data table)

Another benefit of this is that the test scripts are also a living documentation of the system.

I see two ways how to implement this:

Selenium Tests

We could create interfaces for complete end-to-end visual tests using Selenium

Backend Tests

If creating Selenium tests would be too hard/complicated/slow it would be enough for testing the business logic to do it on the API level so basically just the backend would be invoked, not the browser.

So if I would say

Given I open a screen Screen1
we could just invoike InitUI on the backend controller.

And I add a record to Section1
would just invoke CreateObject

etc.