March 21 18:06~19:30
▲One Test Method, N green lights
foreword
The previous episode introduced four ways to write Scenario Outline in ezSpec (please refer to < Using ezSpec to Implement Behavior-Driven Development and Instantiation Requirements (5): Four Ways to Write Scenario Outline >), the Examples used are relatively simple single form. This episode introduces how to express these Examples when the Examples of Scenario Outline are more complicated.
***
ArgumentsProvider for JUnit 5
Before explaining how to express complex Examples, two basic interfaces/categories are introduced: ArgumentsProvider and Junit5Examples.
JUnit 5’s @ParameterizedTest originally supported several ways to provide test data. The last episode used the simplest @CsvSource, and this episode uses ArgumentsProvider to provide test data. Referring to Figure 1, ArgumentsProvider is an interface with only one provideArguments method, which returns Stream<? extends Arguments>.
Arguments is also an interface, refer to Figure 2, it has a get mehtod, returns Object array, this is where the parameters are stored.
▲Figure 1: ArgumentsProvider interface of JUnit 5
▲Figure 2: Arguments interface of JUnit 5
***
ezSpec’s Junit5Examples
ArgumentsProvider is the interface used by @ParameterizedTest designed by JUnit 5. The parameters accepted by ezSpec’s Scenario Outline are Examples, and the two interfaces are different. Therefore, Teddy designed a Junit5Examples abstract class, through which the Examples of ezSpec and ArgumentsProvider of JUnit 5 can be converted, as shown in Figure 3.
▲Figure 3: Junit5Examples abstract category of ezSpec
***
Scenario Outline of RenameWorkflow Use Case
Referring to Figure 4, suppose you want to help specify the RenameWorkflow use case of ezKanban, and you think of two main scenarios:
- Scenario 1: The new name is different from the old one, and a domain event will be generated after executing the RenameWorkflow use case.
- Scenario 2: The new name is the same as the old name, and no domain events will be generated after the RenameWorkflow use case is executed.
For these two scenarios, you find a total of five different test data, such as changing the name of the Workflow from dev to dev, from dev to DEV, or from dev to dev.
▲Figure 4: Rename a workflow example
How to express the Scenario Outline in Figure 4 with ezSpec? First define the test data, please refer to Figure 5 and Figure 6.
▲Figure 5: Test data (Examples) with different Workflow names
▲Figure 6: Test data (Examples) with the same Workflow name
Once the Examples are ready, they can be used in the Scenario Outline. Referring to Figure 7, use the method 1 introduced in the previous episode to write the Scenario Outline, the only difference is line 61:
WithExamples( Junit5Examples.get(different_name_examples.class),
Junit5Examples.get(same_name_examples.class))
Directly specify the class name of Examples to obtain test data.
▲Figure 7: Use the specific category of Junit5Examples as a source of test data to provide to ezSpec
In addition, different_name_examples and same_name_examples can also be used as the data source of @ParameterizedTest to execute Scenario Outline, please refer to Figure 8.
▲Figure 8: Use the specific category of Junit5Examples as a source of test data for @ParameterizedTest
***
More complex test profiles: tables within tables
Please refer to Figure 9, which is the acceptance test data provided to ezKanban’s MoveLane use case, where givenWorkflow represents the Workflow state initialized in the Given stage, and expectedSubStageAsRootStage represents the Workflow state after moving the Lane.
▲Figure 9: Examples include examples of tables
The Scenario Outline of MoveLane is shown in Figure 10. It can be seen that the <given_workflow> parameter is specified on line 89 (the givenWorkflow table in Figure 9), and the <expected_workflow> parameter is specified on line 123 (the expectedSubStageAsRootStage table in Figure 9).
▲Figure 10: Example of MoveLane Scenario Outline
The execution result of Figure 10 is shown in Figure 11. It can be seen that the 22nd is the outermost Example table, and the two internal columns of given_workflow and expected_workflow are another table. You can easily design complex acceptance test data through ezSpec, and it is also very simple to use.
▲Figure 11: MoveLane Scenario Outline Execution Result Report (only part is displayed)
***
epilogue
Through ezSpec’s Junit5Examples, you can design the acceptance test data used by ezSpec and JUnit 5’s ParameterizedTest at the same time. Each test data is independently defined in a Junit5Examples category, which is easy to manage and write.
At this point, the commonly used ezSpec functions have been introduced. The next episode introduces Background, which can be used to write the same Given together to facilitate reuse and reduce duplicate code.
***
You Zang’s inner monologue: The Table within the Table is still the Table.
This article is transferred from https://teddy-chen-tw.blogspot.com/2023/03/ezspec6scenario-outline.html
This site is only for collection, and the copyright belongs to the original author.