DSL for programmatic test plan generation#678
Merged
Conversation
|
Initially - thanks for the idea, this is really what the community needs. My opinion on current issues:
|
8e3ca1c to
ad6ade1
Compare
a73589a to
0257ffa
Compare
Collaborator
Author
|
I've added documentation, and a few more samples |
0853eae to
b9095f2
Compare
Collaborator
Author
|
I've added |
34e609f to
a97510c
Compare
A single instance for the schema is enough, so it would be better using abstract class so the users know they don't need instantiate it.
It produces a draft code, so it is easier to start using DSL by generating code from the UI.
It enables creating a subgroup and attach it to a schema or to another group.
…n interface Java's interfaces are bad since they have no declaration side type variance. Kotlin's ... -> Unit is hard to use in Java as it would require "return Unit.INSTANCE" Regular Kotlin's functions A->B are fine though.
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
… the most often used scenario This is a follow-up to apache#678
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
… the most often used scenario This is a follow-up to apache#678
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
…ckward compatibility Previously, TestElement.NAME and similar constants were coded as literals, and it was possible to use those references in annotation values. If the replace literals with method calls, then it would be impossible to use the fields in annotation values. So the static fields are reverted to literals. This partially reverts commits like apache#678,
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
…ckward compatibility Previously, TestElement.NAME and similar constants were coded as literals, and it was possible to use those references in annotation values. If the replace literals with method calls, then it would be impossible to use the fields in annotation values. So the static fields are reverted to literals. This partially reverts commits like apache#678,
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
…ckward compatibility Previously, TestElement.NAME and similar constants were coded as literals, and it was possible to use those references in annotation values. If the replace literals with method calls, then it would be impossible to use the fields in annotation values. So the static fields are reverted to literals. This partially reverts commits like apache#678,
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 15, 2023
…ckward compatibility Previously, TestElement.NAME and similar constants were coded as literals, and it was possible to use those references in annotation values. If the replace literals with method calls, then it would be impossible to use the fields in annotation values. So the static fields are reverted to literals. This partially reverts commits like apache#678,
vlsi
added a commit
that referenced
this pull request
Jun 15, 2023
…ckward compatibility Previously, TestElement.NAME and similar constants were coded as literals, and it was possible to use those references in annotation values. If the replace literals with method calls, then it would be impossible to use the fields in annotation values. So the static fields are reverted to literals. This partially reverts commits like #678,
vlsi
added a commit
to vlsi/jmeter
that referenced
this pull request
Jun 16, 2023
… the most often used scenario This is a follow-up to apache#678
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
See https://lists.apache.org/thread/52o722d7npsjj99m4k2zdz44mstl02lg
TODO
ListedHashTreeand other classes represent the tree? I incline we should create a separate set of classes to avoid leaking unwanted methods to the end-user. For instance, methods like#sample(),#interrupt()do not seem to make sense during test plan generation.no-resultfunctions?$be escaped? (see https://youtrack.jetbrains.com/issue/KT-2425, https://lists.apache.org/thread/717sm4k8kx6ojmkq0j1w0fhkv41bkm8d)ifandpauses, however, regular programming languages and DSLs do not require names for things likeif,for, etc. Of course, the transaction controller should have a name, but is the name required forhttpSampler?.children()or something like that API to access all the children elements of the currently built node?Motivation and Context
(in alphabetical order)
https://aliesbelik.github.io/awesome-jmeter/#dsl
https://github.com/abstracta/jmeter-java-dsl
https://github.com/anasoid/jmeter-as-code
https://github.com/smicyk/groovy-jmeter
anasoid/jmeter-as-code#133
https://github.com/Kotlin/kotlinx.html/wiki/Micro-templating-and-DSL-customizing
Screenshots (if appropriate):