After identifying the prototype desired features, we needed to analyze how we would implement those, the pros and cons of each alternative, and immediately came up with 2 prototype options:
• Alternative 1: Start from the existing BDDFramework and build a new compo- nent around it. It will use the features already provided by theBDDFramework,
such as the Gherkin scenario templates and all the blocks for the description and implementation of BDD steps, as well as theBDDFramework AssertSteps library and
information about test execution. With this alternative we would still be in the Low Code OutSystems domain and would have already implemented the basis for the description of scenarios as it already exists in the BDDFramework. The challenge
here would be more focused on automating the screen test logic generation (step definitions), as well as reusing actions, all from feature textual files. The strengths of this alternative would be: the previously mentioned fact that we remain in the Low Code domain, without having to leave it to perform BDD testing. This can be a crucial aspect, as it would allow developers to stay in the development environment (the test specification and implementation would be very close to the code under test) and we would use the already knownBDDFramework that would be leveraged
by the component but will continue to exist on its own, just like before. It would not be replaced. The learning curve would therefore be supposedly shorter for devel- opers who already know OutSystems and theBDDFramework and also by allowing
scenarios to be described in text files that automatically populate the scenario tem- plates (before we had to drag the steps, type in the descriptions and place the blocks in their corresponding placeholder within Service Studio). This would significantly simplify the entire process. Anyone can easily use a simple text file, including business people, who previously had to install Service Studio to participate in the scenario description process. Moreover this tool would be unique and developed specifically for the language. We can find a schema that represents this solution in figure4.16and the test eSpace generated general structure and organization inside Service Studio in figure4.17.
4 . 4 . P R O T O T Y P E A LT E R N AT I V E S
Figure 4.16: Automated generation of the test logic and filling of the BDDFramework scenarios and steps process, from the external feature files by the prototype component.
Figure 4.17:eSpace organization inside Service Studio.
• Alternative 2: Integrate SpecFlow with OutSystems. The idea is to take advantage of an already developed engine and apply it to perform BDD tests. This approach involves the development of a component that enables the integration between scenarios interpreted by SpecFlow and their implementation in OutSystems logic. SpecFlow engine already supports the automated generation of test classes and step definitions for the corresponding feature files and scenarios, respectively. It also supports the parameterization of inputs with type inference as well as various mechanisms of step aggregation and data manipulation for testing. SpecFlow also supports step reuse for equal steps and it supports integration with other tools (al- though like in Alternative 1 we will need it anyway for an OutSystems domain). It also can be executed from the terminal without any IDE to generate the step definitions and return the test results (with thegenerateall3command).To do this,
3Thegenerateall command can be used to re-generate outdated unit test classes based on out feature files.
This can be useful when upgrading to a newer SpecFlow version, or if feature files are modified outside of
the idea would be to have SpecFlow C# classes invoking actions of an OutSystems eSpace directly (in runtime). The SpecFlow C# code would just be wrappers for actions to be invoked in an eSpace, thus the step implementation would be done in OutSystems code. To achieve this, we need to built: (1) a code generation mech- anism (close to Alternative 1) just to create an eSpace with Server Actions where the step implementation would be done; (2) a C# library that would allow us to easily call the eSpace server actions in runtime; (3) a code generation application that would populate the SpecFlow generated C# classes (with the step implemen- tations) with the appropriate calls to the library in item 2. In short, the idea would be to take advantage of the SpecFlow features as they are, to be able to generate the OutSystems project with the test code. The main advantage of this approach is that the main engine is already built and quite complete with lots of features, but also the fact that the SpecFlow community is large, and it allows integration with other tools as well as command line execution. We would have found to be a way of generating output between SpecFlow, that deals with the feature files and scenarios, and Service Studio, where the test code is implemented. The main challenges would be: beyond the crossover between both platforms, the already mentioned code gen- eration mechanism (which we have already found applicable in this context) to insert code invokers to OutSystems actions in the generated .cs files with the step definitions and a library to handle those files with the inserted parameters and in- voker functions to allow the automated generation of eSpaces, screens, actions and parameters in an OutSystems domain. Finally, a way to generate the test outputs across platforms. Figure4.18represents this approach.
Figure 4.18: Schema that represents Hypothesis 2.