Considering dropping txt simulation file format in 1.1.0 : feedback wanted

Hi,

Gatling 1.0.x supports 2 simulation file formats : txt and scala.

When we started developing Gatling, we thought that those two
mechanisms could be implemented in quite a similar fashion. In the
end, they're not, and it's a real hassle.

One big difference is the way of handling modularization :
* in scala mode, you use proper imports
* in txt mode, you use the "include" keywork, which is used for copy/
pasting the included file

This "include" mechanism is actually quite a pain to develop and can
be the source of numerous bugs :
* included parts can't include other parts
* as it actually performs a copy/paste under the hood, conflicts can
appear if there's the same variable in two different parts

As a consequence, I'm considering removing the txt format.

With the proper documentation and support, I think that people should
be able to manage with the scala format, which is basically the same
than the txt format (just with the proper package, imports and class
declaration). I just hope that it wouldn't shy them away.

Any feedback welcome.

Cheers,

Stéphane

Works for me. I would always want to use .scala to get the IDE
support anyway, and surely a few extra lines in the file is a small
price to pay for the extra clarity?

IMHO, this will be a problem if we want to address QA people.

They are not all developers and even if for us it a small price to pay as you said Dave, I think that people might be disoriented with packages, imports, classes, objects…

The txt mode is important for all those people who don’t want to develop but test an application.

This raises the question about the persons we want to use Gatling: “developers & QA & more”, “dev & QA” or just “devs”?

If the answer to the latter is “devs” then no problem, if not, I think we might really think about the implications of forcing people to use classes/objects to create simulations.

The DSL was made to allow non-developers create simulations for Gatling, I think we might lose that aspect if we remove txt mode.

Cheers,
BluePyth

Well, regarding what to expect from QA people, I’d like to hear it from them.
I think it’s a common bias dev people have on QA people. If they can handle Selenium, they can handle those scala files, as long as they have the proper documentation, samples and tutorials, don’t you think?

2012/2/16 Romain Sertelon <bluepyth@gmail.com>

I don’t say they are not able to manage, I’m saying that it will imply efforts and it could lower the acceptance of Gatling in companies.

I’ll tweet the question to see if we can get more feedback :wink:

Hi !
I don’t think there’s such a huge gap between the two types of files.
Dropping .txt support seems ok for me.
Hugo

I definitely think it would be a good idea to drop the .txt format.
I've seen this kind of thing in SBT and other tools where there are
two formats thinking that a Scala-esc DSL is going to be simpler than
actual Scala code. What really happens is that the DSL gets more and
more complicated until it's just its own language that you have to
learn except there are no resources to use because it's just some
random DSL. Not only that but now you have to include 2 examples for
everything showing a Scala way and a pretty-close-but-not-quite Scala
way. I think in general it would be better just to focus on one
format. In the case of Gatling I find the Scala tests really easy to
implement and I quite like that I can use Traits etc to make the tests
more readable.

I questions whether there's anyone, QA or otherwise, who would really
find the text format any easier to handle than the Scala one. In my
experience anyone who is developing load tests is by definition a
fairly technical person. If they can write integration tests using
some spec DSL then they can manage Gatling tests. Depending on the
use case the recorder can do 90% of the work.

I just don't really see a use case where a completely non-technical
person would be working on load tests. And even if that were true I
don't think a contrived Scala-esque txt format really simplifies
things. But honestly I've never seen anyone but developers or 'qa
developers' writing load tests whether it's JMeter or ab or whatever
but that's just my anecdotal experience.

Selfishly as someone who only uses the Scala format I would rather the
team focus on that area. Especially if the txt format complicates
implementation which it sounds like it does.

Chris

Hi,

Stéphane and I discussed the “problem” and it’s clear that focusing only on the Scala mode will not penalize anyone, on the contrary, as you stated it Chris.

We will drop txt mode in 1.1 :slight_smile:

I’ll have a lot to do on the documentation :stuck_out_tongue:

Cheers,
BluePyth

See issue https://github.com/excilys/gatling/issues/418

I will probably push something on this by the end of the day.

Cheers,

Steph

2012/2/17 Romain Sertelon <bluepyth@gmail.com>

Hi

From the QA respective, both the scala and txt format are OK but is there any meanful test case naming function available? Use created date as the init name for the recorded scirpts is a little hard for me to maintain when I have a bunch of them.

Regards

Vance

Oh, I found similar issues here, sorry for the repeatable question :slight_smile:

在 2012年2月27日星期一UTC+8下午11时44分32秒,Vance Zhao写道:

That’s exactly what I’m currently working on.
Expect something in the master by tomorrow.

Cheers,

Steph

2012/2/27 Vance Zhao <vancezhao@gmail.com>