>Well, maybe we see use cases, when we see the first implementation of >the generating function (`http`, `aggregateReport` in your example).
I've filed https://github.com/apache/jmeter/pull/678 to get something started. The relevant code is located in jmeterdsl.kt. The immediate question is "how do we represent in-flight nodes?". One of the ways is to stick with the current JMeter's jmeter.testelement.TestElement instances, however, the drawback is that those classes have weird APIs. For instance, ThreadGroup has setDelay(long), and it has no way to set delay based on a property. Samplers have .sample() method that does not seem to make sense in the context of test plan generation. HttpSampler exposes readResponse(...), .interrupt(), and so on. Then, the relationship between TestElements and their children is not that regular. For instance, ThreadGroup owns LoopController, however, that association is configured **only** in ThreadGroupGui#modifyTestElement method, so if you instantiate ThreadGroup directly, it won't work. On the other hand, if we go with creating dsl-only wrappers, it might increase the amount of boilerplate code required to add a new sampler: "sampler definition class", "GUI class", "properties file", "dsl wrapper", "dsl function". It does not sound that bad, however, I am not sure it is something we should be afraid of. Having a separate set of "test element classes" might be good as we could design it for test plan generation purposes, and we would not expose runtime-like methods unless they are needed. Vladimir
