jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: New feature : Readable overview of Test Plan
Date Tue, 22 Jan 2019 20:03:37 GMT

Am 22.01.19 um 20:36 schrieb Philippe Mouawad:
> Hello,
> Do you think this feature as of now (based on XSL) is worth being committed
> to core as alpha?

That depends on how alpha you think it is :)

Maybe include it, but disable it by default with a clear warning, that 
it is there for testing the usability?

>
> In terms of implementation, it relies on Saxon BasicTransformer as it
> supports xslt 2.0 functions.

Are the used functions comfort functions or necessary ones? (Just out of 
curiosity).

Felix

>
> Regards
>
> On Monday, January 21, 2019, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Am 21.01.19 um 20:56 schrieb Philippe Mouawad:
>>
>>> On Monday, January 21, 2019, Felix Schumacher <
>>> felix.schumacher@internetallee.de> wrote:
>>>
>>> Am 21.01.19 um 11:40 schrieb Philippe Mouawad:
>>>> Hello,
>>>>> This will better explain feature:
>>>>> Menu:
>>>>>
>>>>>       - http://ubikloadpack.com/demo/schematic/MenuSchematicView.png
>>>>>
>>>>> Plan:
>>>>>
>>>>>       - http://ubikloadpack.com/demo/schematic/testRequest.jmx
>>>>>
>>>>> Schematic View:
>>>>>
>>>>>       - http://ubikloadpack.com/demo/schematic/testRequest.html
>>>>>
>>>>> Where do the names "handle Cookies", "add Headers", "Virtual Users
>>>> executing", ... come from? How would extensions (plugins) fit into this?
>>>>
>>> It currently comes from the xsl file.
>>> There would be a default display using element name. For now plugins would
>>> have a very basic display.
>>>
>>> There would be a need to provide registration for implementations, I see
>>> how to do it for java implementation, but for XSLT, for now I don't.
>>>
>> Yes, I think the java implementation would have advantages over the
>> xsl-only version, especially with respect to extensibility.
>>
>>
>>> Working on this feature (within some consulting work, I was asked to
>>> document a plan to provide a textual description and ease understanding of
>>> errors (make other users find to what request an assertion was related)),
>>> I
>>> find that it makes the reading/understanding of a test plan more easy.
>>> I ran it on previous plans, and I see at least this major benefit.
>>> Another one (if we move forward) , would be to provide a more source
>>> version friendly representation of a JMX test plan.
>>>
>> Would this lead to something like Vladimir described? A textual
>> representation of the test plan, possibly with explanations for the
>> elements, that is diff and reader friendly.
>>
>> On the other hand, this reminds me of something. I sometimes dream of
>> having markers in the test plan tree, that could be used to show
>>
>>   * errors that happened during execution of a test plan (linked to/by
>> samples in result tree)
>>
>>   * common misconfigurations like double timers (scoping issues mostly) or
>> beanshell/javascript scripts :)
>>
>>   * samplers with long response times
>>
>>   * ...
>>
>> Felix
>>
>>
>>>
>>> Felix
>>>>
>>>> For now, it's html (I'm using XSLT), but a textual format like YAML would
>>>>> be better for source comparison.
>>>>>
>>>>> Regards
>>>>>
>>>>> On Mon, Jan 21, 2019 at 11:04 AM Vladimir Sitnikov <
>>>>> sitnikov.vladimir@gmail.com> wrote:
>>>>>
>>>>> Paulo Maia Borges> Why not export to standard HTML?
>>>>>
>>>>>> For instance, if jmx is stored in a Git repository (GitLab? GitHub?),
>>>>>> then
>>>>>> markdown would be much easier to review in diffs than HTML.
>>>>>> E.g. https://twitter.com/jamiebuilds/status/1085377471057412096
>>>>>>
>>>>>> In other words, it could make sense to render markdown representation
>>>>>> on
>>>>>> save.
>>>>>> However, it is not clear how tables should be rendered (e.g. HTTP
>>>>>> parameters).
>>>>>>
>>>>>> Vladimir
>>>>>>
>>>>>>
>>>>>>
>>>>> <https://www.openstreetmap.org/#map=18/50.69454/3.16455>
>>>>>
>>>>>
>>>>>

Mime
View raw message