Creating automated tests for the Lunch Catering Process
While still developing version 1.0 of your bundles, it is important to identify the important user stories to test. Furthermore, you should write automated tests for these cases so that others can execute the tests you wrote, and in fact you can deliver your test suite along with the packaged bundle. Luckily, the BMC Helix Platform SDK includes an automation framework designed for exactly this purpose. It can be used to test your application logic: services, and use of framework services (including any Rule or Business Process that you have created).
This framework is documented as part of the SDK documentation in Testing application logic with the automation framework. It itself based on another framework called JGiven which you can read about here . You should also check out the sample automation code provided with the sample Task Manager application.
As the documentation describes, with JGiven, each test includes a Given state (the precondition of the test), and at least one When state (the input for the test case), and Then state (the assertions of expected behavior). It may even have multiple pairs of When and Then to follow a long running execution, for example, of an asynchronous business process with multiple blocking operations. Using method names that read as English helps to make the test use case easily understandable; adding parameters in the right places makes it easy to re-use these methods for slightly different use cases. Also, by avoiding return values in these methods (which may require the use of injected variables as is explained in the documentation), we essentially turn Java into a kind of scripting language for describing and executing tests. The Then state methods will typically contain the Assert statements that will compare expected and actual results and issue the errors at runtime (and stop that particular test).
Let's consider the pseudo-code for a test that verifies one use case for the Order Lifecycle process we created in Module 2. In terms of code, your tests will be methods of MealOrderTest that extends the framework's BaseTest class. The methods for each phase live in the respective class for that test state, such as MealOrderGivenState, MealOrderWhenState, and MealOrderThenState. Let's consider a method of MealOrderTest called testNormalOrderAutoClosed() and how the use case is functionally described. Note that UI behavior is simulated by methods that use the REST API with the server.
Taking each state we can turn the "English" explanation into pseudo code. By the way, this could be used as a template for designing your test code at a high level before starting to implement it.
Use Case: Normal Auto-Closed | Pseudocode |
---|---|
Given that... | given() |
A non-admin user logs in. | .login_non_admin(); |
When... | when() |
The order status becomes "In Progress"... | .the_meal_order_status_changed_to_$("In Progress") |
and waits for a few minutes to give the process a change to resume... | .and().wait_$(2); |
Then we expect... | then() |
Notification was sent | .expect_notification("in progress); |
When... | when() |
The order status becomes "Delivered"... | .the_meal_order_status_changed_to_$("Delivered") |
and waits for a few minutes to give the process a change to resume... | .and().wait_$(2); |
Then we expect... | then() |
Notifications are sent to submitter | .expect_notification("delivered") |
Notifications are sent to consumer | .and().expect_consumer_notifications("delivered") |
Delivery date and time is within 10 minutes of submission time | .and().expect_delivery_time_within_ten_minutes() |
We would then need to implement the following methods in the respective classes. Note that including a _$ in the method name automatically causes the first parameter to be echoed as part of the test output.
Note that when one method needs to share information with another (such as the work order id in this case), this member variable can be injected automatically into methods, rather than using static variables.
@ProvidedScenarioState(resolution = Resolution.NAME)
String mealOrderId;
Also, to help with the REST-based communication with the server, a helper class can be extended from the BMC Helix Platform framework's RecordInstance class in order to work more easily with the REST calls that the automation framework needs to make to simulate user interaction.
We can imagine creating other tests to handle different use cases with the Work Management application created in this tutorial. Note that it is perfectly appropriate to include negative cases to test error handling.
- testtMealOrderCancelBeforeDelivery()
- testtMealOrderCancelAfterDelivery()
- . . .and so on.
The number and depth of the tests should be clear enough by examining the overall test method code, and the output, so that someone other than the developer can have some confidence that the tests are meaningful.
Eventually when you package the application zip, it will include your automation test jar that others can run against your deployed application.
Comments
Log in or register to comment.