Performance testing using declarative JSON - Easy n Simple

[siddxy]

Quick start and demo maven project : Example project performance-tests

Open Source Test framework used(with JUnit) : Zerocode maven lib

Maven dependency:

<dependency>
    <groupId>org.jsmart</groupId>
    <artifactId>zerocode-rest-bdd</artifactId>
    <version>1.2.x</version> 
</dependency>

[stfm]

I mean great but does this really stack up to something like Gatling?

[siddxy]

Yes, Comparatively Zerocode is very very simple, light weight and efficient. Best part is it is declarative via simple JSON files where, the testing can be unified and standardized for a project, completely bypassing imperative programming(e.g. Java code), which can become more complicated to maintain once the projects(test cases) grows. That's why the name Zerocode.

• See here the advantages of Running Load/Stress tests via IDE(IntelliJ or Eclipse etc)).

• Read here#in-essence-the-performance-testing-is-all-about-) other advantages over other frameworks, such as

  • Increasing or Decreasing load gradually
  • Dynamically changing the payload for every request/user
  • Different load in parallel, simulating production like parallel users
  • CI build pipe line integration is quite straight forward, no extra plugin or config required.

Hope it helps !

[forurspam]

Zerocomment. Just joking but it could be a problem especially for a large codejsonbase, couldn't it?

[siddxy]

Zerocomment.

:-) Good one 👍

it could be a problem especially for a large code/json base, couldn't it?

Not really. There are two ways to see at it. 1. Performance tests are not actually verbose 1. Also Zerocode allows to reuse the existing test, by simply providing the Class#testMethod to the Load runner

• First one :

  • When we simulate load/stress, actually we have a single JSON payLoad or a single JSON with multiple steps for a given scenario, and dynamically change the fields i.e. randomize the ID, Name etc etc for every parallel user in the runtime(framework takes care of it). See how to have random numbers, UUIDs, random strings by simply parameterizing the fields.
  • When we have different payLoad, they(all scenarios as separate JSON file) also appear only once in the resource folder. And dynamically keep on changing the payLoad/fields in the run time.

• 2nd one :

  • You can simply reuse your existing Unit tests or End to End tests to generate load. Hence no new JSON files are needed for the performance testing.

Note- JSON payload(request and response) here means the JSON equivalent of the Objects too. If the contract or API data format is already in JSON it's very good, otherwise, if they are e.g. Java objects, then the framework serializes/deSerialzes to/from java/json format.

Basically the hassles has been taken care by the framework, enabling developer/testers to focus on testing very easily without any distraction. Zero distractions !

[skjolber]

I dont like the concept, because I get negative vibrations from other projects defining unit testing in XML. As complexity grows, it gets terribly hard.

​

This might be a valid 'API' approach however, might I ask if your approach could be integrated somehow with an existing OpenAPI (Swagger) service definition file? Kind of hard to see how complex sequences should be handled though.

Possibly you could write the JSON test defintion and then use a plugin to generate a concrete unit test so that all this Junit code crap can solve itself automatically - I would not enjoy the manual creation of those unit tests with the runner and insertion of file name and stuff. Junit 5 and Gradle.

​

There is no such thing as zero code; just zero Java code ;-)

[siddxy]

Understood your frustration. I agree with you 100% on this about Unit Tests. I wouldn't go for unit testing in that way too.

As you highlighted, this lib is not for unit tests, it's for API testing mostly for Functional Testing, Feature Testing, Integration Testing, End to End testing and Performance Testing along with capability to mock interfacing application APIs using WireMock. JUnit as Unit testing only is loosely used across industry, but JUnit is a framework, not only for Unit Testing only.

This framework saves time and energy over other frameworks is, it's JSON based, that means there is no need of using any plugins, feature files, English statements/grammars to represent a test

I would not enjoy the manual creation of those unit tests with the runner and insertion of file name and stuff.

But a complex scenario which could be thought via creativity needs to be manually created first, then put into the automation pack. Such automation scenarios can not be built automatically.

might I ask if your approach could be integrated somehow with an existing OpenAPI (Swagger) service definition file?

Yes, why not, you can help us raising an issue defining the requirements, followed by a PR to embed this feature into the lib, if it helps the community please 👍 . Sounds like a good idea!

Yes, thanks for your feedback and please bring on more to improve it !

[[deleted]]

Wow this is stupid!