{"id":150,"date":"2020-08-04T08:00:00","date_gmt":"2020-08-04T06:00:00","guid":{"rendered":"https:\/\/danilov.es\/?p=150"},"modified":"2025-03-13T11:33:37","modified_gmt":"2025-03-13T10:33:37","slug":"applied-bdd-and-performance-testing","status":"publish","type":"post","link":"https:\/\/danilov.es\/index.php\/2020\/08\/04\/applied-bdd-and-performance-testing\/","title":{"rendered":"Applied BDD and Performance Testing"},"content":{"rendered":"\n

In the previous article<\/strong><\/a> we were analyzing the benefits of designing a process where mixing BDD with Performance Testing would make total sense. As I like to believe, apart from generating wild ideas, I make them happen. Some long time ago the NightCodeLabs<\/strong><\/a> team was formed and we developed a solution to this challenge. <\/p>\n\n\n\n

We chose the Java ecosystem because the team was professionally using this programming language back when the project was started, and we were aiming to solve a need we might have had at some point in our day-to-day jobs. <\/p>\n\n\n\n

In this article you\u2019ll get a general overview on how the solution works and how you can actually reuse the existing BDD functional test code and write performance ones.<\/p>\n\n\n\n

Architecture<\/h2>\n\n\n\n

<\/p>\n\n\n\n

The Test Project<\/h4>\n\n\n\n

A java maven project containing BDD scenarios in Cucumber and a test automation framework of your choice (eg: rest-assured, Selenium, etc). This is where the Performance Tests will live. <\/p>\n\n\n\n

Pretzel<\/h4>\n\n\n\n

The test framework we\u2019ll use in order to make our lives easier while attempting to do load and performance testing with BDD. Pretzel<\/strong><\/a> starts and terminates both the worker and master instances between each test, to allow the rest of the communication to happen and to be able to get individual results for each of the scenarios. Apart from that, the rest of the communication is done just with the worker: it sends out the information on what needs to be tested, it checks the status of the execution and once the execution is finished, it reads the results from the generated .csv file. Once this is done, the instances are terminated, and the cycle is repeated if new scenarios are to be executed.  <\/p>\n\n\n\n

Master<\/h4>\n\n\n\n

This is where all the magic is happening. The whole solution uses Locust<\/strong><\/a> to generate multiple users, to control how many of them are active per second, etc. Locust originally is a python based load testing tool, which happily allows to build clients in different programming languages so anyone can use it in their own technological ecosystem. There are different clients already out there for languages such as go or java. If you don’t find one, you could build your own. <\/p>\n\n\n\n

Even though the project itself and the code doesn\u2019t need to have anything related to python, in order for the whole solution to work, you\u2019ll still need to have python installed in the machine you\u2019ll be executing, together with a version of locust.<\/p>\n\n\n\n

Worker<\/h4>\n\n\n\n

This is the client which interacts with the master instance in order to translate the java code into something which locust can understand. The worker featured in Pretzel is locust4j<\/strong><\/a>, which is doing a super great job as a client in a simple project setup, but has it\u2019s challenges in integrating in slightly more complex architectures that include BDD with Service\/Page Objects. At NightCodeLabs<\/strong><\/a> we were trying to have it integrated by default in the Test Project, but we turned out with a lot of code which is now Pretzel. Finally, locust4j lives as a dependency in Pretzel. <\/p>\n\n\n\n

Your first Performance Test with BDD<\/h2>\n\n\n\n

Notes<\/strong>: The paragraphs to follow is based on the example project<\/strong><\/a> we’ve build at NightCodeLabs. Both the repo and the below guide are meant to show how this can work, rather to demonstrate a perfect BDD example or testing patterns. Before starting, make sure you go through the installation guide<\/strong><\/a>. Grab a beer or a coffee, as installing locust for the first time might take a while. Or avoid all of that and just launch the docker container. <\/p>\n\n\n\n

About the system in test <\/h4>\n\n\n\n

For this example we have chosen to do some API testing, based on this simple and public API<\/a><\/strong>. This is their documentation: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We already have the following functional test case, which we’d like to reuse into a Performance one:<\/p>\n\n\n\n

Feature: Functional Test\n\n  @Functional\n  Scenario: Request a Forced yes Answer\n    When a forced yes is requested\n    Then the corresponding yes answer is returned\n<\/code><\/pre>\n\n\n\n
This feature file sits in a project with the following folder structure:<\/p>\n\n\n\n
-- \/src\/main\/java\n     \/serviceobjects\/ForcedAnswer.java\n-- \/test\/java\n     \/runner\/TestRunner.java\n     \/steps\/Definitions.java\n-- \/test\/resources\n     \/Functional.feature\n-- pom.xml\n<\/code><\/pre>\n\n\n\n
Behind the Functional Test, we have the following code:<\/p>\n\n\n\n
package steps;\nimport cucumber.api.java.en.Then;\nimport cucumber.api.java.en.When;\nimport serviceobjects.ForcedAnswer;\n\npublic class Definitions {\n\n\tForcedAnswer forcedAnswer = new ForcedAnswer();\n\t\n\t@When(\"^a forced (.+) is requested$\")\n\tpublic void aForcedAnswerTypeIsRequested(String answerType) {\n\t\tforcedAnswer.aForcedAnswerTypeIsRequested(answerType);\n\t}\n\n\t@Then(\"^the corresponding (.+) answer is returned$\")\n\tpublic void theCorrespondingAnswerTypeIsReturned(String answerType) {\n        forcedAnswer.theCorrespondingAnswerTypeIsReturned(answerType);\n\t}\n}<\/code><\/pre>\n\n\n\n
The Service Object class which holds all the methods for forcing an answer inside the API is using the RestAssured testing library. You can use whatever you like here, including UI Testing.<\/p>\n\n\n\n
package serviceobjects;\n\nimport io.restassured.RestAssured;\nimport io.restassured.http.Method;\nimport io.restassured.path.json.JsonPath;\nimport io.restassured.response.Response;\nimport io.restassured.specification.RequestSpecification;\nimport org.junit.Assert;\n\npublic class ForcedAnswer {\n\n    public ForcedAnswer() {}\n    private String requestAnswer;\n\n    public void aForcedAnswerTypeIsRequested(String answerType) {\n        RestAssured.baseURI = \"https:\/\/yesno.wtf\/api\";\n        RequestSpecification httpRequest = RestAssured.given();\n        Response response = httpRequest.request(Method.GET, \"\/?force=\" + answerType);\n        JsonPath answer = response.getBody().jsonPath();\n        System.out.println(answer.prettyPrint());\n        requestAnswer = answer.getString(\"answer\");\n    }\n\n    public void theCorrespondingAnswerTypeIsReturned(String answerType) {\n        Assert.assertEquals(\"Correct answer returned\", answerType , requestAnswer);\n\n    }\n}<\/code><\/pre>\n\n\n\n
Adding the Performance Test<\/h4>\n\n\n\n
First of all, add the pretzel dependency to your maven project:<\/p>\n\n\n\n
\t<dependency>\n    \t   <groupId>com.github.nightcodelabs<\/groupId>\n    \t   <artifactId>pretzel<\/artifactId>\n    \t   <version>0.0.2<\/version>\n\t<\/dependency><\/code><\/pre>\n\n\n\n
Let’s add the BDD Magic to Performance Testing:<\/p>\n\n\n\n
Feature: Performance Test\n\n  @Performance\n  Scenario: Request a forced yes answer\n    When 100 users request a forced yes at 10 users\/second for 1 min\n    Then the answer is returned within 10000 milliseconds<\/code><\/pre>\n\n\n\n
Looks cool, right? Let’s update our existing step definitions. To make it work, we’ll need to:<\/p>\n\n\n\n