Community
Participate
Working Groups
Generate plug-in with figures, instantiate generated classes and compare their structure and runtime properties to those specified in .gmfgraph model
Created attachment 36812 [details] Contains subj tests as well as fixes required to make them pass.
1. manifest.mfjet - activator needs singleton=true option? 2. Is there a real need in getFigureXCheck? Smells like code duplication, and what's really being checked is that code in figureXCheck() is aligned with code in figureX(). Can't it be done in bit more generic way? With graphdef.Figure instance you've got all the information you need to actually check IFigure instance. 3. Custom Figures as part of oeg.tests plug-in. Again, what's the need for that? What if we just generate these figures into separate plugin first, and then reference them from that plugin?
1. It does not NEED this. However it seems that all of our plugis has this flag. 2. It is TESTS code. I see a lot of other ways to implement this. E.g, create abstract class GMFFeatureChecker with 5+ implementation classes that know, say, that feature Color should be checked via some Color-specific way different from the check for, say Dimension features. Then I may create one more separate registry class which will map feature name into checker and traverse gmf-EOBject reflectively while checking generated instances against feature values. OR I may use new and exciting generative approach and generate tests using 5+ per-feature templates and 2 classes that compose them together. But, I am absolutely sure that in this case someone will mind that we really need 7 new classes/templates (which we will have to maintain, _test_, etc) just to implement simple checks that may be done by just 4 simple methods. So, I am in in trouble. In addition, I do not see a lot of code duplication there. The only common features that are checked by more than 1 FigureCheck is a children.size(). I doubt that we want to traverse ALL OF OTHER OF OUR TESTS and extract the code which checks the size of collection into separate helper code. Could you please point me to code duplication except this one? 3. We want to check that custom figures (that are just a peaces of legacy user code) may be used. This use casediffers from the one suggested (also we need to test the suggested use case, but it is the part of another scr) Please consider these 2 classes as just a legacy code.
1. There should be REASON not to have singleton. All other plug-in has singleton=true for reason, not because it's just a 'fancy' thing 2. Code duplication is in figureX() and checkFigureX() methods. Latter relies on the code in the former. If you change figureX, you have to change checkFigureX. If you are unlucky, and checkFigureX was not updated but didn't failed, you won't ever notice the problem. That's why it's benefitial to have 'veryfy' login independent from the code under check 3. What't the problem treating classes just generated as part of previous test as 'legacy' code. What's the point to have them coded (provided we trust our generated code - we do check it with our tests, right?)
(In reply to comment #5) > 'veryfy' login independent from the code under check "logic", of course
Created attachment 36891 [details] Contains subj tests (reflective version) as well as fixes required to make them pass. +250 LOCs comparing to the first patch version Do we need to have additional tests for ReflectiveFigureCheck functionality? If yes, just let me know, it would be a real pleasure for me to implement them.
Created attachment 36916 [details] One more version of subj -- allows to select between reflective- (ReflectiveFigureCheck) and typed- (GenericFigureCheck) checks tradeoff -100 LOCs and simplicity of strict typed implementation <-> probable future problems with extensibility.
ReflectiveFigureCheck was abandoned in favor of GenericFigureCheck. Point (1) regarding singleton=true attribute is completely invalid, the directive was there from the first revision
[GMF Restructure] Bug 319140 : product GMF and component Generation was the original product and component for this bug
