Hi
Christian,
As you already know
J
I’m strongly advocating the fact to
remove all generated code from the repository
The generated code should always be
up to date with the model and not mixed with
some handcoded code.
BUT the generated test is here to
check any regression
Obviously if your generated tests
are up to date with your model your tests should
always pass
ð
That’s why the generation of the
tests should be done
manually (still bind to the build tool J )
For example :
- I made a very simple generator to
generate a junit test class for element type (I
hope to share it when the work is done)
(My main concern is to avoid any id
regression since ids can be specialized (so are
part of our api
J) )
- Let’s say that we get the last
official version for SysML 1.4, I will generate
the new elementtype file
- if the tests are generated at
runtime then they will use the new ids as input
and pass
- if the tests are manually
generated, they will failed on a regression (I
will have to
manually call the build tool for updating
them or patch my regression )
ð
That’s why generated test should
not be managed exactly like generated code (It
may have some exception)
About the “versionstamp”, it is
just a way to know the version of the tool that
generated the code
By experience there are some times
when you can’t regenerate the files
but much much worse you also don’t
know what version or even tool that was used.
ð
The best way would be to use a
file without semantic meaning (my recommendation
use package-info.java)
Regards,
Benoit
Thanks for the follow-up.
See some more responses to both of your
replies, in-line below.
On Wednesday, Apr 8, 2015 at
05:11, CADAVID Juan <juan.cadavid@xxxxxx>,
wrote:
Hi
Christian, Benoit,
Thanks
for updating the contribution. I’m having a
hard time finding time to work on the test
generator, but I see you were able to start
extending the transformations, and I will
follow up and your suggested changes.
I certainly don’t mind
continuing to work on this to get it up-to-date
with the current Mars codebase. I have
essentially planned this week to do that. It’s
a learning opportunity for me. :-)
Initially,
I wanted to submit two patches as Benoit
suggested, but I had some mutual
interdependencies which did not allow to
isolate one from the other (e.g. I put the
generation launcher in each diagramXX.tests
plugin, thus creating a depencency to
oep.test.framework). I’ll fix that as soon
as I can.
Again, I can see about the
feasibility of splitting this into separate
codegen/framework and generated-code patches
once I have the current patch working. I don’t
want to derail your schedule, and I’m already
into it.
Juan
Hi
Christian,
I’m not aware of all the
details, but yes it seems that this patch
is pushing new tests for most of the
diagrams.
It may be a good idea to
split the patch to separate :
-
the generator (+framework)
-
and the generated tests (for
each diagrams)
If we want to maintain this
generator, we should also add a “version
time stamped information”
in the one (many) of
generated files since the generated test
don’t follow the same lifecycle as
standard generated code.
Could you explain in more
detail what you mean by this? I’m not familiar
with a version timestamp pattern in code
generation, and I don’t know what lifecycle you
refer to.
Regards,
Benoit
De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx
[mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus
Envoyé : mardi 7 avril 2015 16:50
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Where
is the code generator for diagram tests?
It appears that this
generates an entirely new suite of tests,
correct? I’ll take a look at extending
this framework to support my needs, which
are a bit peculiar because my test cases
are driven by edits in the semantic model,
not by edits in the diagram.
I expect I’ll be
returning to the mailing list for a good
deal of help in the next while … :-)
On Tue, Apr 7, 2015 at 2:17 AM, MAGGI
Benoit <Benoit.MAGGI@xxxxxx>
wrote:
Hi Christian,
I believe the
generator is Gerrit (here [1])
waiting for a review.
Regards,
Benoit Maggi
[1] :
https://git.eclipse.org/r/#/c/38587/
According
to the developer guide on the wiki
[1], there is a diagram tests
generation framework. It is also
referenced in the headers of some
source files as the “Papyrus Test
Framework”. Certainly, many of
the tests appear to be generated.
Where
is the code generator? I don’t
find the QVTo transformations
alluded to by the wiki
documentation. I don’t see the
UML Testing Profile in the
repository, nor any MWE workflows
or launch configurations that
would run test generation.
I
ask because I plan to add diagram
synchronization
(canonical-edit-policy) tests to
each diagram’s test bundle, and I
thought it would make sense to
investigate the possibility of
including some scaffolding at
least in the test generator.
Perhaps these tests were
generated once by something that
isn’t in the repository and have
ever since been maintained “by
hand”?