March 15 08:57~11:00; 20:02~08:19
▲Use ezSpec to write the instruction file of ezSpec
foreword
The previous episode < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (1): Domain Model Introduction > mentioned that Feature is the largest unit used by Gherkin to describe requirements. Today we will introduce how to write Feature in ezSpec.
Before introducing and writing Feature, first explain the two terms External DSL (external domain-specific language) and Internal DSL (internal domain-specific language) . Villagers who use tools such as Cucumber, SpecFlow, or Cucumber-JVM write the Feature in the feature file, and then hand it over to the tool to generate the Step Definition, and then write the Step Definition to achieve the purpose of acceptance test automation. Gherkin is a DSL (Domain-Specific Language) used to describe requirements or specifications. Teddy, the practice of Cucumber series tools, calls it External DSL because the language used to describe requirements (that is, Gherkin) and development The programming language used (Ruby, C# or Java) is different, so Gherkin becomes an “external domain specific language”.
The advantages and disadvantages of External DSL Teddy mentioned in < Painless writing acceptance test files in test cases > and < Using ezSpec to implement behavior-driven development and instantiation requirements (1): Introduction to domain models >, interested villagers can refer to . ezSpec is an Internal DSL that uses the Java language to simulate Gherkin. In other words, the DSL used to describe requirements or specifications is consistent with the programming language used by developers.
***
Write your first Feature
In addition to using the Internal DSL method to develop ezSpec, it is also combined with JUnit 5. Writing a Feature file is the same as writing a Test Class in the traditional way. Please refer to line 8 in Figure 1, FeatureSpec is a general Java Class, the name can be chosen freely, you can also call it FeatureTest or any name you like.
FeatureSpec implements ezSpec interface , so that ezSpec can automatically generate reports. If you only need to view the reports generated by JUnit in the IDE, you don’t need to implement this interface.
Declare a static Feature feature object on line 9 to represent a feature file. Please note that if you want ezSpec to automatically generate reports, the variable name of this static Feature must be named feature, otherwise the system cannot automatically generate reports. Then lines 11 to 21 use the @BeforeAll annotation of the JUnit 5 standard to define the content of the feature. Feature.New() on line 13 produces a new Feature object that accepts two parameters:
- Name : The name of Feature, used to represent a function or group of functions delivered to users.
- Description : The detailed content description of the Feature. In addition to further explaining the content of the Feature, it can also be used to define the vocabulary used by the Feature. These vocabulary can become part of the ubiquitous language .
▲Figure 1: Example of ezSpec Feature usage
After defining the feature, you can directly write a test method to execute it and verify the content of the feature. Please refer to lines 24 to 40. This test method simply verifies whether the content of the feature is correct. The report generated by it is shown in Figure 2.
▲Figure 2: Example of Feature report generated by ezSpec
***
story
The Feature object of ezSpec itself is just a “container”, and the actual requirement content is written in the Scenario. Between Feature and Scenario, ezSpec also supports Story. A Feature needs to contain at least one Story, and a Scenario is attached to a certain Story.
Please refer to Figure 3, line 16 calls feature.newStory to add a new Story, which has the same Name and Description fields as Feature, and its purpose is similar. In addition, Story also has an Index field, which can assign a number to it, and then use this number to read the Story.
Basically, a Story is a small Feature. If you don’t need a Story to manage smaller functions, when writing a Feature, you only need to write a Story for each Feature, and then the Story will generate all the scenarios.
▲Figure 3: Example of using Story in ezSpec
▲Figure 4: Story report generated by ezSpec (excluding internal Scenario, Scenario Outline and Background)
After adding a Story, you can call feature.withStory to get the story belonging to the feature, and then generate a Scenario through its newScenario. The next episode will show how to use Scenario and Given-Then-Then to write requirements examples.
***
Youzo’s inner monologue: Warm up before exercising.
This article is transferred from https://teddy-chen-tw.blogspot.com/2023/03/ezspec2featurestory.html
This site is only for collection, and the copyright belongs to the original author.