Performance Testing

If development is the core of any project performance-testing  is the essence of the project

The need for  performance testing  and the procedure to perform it easily, accurately using simple JUnit and maven based Open Source Library. What problems we face typically during the load and stress testing of an application and how we can overcome these issues and make the performance-testing part of the CI build pipeline.
Sometimes we tend to think that the performance-testing   is not part of the development process. This means the important aspect of a product or service APIs is not not taken care of. But that's not the point, the point is why do we think that it should not be part of the usual development cycle ? 
Solution
@LoadWith("your_load_config.properties")
@TestMapping(testClass = YourExistingEndPointTest.class, testMethod = "aTest")
@RunWith(YourLoadRunner.class)
public class LoadTest { }
number.of.parallel.users=50
users.to.be.ramped.up.in.seconds=50
repeat.this.loop.times=2
where you want 50 users  to be ramped up in 50 seconds  (each user firing tests in 1 sec gap) and this to be run twice(loop=2) i.e. total 100 parallel users will fire requests each approximately in 1 second gap.
@TestMapping(testClass = YourExistingEndPointTest.class, testMethod = "aTest")
required assertions to match the actual result received vs expected result.

Total number of tests fired	100
Total number of tests passed	90
Total number of tests failed	10
Average delay between requests(in sec)	1
Average response time delay(in sec)	5

Also to add more ground to the above thinking, there are no straight forward approaches to do performance testing like we do unit testing or feature / component testing or e2e integration testing or consumer- contract testing. Then the developers or the performance-testers(sometimes a specialized team) are asked to choose a standalone tool from the market place and produce some fancy reports on performance testing , share those reports with business or technology team.

That means it is done in isolation and sometimes after or towards the end of the development sprints, approaching the production release date. The importance of this testing is missed out to provide the room for improvement or fixing of the potential issues in the product. This answers the first question "why".

Ideally to make it part of the usual development cycle,

And to make it part of the CI build, it has to be easy enough to write/change/share the tests for developers or the performance-testers.

The point is how do we get an useful statistics easily understandable by the developers or, how to fix the issues arise from load/stress/capacity testing or,how do we get a continous feedback from the CI build ?

In the traditional approach, too much time is spent understanding the tool and making the tool work due to some are not IDE friendly i.e. not even maven/J Unit based for that matter.

Some challenges like pointing your  performance-testing tool to anywhere in the tech-stack is not an easy or straight forward task e.g. pointing to a REST end point, SOAP end point, DB Server or KAFKA topics or a MQ end point like ActiveMQ/WMQ, SSL connections, connection via Corporate Proxy etc.

This makes it bit difficult to isolate the issues that your application APIs are performing very well and only the downstream systems have the issues. Let's explain what it means-

e.g.

You just tested your GET API's performance, pointing to the url e.g./api/v1/id-checks/131001  using the standalone tool and found that the response delay is more, than invoking the same API for a single time. Then you(as a developer) tend to blame it on the DB or the MQ topics e.g. giving a reason that Oracle DB server is pretty slow while handling the parallel loads. But how do you produce the evidences to support your argument that your APIs are not slow?

Now, you wish you could have a mechanism or tool to isolate this issue from your application, by pointing your performance-test tool directly to the DB or KAFKA-Topics etc, because (as a developer) you know -- which SQL queries are fired to the DB to fetch the result or you know the topic names from which you can directly fetch the data bypassing the application API processing layer, which could prove your point meaningfully as well as produce evidences.

To achieve these steps should be actually very easy as you already have your existing Junit tests, integration-tests etc  doing the same stuff, on daily basis (actually every CI build is doing this). But it is sometimes difficult to do this using a standalone or market-place performance tool

And/Or it is not flexible enough to feed these existing tests to the tool(s) you have choosen. So you loose interest or didn't have much time to spike it in the sprint, and then, you skip this aspect of testing, passing the blame to the downstream systems or to the tool.

Custom JUnit load runner  which can easily enable you to reuse your existing  Junit tests  (e2e integration tests or feature tests or component tests, as most of them use JUnit or TestNG behind the scene) to generate load or stress(Read here the difference between load vs stress aka horizonal load vs vertical load).

The load runner ideally should look like below which could solve the purpose-

where  your_load_config.properties  should hold the below properties-

and  @TestMapping means-

Your  aTest  method of   YourExistingEndPointTest above should have the

Once the load run gets completed, you probably would need a statistics precisely like below-

and ideally much more statistics could be drawn on demand, provided your YourLoadRunner could produce a CSV/SpreadSheet with below kind of data